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

  </body>
</html>