Like
the majority of cyber security professionals in the world, I can't
help but to reflect on the recent major beach of US government
personnel files from the Office
of Personnel Management.
While
the government has made strides towards unifying the security
postures across agencies, with efforts like the DHS Trusted Internet
Connection initiative, as well as advanced technical solutions like
the EINSTEIN 3
Intrusion Detection System; I feel that a more fundamental form a
remediation is necessary.
Security
can be compromised by ambiguities and shortcomings in the guiding
standards. A recent GAO
finding pertinent to reports of FISMA compliance associated with
use of the previous version of SP 800-53 indicated disconnects
between FISMA compliance reports and agencies' actual security
posture (M.E Kabay 2009 – NIST
800-53 is essential in federal government IT systems). I'm
here to say that his ambiguity still persists in SP800-53, Revision
4.
We
(our government's Infosec leaders) need to rework information
security strategy from the ground up, by creating a clear standard
which allows our numerous agencies to elevate their security postures
rather than creatively word-smithing their existing procedures around
unclear security controls. Although not perfect, commercial standards
such as the Payment Card Industry Standard (PCI-DSS version 3.1) have
addressed this issue well. The end result of a PCI assessment
generally leaves the subject knowing 3 things; We have this control
in place, or We do not have this control in place, & finally
we'll have to implement X to become compliant.
Of
course there are always multiple technical shortcomings that factor
into breaches of this magnitude, however ultimate remediation starts
from the bottom of the stack. The integration of commercial products
and personnel, in the form of government contractors, have long been
a strategy embraced by the federal government. This approach has not
been applied in the development of 800-53, or at least not done well.
Not to totally discredit the standard, it was definitely a forerunner
of the majority of regulatory compliance standards, and implemented
correctly addresses the vast majority of all security risks. However,
I do feel that in this case less may be more. Collectively the NIST
standard is comprised of over 950 individual controls, turning
something that actually isn't rocket science into an exercise which
I'd rather just build a rocket instead of performing.
Removing
some of the complexity and red tape which is not aligned to true
risk, will allow agencies, and commercial organizations alike to
concentrate on the basic shortcomings that cyber criminals target and successfully compromise again, and again....
While I agree that compliance standards are vague and that issue should be addressed, I don't think that is the root of bad guys getting root.
ReplyDeleteClosing the compliance gap (moving the needle from 0% compliance towards 100% compliance) gets increasingly difficult the closer to get to 100%. There are also the issues of accepted risks, legacy apps, etc that make closing the gap to 100% impossible. Add to that the problem of exploitation of the human factor and other non-technical vulnerabilities. At some point an organization realizes that closing that gap is too hard and stops trying to drive compliance to 100%, leaving some amount of exploitable gap.
This leaves the defender is the position of always having some amount of exposed attack surface for the adversary to target. The problem focus then shifts from Protect (compliance) to Detect. Official guidance in the Detect arena is generalize...things like run anti-virus, deploy IDS or IPS, use some kind of host security tool, monitor logs. The Detect problem is hard for many reasons, including adversary pre-testing of attack methods against known commercial tools, weak guidance on how to properly monitor, defender's getting overwhelmed by the massive volume of events coming at them, the variety of attack methods, and the list goes on.
Current approaches to the Detect problem tend to revolve around threat intelligence based network defense. This is useful, but often revolves around tracking IP's, domain names, hashes, registry keys, mutex, and other disposable indicators. Very quickly the defender is drowning in threat intel, struggling to deploy watchlists, and determining what indicators are most reliable. At this point the defender ends up needing to better integrate their tools and intel. Once again, the problem shifts to something new.
The important thing to note in all of this is that as an organization goes through the process of maturing their defensive approach, the current problem of the day shifts to a new area. You end up going through a progression of problems as you mature. You need to understand that and structure your team and approach around moving through that progression as quickly as possible.
This requires having some serious technical talent on your team to drive through that progression and a common vision of how all of the interrelated pieces of the security system (platforms, people, processes) will work together. The people have to be strong in the technical arena so that they can jump between all of the systemic areas to attack the problems.
Bringing this all back around to the OPM hack, I suspect a major challenge that was at the core of this series of compromises over more than a year period was a lack of strong technical people with the authority, access, and financial resources to tackle these kinds of systemic issues. A hint that this was the case is that leadership didn't appear to fulling appreciate that they were the target of a major campaign going after their data. They had warning signs that this was the case but didn't react like they recognized the signs. So systemic failures occured. Most tragic incidents involve multi-factor, system failure as was the case with OPM, Target, the Challenger disaster, BP oil spill, etc.
a friend from your past ;)
Only a couple friends from my past could make those point so eloquently! I think you're spot on. You definitely captured the complex landscape we are challenged with managing.
ReplyDeleteGood luck to you, and keep in touch!
I think your last email address changed before I replied to you within the last few months. You can try shooting me an email here. (first initial last name at cox dot net) MS
ReplyDeleteThe suggestion to email me is from the old friend from the past, not a spambot.
Delete