About the Author
Yanek Korff graduated with a Bachelor's degree in Computer Science from the College of William and Mary and is currently a Certified Information Systems Security Professional (CISSP). Mr. Korff joined Bell Atlantic as a Systems Engineer where he played a major role in the strategy, design, and deployment of a key Northern Virginia test facility. He later joined Cigital, Inc., a software quality management company, where he played a central role in the design of their systems infrastructure. He is now an essential member of the Information Security division at America Online. During his career, Mr. Korff has been able to identify and mitigate information security risks particularly relating to host-based BSD security. By leveraging his experience, he has been able to apply security fundamentals to influence business and industry practices.
Paco Hope is a Technical Manager with Cigital. His areas of expertise software security, security testing, and casino gaming. He specializes in analyzing the security of software, software systems, and software development processes. Paco frequently speaks at conferences such as the Better Software Conference, STAR East, and STAR West. He conducts training on risk-based security testing, writing security requirements, and software security fundamentals. He can be reached at email@example.com.
Bruce Potter is a Senior Associate at Booz Allen Hamilton. Prior to working at Booz Allen Hamilton, Bruce served as a software security consultant for Cigital in Dulles, VA. Bruce is the founder of the Shmoo Group of security professionals. His areas of expertise include wireless security, large-scale network architectures, smartcards, and promotion of secure software engineering practices. Bruce coauthored the books 802.11 Security and Mac OS X Security. He was trained in computer science at the University of Alaska, Fairbanks.
Excerpt. © Reprinted by permission. All rights reserved.
First we crack the shell, then we crack the nuts inside.
The Transformers: The Movie
Security is hard. We have all heard this phrase as a rationale for insecure systems and poor administrative practices. Whats worse, administrators seem to have different ideas about what "security" entails. There are two common approaches to securing systems: some view security as a destination while others see it as a journey.
Those who see security as a destination tend to characterize system security in terms of black and white; either a system is secure or it is not. This implies that you can attain security. You can arrive at the end of a journey and youll somehow be secure; you win. One problem with this viewpoint is determining where "there" is. How do you know when youve arrived? Furthermore, how do you stay there? As your system changes, are you still at your secure goal? Did you move away from it, or were you not there to begin with? As you can probably tell, this is not our philosophy.
Instead of being a destination, we think security is best described as a journeya product of ongoing risk management. Rather than trying to make your system impregnable, you continually evaluate your exposure to risks and keep the system as secure as you need it to be. An appropriate level of security is achieved when the risks facing a system balance against the level of effort spent mitigating those risks. No one buys a $5,000 vault to safeguard a pair of fuzzy slippers. You judge the value of what youre protecting against the kinds of threats it faces and the likelihood those threats will succeed, and then you apply appropriate safeguards. This is a much more practical way to view modern day information security.
When following a risk mitigation process, you will periodically pass up the opportunity to enable certain security mechanisms, even though youre capable of doing so. The additional effort may not be warranted given the level of risk your organization faces. You will eventually reach a point of diminishing returns where you simply accept some risks because they are too costly to mitigate relative to the likelihood of the threat or the actual damage that would occur. Sure, it may be fun to use encrypted filesystems, store all OS data on a CD-ROM, and deploy every other countermeasure you can think of, but do you really need to?
We define security in the context of risk. Risk is present as long as the system exists, and risks are constantly changing, so security cannot be a destination; it must be an ongoing process. "Doing security," then, is an iterative process of identifying and responding to risks. This is the philosophy that we encourage you to take in securing your infrastructure.
As youll see in the rest of this book, FreeBSD and OpenBSD are robust operating systems that offer myriad ways to maintain secure systems. Throughout the book we provide security-minded walkthroughs of software installation, configuration, and maintenance. Along the way youll notice that we seem to point out more security-related configuration options than you care to implement. Just because we explore options doesnt mean that you should implement them. Come at it from the perspective of managing risk and youll maximize the cost-benefit of "doing security."
Before we get ahead of ourselves, however, we need to cover a few concepts and principles. In this chapter, we define system security, specifically for OpenBSD and FreeBSD systems, but also more generally. We look at a variety of attacks so that you, as an administrator, will have some perspective on what youre trying to defend against. Well look at risk response and describe how exactly you can go about securing your FreeBSD and OpenBSD systems.
What Is System Security?
Security professionals break the term security into three parts: confidentiality, integrity, and availability. This "CIA Triad" is a set of security requirements; if youre not taking into account all three of these concerns, youre not working towards providing security. We offer a lot of recommendations in this book that should help you work towards building secure systems, but we dont tell you how these recommendations fit in with the CIA Triad. Thats not what this book is about, and it would detract from the real message. Nevertheless, as youre looking at building encrypted tunnels for transferring files, jailing applications, and so on, think about what part of the Triad youre focusing on. Make sure youve addressed all three parts before your project is done.
Whether were talking about physical security, information security, network security, or system security, the CIA Triad applies. The question is, exactly how does it apply to system security?
Confidentiality is all about determining the appropriate level of access to information. Confidentiality is often implemented at the most basic level on FreeBSD and OpenBSD systems by traditional Unix permissions. There are a variety of files scattered across the filesystem that are readable only by the root user. Most notable, perhaps, is /etc/master.passwd, which contains hashes for users passwords. The vast majority of files are readable by everyone, however. Even system configuration files like /etc/resolv.conf, /etc/hosts, and so on are world readable. Is this wrong? Not necessarily. Again, confidentiality isnt about having to protect data from prying eyes; its about classifying data and making sure that information deemed sensitive in some way is protected appropriately.