Security Process Improvement
At the opposite end of the transformation continuum from compliance and control regimes are security process improvement methodologies, which take a more systematic and holistic approach to security transformation. Instead of the narrow perspective of compliance, which defines what an organization must do, security process improvement takes the perspective of how an organization should do things and lets the resulting process drive appropriate controls and compliance efforts. ISO 27001, an international standard for information security management, is probably the most widely adopted of these approaches, with thousands of implementations worldwide. But other frameworks, most notably the U.S. Federal Information Security Management Act (FISMA) and the supporting guidance created by the National Institute of Standards and Technology (NIST), also enjoy a great deal of support.
Security process improvement frameworks like ISO 27001 and the NIST Special Publications do not attempt to force a prescriptive, controls-centric security framework on every organization, subject to standardized, recurring audits. Both ISO 27001 and FISMA do have an audit component, but the fact that many enterprises voluntarily implement the international standard or the NIST guidelines best practice architectures for their InfoSec program is telling. These organizations may never undergo a formal audit of their program, but they recognize ISO and NIST as good ways to "do security” nonetheless.
I am a proponent of ISO 27001 and of the process improvement approach it and NIST promulgate. When implemented properly, they offer a comprehensive blueprint for security that demands leadership buy-in, thoughtful analysis of what the organization actually needs in terms of security, and a risk-based selection of controls that work best for the enterprise, rather than satisfying an external party imposing a one-size-fits-most list of "necessary controls” with little associated context or nuance. An unfortunate problem is that many organizations don't implement security process improvement frameworks correctly and manage to turn them into just another checklist of controls. This is especially frustrating to me as a certified ISO 27001 auditor when I see an organization take the standard and skim over the main body before latching on to Annex A, a list of possible controls the organization may select from. We're so used to thinking of security in terms of controls that we're sometimes conditioned to ignore everything else.
Another limitation of the security process improvement approach is that it can be difficult to implement incrementally. Whether you are facing an audit or not, both ISO and NIST tend to assume a static InfoSec program, a complete system that must be either augmented or created. This tends to require a top- down implementation directive, usually mandated within a finite time frame, rather than a process that is gradual and organic. In the case of ISO 27001, the result is that organizations regularly choose to limit the scope of their information security management system (ISMS), perhaps to a single data center or enterprise application. Making the ISMS apply to the entire organization at once is perceived as being too difficult.