Table of Contents
- Introduction to the Reference Guide
- The New Itinerary for Windows Server 2008
- The Registry
- Domain Organization
- Executing the Migration Plan
- Resource Management
- Anatomy of a Global Exploit
- Castle Defense: Strategy or Mythology?
- The Mindset Shift in Windows Vista
- Utilizing Local Groups in Vista
- Building Policies with Vista's SIDs
- The New Windows Vista Firewall
- The Vista Alternative: Firewalling as Policy
- Making Vista Play By the Rules
- The Group Policy Effect on Firewalls
- The Keys to Kerberos Authentication
- The Kerberos Cipher: A Thriller in Several Parts
- Conversation with a Three-Headed Dog
- How Modern Authentication Changes Network Architecture
- What Is, and Is Not, Exchanged During Logon
- The Authenticator Is Revealed
- Windows Firewall and the Modern Enterprise Network
- How Group Policy Enables Remote Firewall Control
- Process Authentication
- Digital Certification
- Implementing Transport Layer Security
- Know Who Is Connected Using Two-Factor Authentication
- Clustering in the Virtualization Era
- The Basics of Windows Server Clustering
- When Windows Clustering Started Making Sense
- Overcoming Clustering’s Single Point of Vulnerability
- What Do You Have To Lose?
- Disasters Never Happen To Me
- Logistical Disaster Avoidance
- The Purpose of Access Control Lists
- Making Windows XP "Access Controllable"
- The Authorization Store
- Windows Server Super Security Policy Construction Kit
- Security Policy Construction Kit Continued: Granular Changes to the Security Configuration Template
- Security Policy Construction Kit Continued: Balancing Auditing with Performance
- Securing the File System
- Keeping Files Confidential with EFS
- Security Documentation
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Networking at the Link Level
- Network Applications
- Windows Management Instrumentation
- The Dawn of Windows Server 2008
- Windows Server By Command
Castle Defense: Strategy or Mythology?
Last updated Sep 26, 2003.
The malicious user is a person whom sociologists and psychologists have been trying to analyze, categorize, and diagnose ever since they were introduced to the concept of malicious computer use by some movie or television show. If there is anything that I have learned from the white papers and treatises these parties have presented, it is that malicious users are about as likely to be typified or classified as people who take off from the gas pump without paying. "Hackers," as they have been unfortunately dubbed by the popular press, are not a breed or a condition or an aberration on the human populace. As a result, any enterprise security policy that is structured even partly on the concept of responding to malicious use as a clinically diagnosed or professionally recognized behavior pattern, is probably doomed to failure from the beginning.
But if something can be said about security engineers generally or as a whole, it is that they're smart. Smart people use visual symbology and textual metaphors to help them catabolize and digest sweeping and complex topics. To some degree, much of the practice of psychology itself is the act of symbolizing multiple observations of human behavior in the attempt to extract patterns and similarities that we can understand, talk about, and base screenplays on. Whenever anyone or any group of people, for any reason, builds a plan of defense for themselves, to some degree, they borrow from the realm of psychology. They characterize what constitutes an attack or an affront by analyzing, as best they can, who is doing the attacking and why. (For exceptions to this rule, see the 9/11 Commission report.) Psychology compels analysts to study patterns of human behavior when assessing threats and composing strategies, even if the threat is actually mechanical in nature. And because analysts resort to examining behavior, the strategies they employ tend to be symbolic or metaphorical, even when the threat may be about as metaphorical as the number 16.
Applying the Fortress Mentality to Information
One of the concepts that has been bandied about among security engineers for the last decade, is a concept called castle defense. In more recent white papers, the concept is referred to more formally as the Castle Defense System (CDS), although it has no official creator, manufacturer, or vendor. The earliest reference to the notion of invoking castles as a means of visualizing security strategies, is in a 1999 article by consultant Frederick M. Avolio, although at that time, Avolio used it mainly to visualize the concept of deploying multiple firewalls to protect multiple system services. The general methodology of castle defense has come to mean the apportionment of a network's functions and services into compartments—"garrisons," if you will—with security protection at the gates to marshal the flow of transactions.
In one modern incarnation of the CDS model, a business' critical information is protected by five discrete compartments of services. In a sense, the compartmentalization itself serves as part of the security, for reasons we will examine later. These compartments are visualized as parts of a medieval castle, perhaps mainly because it helps individuals to remember the underlying concepts by tying them to something familiar. Starting with the core or "keep" of the castle and working outward toward the network boundary or "moat," the five layers are as follows:
- Critical information. The description of this division is roughly equivalent to a business' primary database, which was described once to me by a CIO as "the data that represents our dollars."
- Physical protection. This layer literally represents the physical security measures a business undertakes to protect its resources: human and canine security officers, surveillance cameras, physical fortresses.
- Operating system hardening. (Not to be confused with the type of "hardening" that constrains blood flow through veins or arteries.) Primarily, this compartment constitutes the services that an operating system provides for securing files and the file system. Encryption could be classified in this compartment, but anti-virus services could be visualized here as well.
- Information Access. This compartment represents the security of transactions, as well as policies, identity, and access controls generally provided by services such as Active Directory.
- External Access. This layer deals with the "front gate:" initial logon and authentication, as well as perimeter networks that provide public and customer services, and virtual private networks.
Depending on whose seminar you take or white paper you read, there are a myriad of purposes for compartmentalizing services in this specific way. One is the delegation of responsibility for securing and protecting services, among members of a security or I.T. team. When deciding who is responsible for what, an I.T. manager can examine résumés and vitae, learn and assess team members' respective strengths and weaknesses according to the lists they provide, and delegate responsibility accordingly. Indeed, these five groupings do correspond with the contents of the key skill sets listed on IT specialists' résumés.
Another purpose of the model is to help security analysts visualize their networks' components not from the inside out, but from the outside in. By seeing the network the way an outsider sees it—more representative of physical components than of logical or virtual services—they imply analysts could more easily ascertain the nature of attacks from the outside.
In either event, supposedly one of the goals of this model is to help you build a plan of action. If you can see the stages of overall network security as divided into zones that are separated from each other by perimeters, proponents of CDS argue that the question of security can be boiled down to, "How do I secure the perimeter?" Then that question can be applied equally to each perimeter, one at a time, working from the inside out or the outside in depending on who is interpreting the model.
The Breach of Security
If you're a regular reader of the InformIT Reference Guides, have studied the sections on Active Directory, migration, and security quite thoroughly, and have sampled the resources the Guides send you to, then you already see the most serious problems with the Castle Defense System model.
The core of the problem is the core of the model: Critical information, as every experienced security analyst learns, is not a cache full of items kept in a treasure chest or locked in a safe like a stash of coins. It's not a list of items. Critical information is comprised of transactions. If you work with SQL Server, and you design models for replication and rollbacks, you know this intrinsically. Critical information is comprised not only of the data stored in fields and records, but the transactions and movements that make that data active. All banking databases are comprised of transactions, not states.
Think of a real relational database like a recorded chess game. The state of the game at any point is reflected not by separate frames of chessboards, or individual 8 [ts] 8 grids of occupied and unoccupied squares, but of individual movements whose transactional description follows a protocol. "White" and "Black" are the agents of each transaction. Their identities are easily presumed; they're the only two intelligent services in the entire universe of the chessboard. In reality, the agent of a transaction must be more aggressively authenticated. This renders authentication of each and every transaction not something that validates the identity of the agent, but the identity of the agent itself. In Windows Server 2003's Active Directory model, the security identifier (SID) is the identity of the user and owner of the transaction, not the element that identifies some cleartext label that identifies a transaction. The SID is not an add-on or an afterthought. It is not separate from identity. But in the CDS model, authentication takes place at the outer perimeter—at tier 5—while security of critical information takes place at tier 1.
It isn't difficult for a real-world security analyst to cast a skeptical eye on Tier 2 of the CDS model. Rarely in the course of history has anyone who has attempted to access a critical database, locally or remotely, overtly or clandestinely, found her way obstructed by, say, a dog. As many security analysts and columnists have noted over the last four years, one of the greatest errors organizations can make is confusing physical security for digital security.
While some Microsoft analysts have been ardent proponents of the CDS model, the corporation does not either endorse or rebuke it officially. But as every Windows administrator knows and as Microsoft will readily agree, Internet Information Server is a component of Windows Server. Over the years, IIS is the part of Windows that has needed the most hardening—I and others have made that argument, and have been pleased to see Microsoft address it positively. Thus real-world experience tells us that information access services—which, by one definition, could be explained as "accessing the file system"—and operating system services (also known as, "accessing the file system") are the same services.
But there is one more critical error, and it's a more subtle one: The Castle Defense System model perpetuates the common misconception that users enter a system and exit a system, as though they were people represented virtually, like Jeff Bridges and Bruce Boxleitner in the movie "Tron." CDS does this by drawing maps of gateways and perimeter checkpoints—inspired, perhaps, by Avolio's original, sensible notion of drawing maps for multiple firewalls—implying that networks are equipped with turnstiles through which individuals enter virtual rooms full of virtual services that are either exposed or locked down. Even the most basic understanding of the HTTP protocol gives one the tools to completely destroy this notion. Internet architecture follows a transactional model of requests and acknowledgments. The Web gives users the impression—or more accurately, the illusion—that they are "in" something, or roaming a site, when in actuality, the information responsible for substantiating that illusion is generally already procured, and the transaction completely closed, by the time the user ever reads it.
Network transactions do not follow conventional building architecture models, whether that building is a shopping mall, a railroad, a KFC, or a castle. If you want to see how service compartmentalization is "done right," look to the OSI Reference Model on which all Internet networking is based. Here, services are discretely grouped into seven tiers. A service is defined as something that the elements of one tier produce for some other tier or for the user. In the OSI model, a service is always provided to the tier above; and after Layer 7 (the application layer), the recipient of service is the user. A service receives its support only from the tier below it, and nowhere else. For example, Internet Protocol provides identity service to the transport layer, where TCP/IP provides routing and communication services to the session layer (for Windows' purposes, a network BIOS). This delegation of services and responsibilities is clear and unambiguous. Nothing in Tier 5 provides services to Tier 1, or vice versa.
The problem with applying behavioral models to information technology, it turns out, is that behaviorists associate too many human characteristics to technological entities. As a result, they actually befuddle the issue by creating frameworks under which security analysts work that are too ambiguous to be sensibly defined, but also too rigid to successfully escape from. At some point, it can and must be conceded that true system security is achievable without any notion or illusion of the comprehension of the mind or minds (if there are any) behind malicious use, or of the masonry behind firewalls and perimeter defenses. Networking is, by definition, an abstract and virtual science. Comprehension of networking—and thus, of network security—is best achieved when we deal with the abstractions at their own level, and not mistake them for concrete...or, more dangerously still, for brick and mortar.
Books and E-Books
- Northcutt, Steven; Zeltser, Lenny; et al. Inside Network Perimeter Security, 2nd Edition. Sams Publishing, 2005. Preview Chapter 24, "A Unified Security Perimeter: The Importance of Defense-in-Depth," on Safari.
- Thorsteinson, Peter; Ganesh, G. Gnana Arun. .NET Security and Cryptography. Prentice-Hall, 2003. Preview Chapter 10, "Web Services Security," on Safari.