Showing posts with label controls. Show all posts
Showing posts with label controls. Show all posts

Friday, May 08, 2009

A FAIR measure of defense in depth

Recently, the owners of a system containing sensitive information where I work began planning an upgrade to the latest available version. In addition to performance improvements and bug fixes, the new release also modified authentication and authorization processes. Compared to the current model, these changes would offer significant cost improvements in administration and support. But before flipping the switch, business and security stakeholders wanted to know “which configuration is more secure?”

To provide an objective answer to that question, we defined “more secure” as the configuration and support processes (i.e. security controls) that would result in the smallest amount of residual risk to the organization.

Initially, this looked like a simple consulting request from a business unit. Normally, the security team reviews the proposed security architecture and provides a recommendation. But long after the system upgrade, system owners and administrators will face new decisions that impact the security of the system. They needed advice and a full knowledge transfer on how security controls work together.

The Factor Analysis of Information Risk (FAIR) methodology makes this kind of analysis transparent by decomposing the analysis into lower levels of detail only as needed. In situations where the alternatives are very similar, FAIR allows an analyst to identify and focus only on the relevant differences.

FAIR defines risk as “The probable frequency and probable magnitude of future loss.” Given that we looked at two possible configurations of the same system, the underlying information value was equivalent in both situations, and the expected threats were also the same. So the probable magnitude of loss could only be determined by the controls, not by any differences in the underlying information. Since the FAIR framework structures the analysis in a hierarchy along impact and likelihood boundaries, an analyst can isolate the comparison to only the parts of the analysis to the subset of factors that are different. In this case, the focus was on control strength and control depth against the range of expected threats.

Using FAIR, we looked at the type and frequency of contact that threats would have with the system, their probability of action, and the number and strength of controls applied in each case.

In the end, the analysis objectively determined which configuration had enabled more layers of security controls that could not be circumvented by an attacker. (As an example of circumventing a control: logon banners may be required for legal reasons on certain systems, but an attacker may not interact with the system through those defined interfaces and thus circumvent the control. The AOL mumble attack is another.) And the threat-oriented focus provided a context for evaluating future system changes: owners, auditors and security team members now share a common understanding of how control changes add or remove layers of protection between threats and assets.

Eventually, we wound up with a reasonably portable security metric for comparison: defensive layers per threat vector.

It’s not the number of controls or compliance gaps that determine the security of a system, but the strength and depth of that protection that attackers can’t sidestep.

Tuesday, February 10, 2009

Change as a catalyst for security

IT Budgets are expected to be flat for just about everybody in 2009; IT security spending will likely be the same. After years of relatively strong management support this may seem like a setback, but I’m convinced that the proverbial glass is still at least half full.

Even if new security technology rollouts are being delayed, that doesn’t mean the entire organization is standing still. Management faces pressure on revenues and costs, and they’re going to be very active pursuing any and all strategies to make improvements in both of those categories. These pressures are going to drive change, and change can become a powerful catalyst if you can influence the organization to address security issues opportunistically.

There are two keys to an opportunistic security strategy: first, a thorough understanding of the gaps in administrative, technical and physical controls across the enterprise. And second, an equally sound understanding of how to produce better security as a side effect of operational improvements.

As an example, the Visible Ops Handbook describes high performance organizations which have gained control over their change management processes, boosting efficiency. More importantly, “by putting in controls to find variance, they have implemented preventative and detective procedures to manage risk.” Security is a side effect; an externality of operational improvements.

The output of security control gap assessments effectively becomes a shopping list for an opportunistic security manager. Once you start looking at security as a positive side effect, there are at least four main opportunistic strategies available:
1. Attrition: retire systems with known gaps. Network gear with password length / strength limitations? Applications on end-of-life operating systems? Security won’t drive these retirement decisions – but it makes a good tiebreaker.
2. Relocation: consolidate critical systems from environments with low control coverage in areas with better protection capabilities.
3. Extension: broaden the asset base addressed by compliant platforms as an overlay, reducing configuration diversity and streamlining support costs.
4. Outsourcing: When transitioning, fully document procedural controls that were informally implemented, but not consistently.

Visible Ops describes the mechanics of strategies 3 and 4, but in a different context. They’re two instances of a common theme: quality and control make a strong foundation for both security and cost efficiency. Some organizations will be better positioned to take an opportunistic approach in 2009. A lot depends on the manager, but there are other factors that will also play a significant role:
1. Metrics maturity: does the organization have an objective view of control coverage and control strength?
2. Communications: Accountable system owners and project sponsors need to be aware of the current state of protection, and the expected effects (benefits) of proposed changes.
3. Line of sight to business objectives: how does coverage and exposure impact profit and loss?
4. A significant volume of organizational change.
5.Operational flexibility and creativity
to modify projects, ensuring that opportunities to improve security are incorporated.
6. Continuous improvement: once a change has been made, capture and replicate it. And just as important: make sure that subsequent change in these environments do not reopen old vulnerabilities.

“Progress, of the best kind, is comparatively slow. Great results cannot be achieved at once; and we must be satisfied to advance in life as we walk, step by step.”
--Samuel Smiles [Scottish author, 1812-1904]