[Security_sig] Draft: DCL Database Server Profile description

Mary Edie Meredith maryedie at osdl.org
Thu Apr 28 11:09:29 PDT 2005

On Thu, 2005-04-28 at 11:42 -0600, 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. 
> 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 wearhouse
> and decision support center ad-hoc queries are only allowed to come
> through application servers (see 2.1.2, below) 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. 

Do we need to talk about the disk farm for this machine possibly being
a shared disk farm (over Fibre Channel, iSCSI, NFS ) that we assume is
also secure?  

Also, in the case of NFS V4, is there a way of describing
the relationship of the database server to storage that would imply
certain encryption types (if not all of them) that we discussed 
in the Security SIG call a couple of weeks ago (Authentication only,
Integrity, Privacy)?  

Or should is all this be left for other sub use cases?

> 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