A Prerequisite for Effective Security

The following paper was originally published in the Proceedings of the Twelfth Systems Administration Conference (LISA ’98) Boston, Massachusetts, December 6-11, 1998 Infrastructure: A Prerequisite for Effective Security Bill Fithen, Steve Kalinowski Jeff Carpenter, and Jed Pickel CERT Coordination Center For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org Infrastructure: A Prerequisite for Effective Security Bill Fithen, Steve Kalinowski, Jeff Carpenter, and Jed Pickel – CERT Coordination Center ABSTRACT The CERT Coordination Center is building an experimental information infrastructure management system, SAFARI, capable of supporting a variety of operating systems and applications. The motivation behind this prototype is to demonstrate the security benefits of a systematically managed infrastructure. SAFARI is an attempt to improve the scalability of managing an infrastructure composed of many hosts, where there are many more hosts than hosts types. SAFARI is designed with one overarching principle: it should impact user, developer, and administrator activities as little as possible. The CERT Coordination Center is actively seeking partners to further this or alternative approaches to improving the infrastructural fabric on which Internet sites operate. SAFARI is currently being used by the CERT/CC to manage over 900 collections of software on three different versions of UNIX on three hardware platforms in a repository (/afs/cert.org/software) that is over 20 GB in size. Background compromises. They are often forced to undertake large efforts to secure their hosts and networks. Often the Since the formation of the Computer Emergency required resources are unavailable, preventing admin- Response Team, ten years ago, it and nearly a hundred istrators from completely recovering from compro- other subsequently formed incident response teams mises, usually leading to subsequent compromises. have been providing assistance to those involved in computer and network security incidents. The CERT® In this paper, when we refer to an organization’s Coordination Center has participated in the response information infrastructure, we mean: to well over 10,000 incidents over that period. • The organization’s installed base of computing Throughout that interval, incident response teams have and networking hardware, attempted to convince their constituencies to apply • The system and application software operating security patches and countermeasures to hosts on a on that hardware, routine basis. Over the course of its life, the CERT/CC • The policies and procedures governing the alone has issued over 160 advisories, 70 vendor-initi- design, implementation, operation, and mainte- ated bulletins, and 20 summaries. Most of these docu- nance of the software and hardware, and ments urge system administrators to apply a variety of • The people who perform those procedures. countermeasures. Yet, on a daily basis the CERT/CC One assumes that, in general, such an infrastruc- receives incident reports involving hosts that have ture exists only to serve some business purpose of the been compromised by intruders exploiting vulnerabili- organization. In a very real sense, an organization’s ties with publicly available patches or countermea- information infrastructure is business overhead-part of sures. The overwhelming majority of compromises the cost of doing business. continue to be a result of sites running hosts without An information infrastructure management sys- applying available countermeasures. tem (IIMS) is a system whose purpose is to automate In a recent survey we conducted, the most fre- the maintenance of an information infrastructure. quent reasons for continuing to operate hosts without available countermeasures were: Motivation • Insufficient resources A site with an adequate information infrastruc- • Difficulty in finding and understanding coun- ture finds itself able to detect and recover from com- termeasure information promises in short order. It can repair or recreate hosts • The inability to administer configuration man- using automated mechanisms designed to deal with agement across a large number of hosts. such demands. It can also protect itself from many At many of these sites, the basic computing types of attacks through proactive deployment of infrastructure is an impediment to timely distribution countermeasures. of configuration changes. These sites operate at a sub- A site without such an information infrastructure stantially higher level of risk than those with solid must spend much greater effort to detect and recover infrastructures. Such sites are not only more likely to from compromises or to proactively deploy counter- be compromised, but they are also less likely to be measures. This effort is proportional to the number of able to adequately detect and recover from hosts being managed. At a small site, this may be 1998 LISA XII – December 6-11, 1998 – Boston, MA 11 Infrastructure: A Prerequisite for Effective Security Fithen, et al. acceptable or even ideal, but tends not to be scalable SAFARI is being designed to meet four primary as the site grows due to resource constraints. objectives: At a site with an effective information infrastruc- • Construct each host in its configured state auto- ture management system, the effort to detect and matically from an empty disk with minimal recover from compromises or to proactively deploy manual intervention. countermeasures is substantially less. In general, the • Reconstruct each host to its configured state effort to deploy a change is proportional to the number after a security compromise or catastrophic fail- of different types of hosts, rather than the number of ure automatically with minimal manual inter- hosts. However, the effort to prepare for such a vention. deployment is higher due to packaging requirements • Upgrade each host with new applications, oper- of the IIMS. ating systems, patches, and fixes automatically on a regular basis with no manual intervention. Chart 1 shows some simpleminded math to illus- • Maintain each host in its configured state auto- trate these ideas. matically with no manual intervention. Let: In order to achieve the desired influence in the NH be the number of hosts system administration community, three additional NP be the number of host platforms secondary objectives must be met: EH be the effort to make a manual change on one • It should be engineered for an extremely high host host-to-administrator ratio. EP be the effort to prepare a change for automatic • It should facilitate the sharing of software deployment on any host of one platform among multiple, not necessarily mutually trust- ED be the effort to deploy a change to one host auto- ing, administrative domains. matically • It should follow a policy-based model that Then: works with a wide range of organization sizes. EM is the total effort to make a manual change on NH Whatever compromises are necessary throughout hosts: the evolution of SAFARI, the following constraints EM = EH × NH must not be relaxed: EA is the total effort to make a change automatically • Guarantee that software is distributed onto on NH hosts authorized hosts only. Guarantee that software is delivered with E = E × N + E × N • A P P D H integrity to each host and that it is installed cor- Therefore: rectly. The scalability breakeven point is when: The design should be guided by the following EM = EA overarching philosophy: If one assumes that in a good IIMS, the effort to • It should support user, developer, and adminis- deploy a change on one host automatically (ED)is trator activities in a manner that most closely negligible, then the breakeven point is when: parallels those same activities before SAFARI. NH × EH = NP × EP Design Assumptions Chart 1: Mathematical derivation of fundamentals. This work differs from related projects in some As you can see from this simplified model, at the ways. While there have been many projects relating to breakeven point, the effort to deploy change manually large scale host administration or software distribu- is proportional to the number of hosts, while the effort tion, this project is motivated primarily by scalable to deploy the same change is proportional to the num- security. As a result, we have made certain design ber of host platforms (types of hosts). assumptions that run counter to prior published work. Requirements We don’t consider disk space conservation to be a significant design motivator. Our most recent acqui- The CERT Coordination Center is currently sitions of reasonably inexpensive 18 GB disks sup- developing an experimental IIMS called the Securely ports our assumption. Therefore, a number of space Accessible Federated Active Repository for Infrastruc- conservation techniques can be immediately dis- tures (SAFARI). Via SAFARI, the CERT/CC is purs- carded. For example, the process of preparing soft- ing two primary goals: ware for distribution via SAFARI is complex enough • Enable sites to effectively, securely, and eco- without an extensive set of space saving rules to fol- nomically distribute host-resident software low. Therefore, we decided not to have such rules. from one or more managed repositories. Unlike systems that divide a software package • Enable sites to manage all software throughout between platform-independent and platform-specific its entire operational lifecycle focusing on qual- [20], we decided that minimal

Load more