-------------------------------- 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