When is a security program not a security program? This is a question I have been pondering lately, and I have an idea to share and debate.
First off what is a security program, and how do I define it? A security program for this purpose is one that operationalizes the orchestration of information security functions. It is constituted by both a documented structure of documents, and implemented technology processes. An example of a starting point for companies is ISO 27001. Now I am a proponent of creating a custom control framework, as reinforced by my book on this subject. I do though believe that such programs can be formed using such standards. Will an organization grow beyond, of course.
On to the question at hand…. When is a security program not a security program? It is when one is built in form and not substance or substance and not form. Yes, that is correct. Both are valuable and necessary. The form of a program is required to support efficiency, consistency, coverage, and visibility. The substance is necessary to provide effectiveness, compliance, and this little thing referred to as security in the common industry.
The challenge is that many organizations develop policies and procedures that mimic standards, but are not operational. This is especially prominent in U.S. Companies if one empirically bases this on the number of security certificates issued based on ISO. Though this is also supported by years of client engagements. It is one thing to have policies that have the same table of contents of ISO 27001, and quite another to actually have the program deployed.
This creates a mental challenge for many leadership, as according to the surface…their policies are “aligned” with these global standards. Conveying the difference and importance of each is critical for businesses as we move forward in 2011. How one might ask?
I would propose the following logical flow:
1. As in everything good, the truth shall set you free. Sharing the real risk is pivotal. Everyone has the same desire – to be part of a great company, enable them!
2. Bring management into the process. This is a fundamental aspect of the ISO 27001, start small and communicate.
3. Be great… Following the lowest common denominator for industry technology deployment, products, customer service, and security is silly. Lead.
While the above are philosophical, I feel that in this point in time we need a bit of an adjustment of perspective. Other thoughts?
I will be speaking in San Francisco next week at RSA on PCI, and looking forward to seeing everyone live and in person.