[Security_sig] Edge Server Use Case Draft 0.1

[Mary Edie Meredith]

I've merged the comments made on the last conference call with Philip's
and posted the resulting "Edge Server Use Case (Draft 0.1)" on developer
at this location,
http://www.developer.osdl.org/dev/security/docs/EdgeServer_70cols.txt
accessible from the security sig homepage (under documentation)
http://developer.osdl.org/dev/security/
and the use cases list (security link on left panel)
http://developer.osdl.org/dev/usecases/

Here is the text for your review (the important stuff to review is the
"Scenario" section, about a page's worth.  The other server types are
forth-coming.

--------------------------------
Use Case:
Edge/Public-Facing 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 4
References 4

---------------------------------
---------------------------------
Description
---------------------------------
This use case describes what we call a “Edge Server” or
“Public-Facing 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“Edge 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.
---
* 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 an operations
staff member.
---------------------------------
Scenarios
---------------------------------
An edge, or public facing server performs many of the network
guardian functions to limit methods of attack upon critical business
systems.  They'll typically be deployed in the data center, and be
associated with a Firewall or Demilitarized Zone (DMZ) intended to
isolate critical systems from pubic attack.

Remote Access servers, modem pools and their associated terminal
servers, Virtual Private Network (VPN) servers all fall into this
category, as do public facing DNS, SMTP, and HTTP Proxy Portals.

It is not unusual for such systems to:
1.demand authentication of requests before allowing access to
the protected network, either from devices or from users of those
devices, and
2.provide audit recordings for system administrators,
3.tally and record resource usage accounting records for system
administrators or operations staff, and
4.provide access control policy enforcement based on the identity
(either network address, user name, or other identifying information)
associated with the connection.

The typical security environment for an edge server is as follows:
*Hostile attackers are expected and are likely frequent.
*The system administrator implements the security policy for
the system, the application administrator (if there are any on
the server) will implement the security policy for applications.
The policy will likely be part of a site-wide policy determined by
one or more groups formed to apply corporate policy to a security
policy, sometimes with people who do not have full grasp of the
implications of their policy decisions.
*There is usually very limited access by employees via login.
In some provisioning models, there is no access, as the provisioning
is automated, the server is removed if there are problems, and
troubleshooting happens in an isolated lab.
*Access by outside users is controlled by business units following
authentication/authorization for pre-packaged roles only.  These
users are unlikely to get a shell prompts, but they use services
(like web services) that require authentication/authorization.
*Quite a few outside users access these systems, but a few to none
will have administrative access to the system.
*Separation of administrative duty is not necessary, excepting
possible the audit administrative duty if the audit files are kept
on the server.
*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) IDS style auditing of things like network traffic analysis,
or binary/configuration file checksum intrusion detection (see [2]
in References section)..
*Retention on the server of sensitive information is unlikely,
but flow through of sensitive information to other data center
servers may happen.
*Denial of service mitigation is expensive, so typically edge servers
use primitive DoS blocking IP address, IP address blocking at the
firewall, or throttling techniques.
*Disaster continuance is covered by a geographically remote
fail-over.  Multiple edge-servers are usually configured in the
event of failure of one.

---------------------------------
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] Intrusion Detection Systems (IDS)on Linux Resources:
http://www.linuxsecuritycentral.com/resources.php?title=Intrusion
+Detection