Tuesday, February 26, 2013

Securely Exposing Information 101: An Overview

This two part post provides a high level overview of secure information sharing concepts and and mechanisms. This first part discusses fine grained access control mechanisms achieved through the use of Policy Based Access Control (PBAC) mechanisms implementing the eXtensible Access Control Markup Language (XACML) standard.

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.

Tuesday, February 5, 2013

Cybersecurity Cause and Effect: Motivations, Vision and Options

On Friday, 25 January 2013, the hacktivist group Anonymous hacked and defaced the website of the United States Sentencing Commission (USSC), the agency responsible for articulating the sentencing guidelines for the US federal courts.  According to Anonymous, the attack was a response to the 11 January 2013 suicide of activist Aaron Swartz, which some allege to have been motivated by Swartz’s prosecution by the US Department of Justice.  The hack replaced the homepage with a video condemning the prosecution, claiming to have distributed encrypted government files and threatening to release the encryption keys if the government failed to reform cybercrime legislation.

Two days later, on 27 January 2013, Anonymous hacked the USSC website again, turning it into a playable version of the classic video game “Asteroids, ” and tweeted that the game could be played on a “backup” site – the website for the federal probation office in Michigan. Once the player erases the USSC web site while playing the game, Anonymous’ trademark Guy Fawkes mask is revealed.  The mask is made of white text on a black background reading “We do not forgive.  We do not forget.”  As of 1 February 2013, the USSC website is listed as “under construction.”

At the same time (27 January 2013) the US Department of Defense (DoD) that the American cybersecurity force, US Cyber Command, would be dramatically expanded over approximately three years, growing from 900 to about 4,900 personnel.  The expansion’s goal?  To transform an agency that has been focused on security and defense into a 21st century force capable of offensive, defensive and effects based operations.  The objective Cyber Command will consist of national mission forces, whose mission will be to defend critical national infrastructure; combat mission forces, who will integrate and work with deployed combat forces to add a cyber weapon to a combatant commander’s arsenal; and cyber protection forces charged with defending the DoD’s networks.

Coincidental timing?  Maybe.  It’s more likely that that the DoD is finally waking up to 21st century reality.  In 2010, DoD systems were probed six million times a day.  In 2013, it's estimated that DoD systems will be probed by unauthorized users over eight million times a day.  That’s in excess of 300,000 probes an hour.  This, however, is only the tip of the iceberg.  The hostility of the international cyber-environment makes Io’s (one of Jupiter’s moons) volcanic surface, sulfur dioxide atmosphere and continuous exposure to lethal ionizing radiation seem warm and inviting by comparison.  Secondary, and, increasingly, primary schools in both Russia and China feature state sponsored hacking clubs.  These aren’t just modern alternatives to chess and math clubs.  They’re state sponsored militias that combine a powerful offensive cyber capability with plausible deniability. 

The might of these quasi-state organizations was demonstrated in 2008 when Russia and Georgia went to war.  Within hours of the commencement of hostilities, the Georgian internetinfrastructure was paralyzed.  Who was behind the attacks?  A shadowy, and mostly illegal, organization known as the Russian Business Network (RBN) and a collection of hacktivists focused on the stopgeorgia.ru website.  (Interestingly, the stopgeorgia.ru website was hosted on servers located in Texas.)  The fact that the cyber attacks coincided neatly with attacks by Russian air and ground forces was lost on nobody.  Russian protestations that the attacks were the work of overzealous nationalists were at best unconvincing. 

The Chinese have taken the concept of a “people’s cyber war” a step further by creating “cyber warfare militias.”  Cyber militias are People’s Liberation Army (PLA) civilian unitscomposed of workers with high tech day jobs.  Militia members channel their professional expertise into PLA efforts on military communications, electronic warfare and network operations.  At the same time, the Chinese are investing heavily in augmenting the regular PLA’s ability to manage and exploit cyber technology as well as advanced weapon systems.

And so, the DoD is making a very timely decision. More importantly, the decision is supported by official DoD policy.  The DoD Information Enterprise Architecture (IEA) version 2.0 calls out very specific rules and principles with respect to system and information security, including:

Authoritative data assets, services, and applications shall be accessible to all authorized users in the Department of Defense, including Joint, interagency, inter-governmental, and multinational partners, and accessible except where limited by law, policy, security classification, or operational necessity;
  •  The globalization of information technology, particularly the international nature of hardware and software (including supply chain) development and the rise of global providers of Information Technology (IT) and communications services presents a very new and unique security challenge. Global Information Grid (GIG) resources must be designed, managed, protected, and defended to meet this challenge;
  •  All DoD information services and applications must uniquely and persistently digitally identify and authenticate users and devices. These services, applications, and networks shall enforce authorized access to information and other services or devices according to specified access control rules and quality of protection requirements for all individuals, organizations, COIs, automated services, and devices;
  •  A comprehensive security policy will be developed that addresses all aspects of Identity Management and Authentication (Id&A) and provides for realistic opportunities to enforce the greater Information Assurance (IA) policy requirements;
  • Design and implement a single authentication mechanism that is usable across the IE regardless of Service affiliation, role, and/or deployment status; and
  • Implement a digital attribute based approach for granting access to information integrated with an overall IA policy and single authentication mechanism approach.

The decision (as well as its rationale and execution methodologies) to improve the DoD’s defensive and offensive cyber capabilities is well understood and has commitments from the highest levels, including the DoD Chief Information Officer’s (CIO) office, the office of the Director of the Defense Information Systems Agency (DISA) and the secretaries’ offices for the service components.  Unfortunately, this decision has yet to be widely reflected in the systems currently fielded by the DoD and the intelligence community (IC). 

Many of these systems rely on a security perimeter guaranteed by ever-changing passwords, trusted digital certificates or both, coupled with role-based access control (RBAC) mechanisms.  Unfortunately, the administrative overhead associated with managing large numbers of RBAC roles results in very few being implemented in practice.  A typical fielded instantiation will have only two or three roles such as user, supervisor and system administrator.  This means that once an attacker (either an external hacker belonging to a cyber-warfare militia, or worse, a disgruntled insider) is past the perimeter security, there is virtually no system resource that is safe.  Attribute-based access control (ABAC) mechanisms reduce this vulnerability by compartmentalizing system resources.  Each resource request is evaluated against stored user characteristics and access control policies for the requested resource.  If the user characteristics don’t match the policy, access is denied.  When using advanced interface definition languages such as Apache Thrift to support ABAC transactions, the additional system overhead incurred by the increased security is surprisingly small.

It isn’t that the advantages of single sign on (SSO) and ABAC aren’t understood by the acquisitions community.  Modernization and sustainment are bread and butter activities.  The problem is that until comparatively recently, open-standards based tools to implement ABAC-enhanced security were either unavailable or prohibitively expensive.  (A good idea stops being a good idea if it costs more than living with a bad idea!)  Fortunately this is no longer the case and there are a number of off the shelf toolkits that can improve the security posture of existing systems in a manner consistent with industry best practices and guidance such as the IEA.

Examples of these security frameworks include:

License Type
WSO2, Inc.
Open Source; Apache
Oracle Identity Manager
Oracle Corporation
Open Source; CDDL

It’s worth a quick look at what capabilities these types of products provide.  The WSO2 Identity Server, for example, is a comprehensive identity and access  management (IdAM) solution.  It provides support for system and user identity management, access and entitlement management for both RBAC and ABAC, access control policy management in both versions 2.0 and 3.0 of the eXtensible Access Control Markup Language (XACML), and management and monitoring activities.   It is designed to offer the maximum of implementation flexibility; program and system architects can specify as much or as little of the tool’s functionality for implementation as desired.

So how do these tools fit into a defense or IC programmatic roadmap?  For starters, support for flexible implementation is critical.  Defense and intelligence programs have neither the fiscal nor scheduling luxury of completely re-engineering a system over single version change.  As a result, any improvements at an architectural level have to be implemented incrementally.  Tools that offer an all or nothing approach simply aren’t suitable.  This is where the current generation of IdAM solutions shine.  They allow for a one for one replacement of existing solutions while maintaining legacy security mechanisms and supporting the migration path to an objective access control capability.  Also, software licensing costs are no longer a dispositive factor.  There is little, if any, capability that proprietary IdAM packages offer that is not matched or exceeded by open source offerings.  Open source IdAM packages in general, and quite a few of the proprietary offerings, are based on open standards, helping to avoid vendor lock-in.

In sum, the modern cyber environment is hostile and dangerous.  This fact is not lost on visionaries and policy makers at the highest levels of the defense and intelligence communities, who have not only promulgated doctrine and guidance on the matter, but have also worked to expand boots-on-the-ground cyber-defense capabilities significantly.  Just as importantly, the acquisitions community now has options and a technical approach for markedly improving the security of existing defense and intelligence systems.