The second part of the post will discuss concepts relating to the user of application programming interfaces (APIs) as a means to securely expose information across a community of interest.
---
Modern defense systems emphasize the secure sharing of information. Shared information allows users and systems to pull what they need to derive meaning that is relevant to their specific domain context. This in turn, relieves the command structure of the burden of seeking that most elusive of operational holy grails, the truly common Common Operational Picture (COP). The operational agility stemming from shared, freely available information comes at a price. Systems that expose their own or others’ data must ensure that the data is exposed in such a manner that preserves both access and need-to-know principles while at the same time ensuring acceptable levels of computational and resource overhead.
This seems obvious, but in the defense and intelligence acquisitions communities, old information security paradigms die hard. This isn’t because of any entrenched neo-Luddism in the acquisition world. It’s due to the fact that acquisitions managers must constantly balance the attractions of new technology against the prosaic facts that fielded systems already meet operational requirements.
As you can imagine, this keeps me pretty busy. I spend a good deal of time counseling clients about the dangers of perimeter-only security and the security patterns and tools that will help them evolve and transform their organizations. The remainder of this discussion will explain some basic computer system security concepts from both historical and technical perspectives in a manner that is, I hope, useful to a broad spectrum of stakeholders including program managers, systems engineers, developers, architects and competency staff.
On May 26, 2010, US Army Private First Class (PFC) Bradley Manning was arrested in Iraq on suspicion of having passed classified material to the website WikiLeaks. He was charged with a number of offenses, including the unauthorized communication of national defense information and aiding the enemy. Manning had been assigned to a unit based near Baghdad. In connection with his duties, he had access to databases used by the military to store, exploit and disseminate classified information. His arrest came after the Department of Defense (DoD) received information that he had downloaded and passed classified data to Wikileaks, including videos of airstrikes on Baghdad on July 12, 2007 and Granai, Afghanistan in 2009, a quarter of a million US State Department diplomatic cable and approximately half a million Army war logs. This information represented the largest set of classified documents ever to be leaked.
While Manning’s actions, if proven at his trial (which is scheduled to begin in mid-2013), are undoubtedly a violation of the non-disclosure agreements (NDA) that he signed in conjunction with his security clearances, and may constitute treason, they are not the most damning part of the whole Wikileaks debacle. The real issue is that the systems to which Manning had access remained a virtual big box store of government information with few, if any, checks on access. A less technical analogy may help to illustrate the nature of the problem:
Imagine that you own an office building. This office building has many floors. Each floor contains dozens of offices, and each office belongs to a different tenant company. It’s safe to say that an employee from the travel agency renting office 314 really has no reason to have access to office 546, which is rented by a religious articles import-export firm. Now let’s imagine that at each of the entrances to the building, there is a security guard. The guard’s instructions are to ask for the photo-identification card that you issued to each legitimate tenant, and to ensure that the photograph on the card matches the person requesting access to the building.
Once the guard verifies that the person providing the identity card is in fact the person described on the card, the person is granted access to the building. Now here’s the kicker: Once past the guarded entrance, there are no locks anywhere in the building. Not on the office doors, not on the restrooms, not on the utility closets, not on the wiring and phone closets. Nowhere. Once you’re in, you’re in. You can go to any floor and into any office. It’s a free for all.
Sounds crazy, right? No landlord – and no sane tenant – would knowingly sign up for such an arrangement. Yet this sort of one-time, perimeter-only security is exactly what most computer information systems have, including those used by the government and the military. And it was exactly the sort of security used on the systems on which Bradley Manning worked. This is called “authentication only” security.
AUTHENTICATION is the act of proving that you are who you say you are. There are three primary ways of authenticating to an information system: Know, Have, Are.
- Know: The most common authentication method is to provide a shared secret that only the system and the user know. Typically this takes the form of a username/password combination.
- Have: For additional security, the system my require the user to present a physical item to which only a bona fide user would have access. Examples of this are smart cards with embedded digital certificates, RSA SecurID tokens or a mobile phone running the Google Authenticator application. (The SecurID token and Authenticator app provide rotating numerical combinations that must be entered within a certain time period to corroborate the username/password combination.)
- Are: The highest levels of authentication security require some form of biometric verification in addition to usernames/passwords and physical items. This may take the form of a voice print or fingerprint or retinal scan. While the technology for these is getting better all the time, there are still reliability issues that make many organizations reluctant to adopt biometric verification mechanisms.
No matter how secure the authorization mechanism is, it’s still only perimeter protection. Under the information assurance rules protecting the sorts of systems on which Bradley Manning worked, passwords had to be changed frequently (anywhere from every 30 to 90 days), and they had to meet stringent length (often twelve or more characters) and complexity (mandatory use of both uppercase and lowercase letters, numbers and special characters) requirements. Obviously, it wasn’t enough.
The answer is to incorporate automated AUTHORIZATION mechanisms into the security paradigm. Authorization mechanisms ensure that an authenticated user has access only to those system resources (i.e., data and capabilities) pertinent to their job, rank, organization or some combination of other attributes. Currently, there are two dominant forms of automated authorization technology in use, RBAC and PBAC/ABAC.
Most systems (especially those premised on Microsoft Windows technology) use something called Role Based Access Control, or RBAC. RBAC assumes that there are a finite number of organizational roles (loosely analogous to jobs/tasks), and that access to system resources is predicated on a user’s allocation to one (or more) of these roles. The practical problem with RBAC is that the initial set of roles winds up offering too much - or not enough – access for a particular user’s needs. The remedy is to create a new, tailored role for specific user needs. The unfortunate results of this practice are either an unmanageable proliferation of roles (a system administrator’s nightmare!) or role overlaps that negate access control efforts and create an insecure condition. As a result, there are usually only two or three roles created in most RBAC systems: User, Supervisor and System Administrator. The consequence of this paucity of roles is that there is, effectively, little or no access control.
The response to RBAC from the computer security community was the development of open, community standards supporting what is referred to as “policy based access control” (PBAC) or “attribute based access control” (ABAC). The key standard supporting PBAC/ABAC is the eXtensible Access Control Markup Language (XACML). Under a PBAC/ABAC scheme faithful to the XACML standard , instead of having a plethora of roles, each request for access to a system resource results in an evaluation of the user’s personal characteristics against a pre-defined access control policy for the resource in question. (It's worth noting that role-based security can, if desired, be implemented using the XACML standard.) Returning to our office building analogy, the implementation of an automated authorization mechanism might look like this:
Once past the perimeter guard, a tenant goes to an information desk. At the desk, the tenant presents her identity credentials and specifies the office to which she’d like to go. The attendant looks up the policy for that office, which might say something along the lines of “admit people who are full time employees of XYZ Company and have a title of manager, director, vice president or C-level employee.” The attendant then looks up the tenant’s attributes corresponding to her identity credentials. If the tenant’s employer is “XYZ Company,” her status is “full time employee” and her title is “Manager, Technical Development,” the tenant is given an access card that will grant her access to the desired office. If a key attribute is wrong (let’s say the tenant’s status is “part-time” or “consulting” employee), the tenant is not given the access card, but is instead provided with the phone number of the XYZ Company security manager to whom she can air her grievances.
So how does authorization provide augmented security in real life? Let’s place authorization in the context of the Manning/Wikileaks case. As a result of the authentication-only, perimeter security paradigm implemented on the system on which he worked, Manning had untrammeled access to not only Army information directly pertinent to the his unit’s (2nd Brigade Combat Team (BCT), 10th Mountain Division) operations, but to Army- and Department of Defense-wide intelligence and State Department diplomatic information as well. Had an authorization system been in place, it is likely that Manning would only have had access to information directly pertinent to 2nd BCT operations, thus limiting the damage he could do. In sum, authorization schemes implement “need to know” capabilities that complement the “access” capabilities of the authentication mechanisms.
It gets better though. In order to really defeat a combination of authentication and authorization mechanisms, an attacker would not only need the username/password combination (for “know-only” authentication) but would have to be able to change data in either the secured user store, the secured access control policy store or both. It’s a more daunting – and time consuming – task.
At this point, you’re probably thinking “Well, if it’s that simple and effective, why doesn’t everyone implement authorization mechanisms?” The answer has two parts: Knowledge and expense. Many architects, developers and systems engineers simply aren’t aware of either the standards or the tools that implement them. For those that are aware, the combination of software licensing fees and the perceived development effort costs associated with implementing PBAC/ABAC mechanisms are often seen as insurmountable.
The answer can be found in the emergence of open source software engines based on open standards designed expressly to support identity management and security. Open source means that the software is available for download and use free of any licensing fees. Open standards mean that there are no proprietary interfaces that would stymie the integration of these tools into existing systems. More importantly, these tools are intended to interoperate with existing system components. For example, one of the most popular user information stores available is Microsoft’s Active Directory (AD) . One of the more popular open source identity and access management engines, the WSO2 Identity Server , comes with out of the box support for AD interoperability.
Let’s do a quick recap:
- Authentication only security means that once the bad guy steals a username and password, the system is completely at his mercy.
- Authorization systems can provide additional security by limiting authenticated users’ access to those resources consistent with their jobs.
- RBAC systems are difficult to maintain because of the potential plethora of roles and the security-frustrating effects of role overlap. More importantly, RBAC system are usually implemented with only two or three roles, thus not really providing any access control at all.
- PBAC/ABAC systems are more powerful, finer grained and more easily managed than RBAC systems. They are also more secure and resistant to hacking.
- Powerful, standardized and cost-free identity management software is now readily available.
No comments:
Post a Comment