[Security_sig] Mid-Tier Server Use Case

Mary Edie Meredith maryedie at osdl.org
Thu Aug 11 17:40:03 PDT 2005



Mid-Tier Server use case info merged and draft posted here with similar
access via developer:

http://www.developer.osdl.org/dev/security/docs/MidTierServer_70cols.txt

Please review in particular the Scenario Section.

--------------------------------
Use Case:
Mid-Tier Application Server
---------------------------------
Version 0.1 (DRAFT)
Last Modified Date: 8/11/05

Copyright (c) 2005 by The Open Source Development Lab, Inc. Verbatim
copying and distribution of this document is permitted in any medium,
provided this notice is preserved.  Draft copies of this document
may not be posted publicly without indicating the draft status.

---------------------------------

Table of Contents
--------------------------------- 
Description 1
Target Acceptance 2
Participants/Roles 2
Scenarios 3
Implementation Notes 3
References 4

---------------------------------
---------------------------------
Description
---------------------------------
This use case describes what we call a “Mid-Tier Application
Server” found in a Data Center.  The purpose of creating this
description is so that the OSDL Security Special Interest Group
(SIG) can use this description to evaluate the security needs for
such a Server.	The goal is to determine the operating system
capabilities (the kernel and above) needed so that managers of
these servers can create a secure environment.	The assumptions
need to be clearly defined to do that analysis.  Once identified,
the capabilities needed can be compared to what is available on
any OS platform to identify possible gaps.

This is one of a series of server usage profiles, which will
be used to distinguish between security capabilities that are
of general use, and those that have particular applicability to
certain deployment scenarios.  In particular, the environmental
assumptions surrounding each scenario differ, and so the types of
security capabilities each requires differ, too.

Although the initial effort in creating server usage profiles is
targeted at security, we intend this description to be good enough
for other use cases to reference when they refer to server types,
in this case a ”Mid-Tier Application Server”.  In other words,
we want the description to be useful for discussions beyond the
topic of security.
---------------------------------
Target Acceptance
---------------------------------
This document is intended to help drive acceptance of any missing
features into the mainline Linux kernel or any utilities that are
impacted.  Test cases for newly developed or modified features can
be designed with this use case in mind.
---------------------------------
Participants/Roles
---------------------------------

---
* Systems Administrator
* Operations Staff
---
Special class of user that has special privileges on a given
system. This is a role held by an individual that acts as the
administrator for the system or by an individual that might have
a specific role within the administration role, for example
responsibility for system backup.
---
* Application Administrator
---
Special class of user that has special privileges for a given
application. This is a role held by an individual that acts as the
administrator for all aspects of an application. Administrative
duties among the various application administrators should be
clearly separated.

---
* User
---
Any user on the system. This is a role that is held by all
individuals using a system.  The user can interact with the system
through the processes associated with applications they are using.
Root Users are users who have root privileges. They are typically
the system administrator.  Privileged users have some of the root
user privileges, but not all.  They are typically and operations
staff member.
---------------------------------
Scenarios
---------------------------------
======================
A Mid-Tier Application Server is the classic mid-tier (in a
three-tier architecture) application server, providing processing
for applications that generally drive against databases held on
a Database server (see Database Server use case ).  One or many
different applications may share the same server, and each may
have its own configuration and administration responsible persons
(application administrators).  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.

Users may access the system directly or through portals (see Edge /
Public Facing servers use case [2]).  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.

The principle assets protected on the application server is the
business login 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, through 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.


The access control policy is enforced by the system administrator
for system access, and by application administrators (usually
several applications). The access control policy is developed by
a business group withing the company in collaboration with any IT
security group that may exist.

The number of logins as system administrator is usually small, for
example less than five.  But the number of application administrators
will be higher than the Edge Servers, as there are typically more
applications installed and there will be one or more application
administrators for each.

Any separation of system administration duties is important for
an audit administrator if audit files are kept on the system.
Separation of duties for per-application administrators is vital.

Security auditing is important for (1) system and application/service
login attempts, both successful and failed, (2) security changes
made by the system administrator or application administrator,
(3) anything else important to the site policy, (4) auditing of
per application installations and upgrades.
---------------------------------
Implementation Notes
---------------------------------
There are currently no implementation notes for implementing security
on Database Servers.

---------------------------------
References
---------------------------------
[1] Security discussions can be found in the archives of the
Security SIG:
http://lists.osdl.org/pipermail/security_sig/
[2] Use case for Edge Servers in the data center can be found at:
http://www.developer.osdl.org/dev/security/docs/EdgeServer_70cols.txt


-- 
Mary Edie Meredith
Initiative Manager
Open Source Development Labs
maryedie at hotmail.com
503-906-1942




More information about the security_sig mailing list