[Security_sig] Draft: DCL Database Server Profile description

Lynn de la Torre ldelatorre at osdl.org
Fri Apr 29 09:59:10 PDT 2005

I've thought about it and I don't think it changes the security
requirements. Let's leave your descriptions as-is.  We can have a
configuration section separately in the use case somewhere for reference
just to complete
the descriptions of our servers.

On Fri, 2005-04-29 at 00:29, Ed Reed wrote:
> re: "Is
> it helpful to characterize the type of server configuration, or 
> does this just muddy the water?" 
> I don't think that changes the security aspects of the system.  True,
> the balance of memory to disk resources and CPU will vary from the DB
> to the app server, but that's true across the board.  We can add
> something like this, but I'm not sure what it adds.  What do you have
> in mind? 
> Ed
> >>>Lynn de la Torre <ldelatorre at osdl.org> 04/28/05 7:26 pm >>>
> Ed,
> This is really great! You have summarized in a few paragraphs the
> essence of the database server profile. A few minor
> corrections/suggestions.
> On Thu, 2005-04-28 at 10:42, Ed Reed wrote:
> >Here's my first take on the description of what I mean by a Database
> >Server.  There are aspects, in this description, of environmental
> >assumptions, security objectives, risk analysis, etc.  It's in
> >English, though, or at least tries to be.  It's almost a short "use
> >case".
> > 
> >I'll follow with descriptions of the other profiles shortly.
> > 
> >Your comments and suggestions welcome (at least until I see them ;-)
> > 
> >Ed
> >======================
> >Database Server
> >This is the classic raised-floor, big iron server, providing database
> >processing resources to applications throughout the organization.  It
> >typically supports multiple database instances, possibly from
> multiple
> >database technologies and vendors.  Transactional semantics are
> >typical, with different performance tuning parameters used as daily
> >processing loads change from on-line transactional to batch update /
> >reporting in nature.
> Is it helpful to characterize the type of server configuration, or
> does this just muddy the water?
> I might add:
> Depending upon the type of workload, whether true transactional or
> some
> decision support included, the configuration will change. However, it
> is
> safe to assume that there will generally be more than 4 cpus, a large
> amount of memory to balance the cpus, and some type of large disk
> array
> attached, usually SAN.
> > 
> >Access to such a machine is presumed to be limited to trusted
> >application servers located within the same data center, or at least
> >to be isolated from casual access from users and developers.  No
> >access from customers, competitors or hostile attackers is expected.
> >User accounts on such a machine are limited to those needed by the
> >operations staff and database administrators to install and maintain
> >the operating system and databases, themselves.
> Information Warehouse
> >  Information wearhouse and decision support center ad-hoc queries
> are
> >only allowed to come through application servers (see 2.1.2, below)
> Definitely a good assumption to make for our purposes.
> > so as to make resource and performance management possible.  Only
> >privileged users, not necessarily root users, but trusted employees
> >and contractors, have login privileges on the machine.  
> > 
> >All administrative and user actions with respect to the machine are
> >candidates for audit capture, analysis and reporting.  Business
> >critical information is held on the machine which, if stolen or
> >inadvertently published, could have material effect on the
> >organizations financial performance, share price, or public
> >reputation.  Customer privacy-sensitive information, ranging from
> >financial to health-care in nature, are likely to be held on such a
> >server.
> >
> >
> >
> >security_sig mailing list
> >security_sig at lists.osdl.org
> >http://lists.osdl.org/mailman/listinfo/security_sig

More information about the security_sig mailing list