[Security_sig] Infrastructure Server Use Case Draft

Mary Edie Meredith maryedie at osdl.org
Fri Aug 12 09:58:56 PDT 2005


There was only one responder to the questions about Infrastructure
Servers, namely that the answers were the same as those for Mid_Tier.
If you disagree, please speak up.  Here is the resulting use case,
posted at the following URL with links from developer:

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

--------------------------------
Use Case:
Infrastructure Server
---------------------------------
Version 0.1 (DRAFT)
Last Modified Date: 8/12/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 an “Infrastructure 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”Infrastructure 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.

---
* 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
---------------------------------
Internal Infrastructure Servers provide essential network
services such as time, naming, authentication, message forwarding,
accounting, audit, software distribution, inventory management and
service location.  Along with the network routing and connectivity
infrastructure, they create the network environment supporting
applications and services throughout the organization.	Typically,
they, or at least critical replicas of such services, will be housed
and managed in the data center, both to facilitate centralized
supervision and management of their configurations, and also to
facilitate their backup and recovery in the event of data corruption.

Services on these servers are typically redundant, synchronizing
periodically or upon changes as they occur, with their peer
services on other servers.  Such synchronization traffic may be
substantial, depending on configuration and protocol designs.
The synchronization traffic itself presents a security challenge,
as security-sensitive information (passwords, personal information
attributes) may be replicated.	Further, the risk of an attacker
delaying or modifying data in transit must be addressed, as is the
risk that old, stale information (previously deleted or obsoleted)
may be reintroduced into the operational environment intentionally or
accidentally (as may happen due to the restoration of an old backup).

While these systems are generally only used and visible within the
organization, and so are usually protected by firewalls preventing
their access by hostile outside attackers, their central role in
the effective operation and management of the network makes them
attractive targets for internal hackers, or for worm/virus-delivered
attack programs from the outside.  Defense against session hijacking,
man-in-the-middle attacks, and attempts to reconfigure cached or
configuration data should be provided in the selection of protocols
used and their protections.  Many organizations consider the networks
used by internal employees for user productivity applications (email,
collaboration, file and print sharing) to be untrustworthy, because
of the incidence of worm and virus mounted attacks delivered via
email attachments and downloaded documents.

Resource accounting may be a requirement for some of these services,
but frequently, they're operated as utilities by a centralized
operational staff chartered with keeping them running and responsive
to the loads placed on them by user workstations.

The access control policy is enforced by the system administrator
for system access, and by application administrators for the services
supported (usually several). 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 (see References section [2]),
as there are typically more services 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 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
service installations and upgrades.
---------------------------------
Implementation Notes
---------------------------------
There are currently no implementation notes for implementing security
on Infrastructure 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





More information about the security_sig mailing list