<html>
<head>
<DEFANGED_style type="text/css">
<!--
body { margin-top: 4px; margin-bottom: 1px; line-height: normal; margin-left: 4px; margin-right: 4px; font-variant: normal }
-->
</DEFANGED_style>
</head>
<body DEFANGED_style="margin-top: 4px; margin-bottom: 1px; margin-left: 4px; margin-right: 4px">
<DIV> Here are the two revised sections: The biggest changes are to the Database server description. I'm not sure how much more change is needed to the mid-tier, other than to say it's possibly clustered.
</DIV>
<DIV> </DIV>
<DIV>Database Server
</DIV>
<DIV>This is the classic raised-floor, big iron, possibly clustered, 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.
</DIV>
<DIV> </DIV>
<DIV>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.
</DIV>
<DIV> </DIV>
<DIV>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. Database instance files must be able to be managed by separate administrators, on a per-instance basis, so that responsibilities can be separated. When clustered or networked file systems are used, means must be available to assure that disk and file space allocated to database instances will be available when required, and protected from access or use by other databases in the cluster.
</DIV>
<DIV> </DIV>
<DIV>To assure continuity of operations (an important security objective that includes defending against denial of service attacks on systems), on-line backups, both incremental and full, must be able to be taken of still-open-and-operating database instances, when such instances cannot be scheduled to be unavailable to allow “cold” backups to be taken. Transaction journaling of changes, so that backups are transactionally consistent, may also be necessary, along with the ability to restore databases and roll them forward, possibly transaction-by-transaction, past the point of the last available checkpoint, so as to recover from specific corrupting transactions.
</DIV>
<DIV> </DIV>
<DIV>Mid-Tier Application Server
</DIV>
<DIV>This is the classic mid-tier (in a three-tier architecture), possibly clustered, application server, providing processing for applications that generally drive against databases held on a Database server (see 2.1.1, above). One or many different applications may share the same server, and each may have its own configuration and administration responsible persons. Keeping applications from getting in each others way, whether through version conflicts between shared libraries and resources, crashes, isolation of each others configurations and data, etc. is vital to avoid having one poorly written or administered application from crashing the entire application service platform. Separating administrative duties among the various application administrators is vital.
</DIV>
<DIV> </DIV>
<DIV>Users may access the system directly or through portals (see 2.1.3 Edge / Public Facing servers, below). Though protected by firewalls, application access protocols (SOAP, HTTP, RPC, DCE, etc.) may be susceptible to buffer overflow and cross-site scripting attacks through the firewall holes that enable access to applications.
</DIV>
<DIV> </DIV>
<DIV>The principle asset protected on the application server is the business logic of the enterprise, the flow of transactions, the decisions that are made, the reports that are created, and the access to information provided. Loss of service of an application, or more severely, several applications through the loss of the server, may have serious financial impact on an organization, though the loss of on-line sales, failure to respond to requests for information, increased customer, partner, or employee frustration, etc. Denial of service is a serious risk.<br><br>>>>Mary Edie Meredith <maryedie@osdl.org> 04/28/05 3:28 pm >>><br>On Thu, 2005-04-28 at 13:04 -0600, Ed Reed wrote:<br>>My take is that matters of SAN, encryption, etc. are all details<br>>within the use cases, not easily surfaced at this level of overview.<br>> <br>>Whether NAS is different from the departmental server, I don't know.<br>> But SAN almost falls into the category of tape libraries, as far as I<br>>can tell - it's an abstract shared resource.  It's management and<br>>security is certainly important, particularly in that we haven't<br>>thought much, in the past, about the risks of sharing disk spindles by<br>>multiple machines, though that certainly comes up in clusters.<br>> <br>>I didn't talk about clusters, I guess...would that be a good add,<br>>either here or in the Mid-Tier description?<br><br>I believe clustering is appropriate for both database and application.<br>However, there you start to enter the muddy waters of what you mean<br>by a cluster.  <br><br>Would it be possible to say that "The database server environment may<br>include shared resources with other trusted servers.  Examples are<br>configurations like clustering and storage solutions like NAS and SAN."<br>It seems like if we need to think about how application servers interact<br>with database servers, we need to consider all interfaces with the db<br>server to other intelligent forms of life (--:  Besides this gives is<br>the license to care about NFS V4 security in the context of a database<br>server. Right?<br>><br>>>>>Mary Edie Meredith <maryedie@osdl.org> 04/28/05 2:09 pm >>><br>>On Thu, 2005-04-28 at 11:42 -0600, Ed Reed wrote:<br>>>Here's my first take on the description of what I mean by a Database<br>>>Server.  There are aspects, in this description, of environmental<br>>>assumptions, security objectives, risk analysis, etc.  It's in<br>>>English, though, or at least tries to be.  It's almost a short "use<br>>>case".<br>>><br>>>I'll follow with descriptions of the other profiles shortly.<br>>><br>>>Your comments and suggestions welcome (at least until I see them ;-)<br>>><br>>>Ed<br>>>======================<br>>>Database Server<br>>>This is the classic raised-floor, big iron server, providing database<br>>>processing resources to applications throughout the organization.  It<br>>>typically supports multiple database instances, possibly from<br>>multiple<br>>>database technologies and vendors.  Transactional semantics are<br>>>typical, with different performance tuning parameters used as daily<br>>>processing loads change from on-line transactional to batch update /<br>>>reporting in nature.<br>>><br>>>Access to such a machine is presumed to be limited to trusted<br>>>application servers located within the same data center, or at least<br>>>to be isolated from casual access from users and developers.  No<br>>>access from customers, competitors or hostile attackers is expected.<br>>>User accounts on such a machine are limited to those needed by the<br>>>operations staff and database administrators to install and maintain<br>>>the operating system and databases, themselves.  Information<br>>wearhouse<br>>>and decision support center ad-hoc queries are only allowed to come<br>>>through application servers (see 2.1.2, below) so as to make resource<br>>>and performance management possible.  Only privileged users, not<br>>>necessarily root users, but trusted employees and contractors, have<br>>>login privileges on the machine. <br>>><br>>>All administrative and user actions with respect to the machine are<br>>>candidates for audit capture, analysis and reporting.  Business<br>>>critical information is held on the machine which, if stolen or<br>>>inadvertently published, could have material effect on the<br>>>organizations financial performance, share price, or public<br>>>reputation.  Customer privacy-sensitive information, ranging from<br>>>financial to health-care in nature, are likely to be held on such a<br>>>server.<br>><br>>Do we need to talk about the disk farm for this machine possibly being<br>>a shared disk farm (over Fibre Channel, iSCSI, NFS ) that we assume is<br>>also secure?<br>><br>>Also, in the case of NFS V4, is there a way of describing<br>>the relationship of the database server to storage that would imply<br>>certain encryption types (if not all of them) that we discussed<br>>in the Security SIG call a couple of weeks ago (Authentication only,<br>>Integrity, Privacy)?<br>><br>>Or should is all this be left for other sub use cases?<br>><br>><br>>>security_sig mailing list<br>>>security_sig@lists.osdl.org<br>>>http://lists.osdl.org/mailman/listinfo/security_sig<br>><br>><br><br> </DIV>
</body>
</html>