What follows is from Chapter 20: "Strategy Development." To purchase the full book, visit this page.
There are certainly several ways to get from point A to point B -- and not always is the direct way the best one. It's important that you are capable of "thinking outside of the box" -- adopt your strategy to the situation at hand, and if the books tell you otherwise, think of what is the best and right way forward in the specific situation your company is in at this time.
Of course, doing the BIA (business impact analysis) first has a lot of wealth and will give you all the reasons you can think of why and where to spend the money -- but the reality is that a well done BIA takes a lot of time and requires (to be honest) a full blown process analysis, which rarely has been done before you joined the enterprise. It therefore may well be necessary to define the org chart (see above) and set policies in place (governance is highly important), even when you couldn't do the full analysis work before.
I had created the below shown approach in the past and have tested it in a real world setting -- the outcome was highly successful and therefore I share this here to help you. It is still aligned with the above mentioned COBIT processes, and from a 36,000 feet view, you will find the Plan-Build-Run-Monitor in all successfully run corporations. Feel free to adjust the given examples to your world and also to shift some items around where you see fit. An important point is to make an impact and improve the overall security situation as soon as possible. This will then build your credibility bank, which is quite important at a later stage when you need to leverage those relationships and trust.
This approach follows the basic steps of defining and building the right security organization (and may very well entail changes to the current org chart).
Set and approve the top level, detail the security policies (standards, procedures), and perform a process analysis, followed by an analysis of the supporting systems of those processes.
Comparing these analysis results with your policies (or at least vision) will provide you with probably many "audit" findings, which in turn lead to remediation projects. What you don't measure you can't manage, and to be able to manage your security program you therefore need KPIs (key performance indicators) or similar parameters which help you to analyze if your program is successful or needs adjustments.
Over time (including long term), these will serve your program to foster and stabilize the patient (the enterprise) and will prove that the investments have resulted in actual improvements of the risk profile. I provide several KPIs further below (see chapter 23 "KPIs -- A Few Examples To See If You Are On Track"). Finally, since the world spins around and technology develops quicker than ever, new risks will be introduced and will need to be addressed, so it is important to always keep a close look at the risk continuum and new developments -- maybe you need to adjust your organization, policies, etc. -- and there is your security cycle -- a new round of improvements.
It is important to understand that security is not a "project" of some kind but instead a long running process that will need change and regular reinvention to adapt to the ever changing threat landscape.
This leads into another important consideration. According to the SABSA (Sherwood Applied Business Security Architecture), and many other standards and best practices, security is about people (organization), process, and technology. In the past, many folks, and especially security product vendors of all kinds, have only focused on a tiny little problem and created point solutions which are often not even integrated with their surrounding technology stack.
To address the various layers of risk any enterprise has to deal with, I have used the following "security stack" and advise you to secure each and every layer accordingly and with the same kind of attention and time effort. Not addressing any one of these layers for whatever reason will basically leave the back door or windows wide open while you may have put high walls and automatic machine guns at other spots. You have to ingrain security at each layer or your program will fail, guaranteed.
In the following diagram I have put some examples on the right side of what to deal with at the various layers. Starting with the TCP/IP levels, moving through the additional OSI model layers, including virtualization and compartmentalization, also incorporating the users (including administrators), their processes and changes, along with the organization and processes via the management layer, and finally we reach the top layer, and let's face it, that is money in each and every organization.
It is always a business decision of how much money you want to spend on a certain problem. The outcome is basically "you get what you paid for". Or put differently -- to make you smile a bit -- the organizations that have been hit by security breaches in the past and those that will be hit in the future simply have not put the right effort, money, management support, authority, and all the other items discussed in this booklet into the security process.
