Questions in Advance of the Bradley Manning Hearing

Next week’s military assignment of accused leaker Bradley Manning promises to be interesting at many different levels, with defense and prosecution sparring in the press over witnesses and legal strategies. Putting aside the political and legal aspects, we will be watching this closely to see how much of a role access management plays, and to find some answers to questions that are relevant to us as practitioners in this space.  Specifically, did the Army know what classified information Private Manning had access to? Would they have been able to effectively restrict his access to it, had they chosen to do so? Did they try, and fail to prevent this? Was there a sufficiently well-thought out and well-executed data security strategy in place, for this sensitive information?

According to publicly released defense documents[1], the Army was not doing an at-all adequate job in securing the data resources on shared, secure systems  – one of the witnesses “will testify that the information assurance procedures were not being followed by the brigade” and that “the brigade did not have an Approval to Operate (ATO) or an Interim Approval to Operate (IATO) for their network. Additionally, the brigade did not receive a formal IA [Information Assurance] certification and accreditation inspection during its tour, contrary to the guidance in MNF-I Directives”[2].

Like many of the enterprises I speak with, this organization had both internal and external information security guidelines, and was not doing a good-enough job meeting them. Could an effective Access Governance solution have prevented these leaks from occurring?  This certainly appears to be the case, and we look forward to learning more next week, as the hearing begins.

[1] DEFENSE REQUEST FOR ARTICLE 32 WITNESSES http://www.wired.com/images_blogs/threatlevel/2011/12/Defense-Article-32-Witness-List.pdf
[2] ibid, page 9

Account versus Entitlement Reviews (part 2)

Continuing from my previous entryon this topic, I’m continuing the discussion  about different approaches toward capturing user entitlement information, specifically considering the merits of doing so at the account level versus at the entitlement level. Typically, having a system that provides more insight into the details of which application (or data) entitlements a user has is better – so that the appropriate people in the organization can make better, more informed, and more granular access decisions.

But, in two scenarios, it does make sense to capture and use data just at an account level. The first situation is in a period of transition – where the organization may not yet have the infrastructure or capability to capture, normalize, process, and present detailed entitlements to reviewers (or to users requesting access).  This is a perfectly fine approach, and can be quite useful as a way to put in place business processes for review or access request, and to begin to familiarize end users with them – as long as there’s a concrete plan to ultimately move to reviewing and requesting at an entitlement level. These shouldn’t be left indefinitely at an account level – it simply doesn’t provide enough visibility or control, isn’t audit-proof, and will likely lead to a false sense of security.

The second scenario is when the information about an account’s existence is in fact sufficient for its designated purpose.  For example, one of our customers keeps track of which employees have accounts on their mainframe system. None of the applications on the mainframe are subject to entitlement reviews, so they don’t need to capture the entitlement details. Instead, they use the account information as part of their Leaver process – so that when a person departs the organization, IT has a clear view of whether or not a mainframe account needs to be deprovisioned, and can act accordingly. This is a simple, yet effective scenario, and a great example of the value of having an Access Management Database (XMDB) with complete information about identities and access, even beyond traditional focus of access governance systems

In general, of course, organizations need to capture and operationalize with a detailed view of user entitlements, in order to meet their access-related security and compliance goals.

Great Reporting by Wired Magazine on How False Illinois SCADA Attack Came To Be

Here’s a terrific, clear article from Wired Magazine, explaining the series of events and mis-steps behind last week’s erroneous report and subsequent news maelstrom on the (fictional) Cyber-attack on the Illinois water-control system.

Even though this turned out to be a simple mechanical failure, and not a cyber-attack, we must keep in mind that these SCADA systems have in fact been breached successfully (see my blog posting below), and must strengthen our security accordingly.

FBI: Hackers *Have* Accessed City Infrastructures via Compromised SCADA Systems

According to the FBI Cyber Division, hackers have accessed the SCADA (Supervisory Control and Data Acquisition) infrastructures in 3 major US cities. As reported today in Information Age, the FBI’s deputy assistant director stated that 3 US cities have recently had SCADA systems taken over by hackers.

Fortunately these hackers did not cause any damage, but this certainly does raise the profile and the risk associated with such industrial control systems.  Please, take the time to make a baseline assessment of your infrastructure, and get clear visibility into whether you have these kinds of industrial control systems, and who has access to them.

Was this related to the alleged Illinois SCADA compromise? According to Information Age, the FBI speaker “would not clarify” whether it was related.  However, I believe that we need to take at face value yesterday’s assertion from the FBI and the US Department of Homeland Security that no intrusion  occurred in Illinois, at the Curran-Gardner Public Water District.

 

Take a Deep Breath – The Alleged Illinois Water District SCADA Hack Did Not Occur (But, Put In Place a Thoughtful Security Program — Now)

According to the US Department of Homeland Security’s ICS-CERT (Industrial Control Systems Cyber Emergency Response Team), “ICS-CERT and the FBI found no evidence of a cyber intrusion” and that “there is no evidence to support claims made in the initial Illinois STIC report…that any credentials were stolen, or that the vendor was involved in any malicious activity” [1]

While this is a relief, it’s distressing to see, based on commentary and media coverage, how vulnerable these industrial control systems apparently are.  And, in a bitter irony, the coverage and attention raised by what turned out to be a media event (as opposed to an actual security event), will in fact raise the likelihood of future attacks on industrial control systems.

So, organizations with these kinds of control systems in place — please, do two things, immediately:

  1. Read through the Department of Homeland Security document Recommended Practice: Improving Industrial Control Systems Cybersecurity with Defense-In-Depth Strategies
  2. Evaluate and improve your access management systems, to ensure that you have an effective program enforcing the principle of least access.

[1] http://www.us-cert.gov/control_systems/pdf/ICSB-11-327-01.pdf