Chapter 17. Data-Protection MechanismsYou are almost finished! Relax, take a breath , and congratulate yourself: we sincerely hope that what you have learned so far from this book will benefit you as you build (or rebuild) your network's security infrastructure. It is now time to explore the last layer of our model: securing the data itself. Data is why you have networks and computers; data is what makes all modern organizations tick. And for some attackers, it is also the most enticing target. Attackers know they can cause you lots of grief if they simply prevent you from getting to your data, whether through a denial-of-service attack or through active data destruction. And because data is becoming increasingly mobile, it is becoming increasingly more important that organizations invest in sound data-protection mechanisms, because there are times where you cannot rely on any of the other layers to provide sufficient protection. In this chapter, we investigate technologies that can protect data at rest: [1] access control lists, rights management, and a bit on encryption. We also cover a little on auditing. And although it might make sense to have included EFS in this chapter, we put it in the physical security chapter instead because we believe that EFS's principal role is to protect the data on stolen laptops.
Access control is part of the authorization (sometimes referred to as authz) function of a computer system. Authorization is part of the three A's that a secure product must be able to perform: authentication, authorization, and auditing. We have discussed the authentication function in Chapter 11, "Passwords and Other Authentication MechanismsThe Last Line of Defense," but a brief review before we move on to the other two is appropriate. Authentication is the process of identifying a user and binding that user to an identity within the computer system. In Windows, the user identities are held within the Security Accounts Manager (SAM) database or in Active Directory (AD). Although it is possible to have authentication without identification, normally the two are so intertwined that we consider them part of the same functionality. (An example of authentication without identification is where multiple users could use the same computer system identifier [shared accounts, for instance]. You only know which computer system identifier was used, not which actual person performed the operation.) Authorization is the process of asserting whether a computer system identity (hereinafter referred to as a user) has the right to perform some task or another. Typically, the functionality of authorization is implemented through an access control list (ACL), but there are other mechanisms as well. For instance, Windows has the concept of account rights and privileges. An account right is the right to log on or not log on through a particular mechanism, such as logging on locally (SeInteractiveLogonRight internally). A privilege is the right to perform certain system- related operations, such as replacing a security token on a process (SeAssignPrimaryTokenPrivilege). Although account rights and privileges are different constructs and are even defined in different header files (for the programming-inclined account rights are defined in NTSecAPI.h, while privileges are defined in WinNT.h), they are usually considered together under the common moniker "privileges." As often as possible, it is better to assign rights to groups than to individual users. Because users can belong to many groups, create groups that represent the various rights you will use throughout your network and add or remove members as appropriate. [2]
Auditing is the ability to hold users accountable for their actions. The system should have the ability to create an audit trail of accesses to the objects the system protects. This is typically also implemented through ACLs, but a different kind of ACL. |