If you have real world experience implementing security governance practices in an organisation, the thought might have come to you; “There has to be an easier way? Why is this so hard?"
So in the interests of some chuckles for the experienced, and enlightenment for those new to governance, here are some common "bright ideas" and their real world implementation.
We just need to write a security policy and check compliance with it!
Real World Experience: Developing draft security policy and standards is easy, just identify the compliance requirements and align them to the business operations in the form of standard statements. Now try getting it endorsed! You will have to wrangle grammar via committees or focus groups— and beware of "watering down" the standards so far they become useless—and then manage expectations of performing in-depth analysis on the cost/impact of implementing the standards.
Once that battle has been fought comes implementation. How do you assign the statements to stakeholders in order to implement them throughout the organisation? Only once you have informed all the stakeholders sufficiently of their obligations, and they have implemented appropriate controls, can you start to check compliance. If you start by doing a wide ranging gap analysis before implementation, you may just put everyone offside from the beginning. You need to post a speed limit before you get out the radar gun!
All we need to do is identify all of the information assets, then identify the associated risks, then we can select cost effective mitigating security controls!
Real World Experience: Aha, the risk-based rather than compliance-based approach! Maybe you can find a list of all the servers and network devices in your organisation? But I challenge you to find an accurate database of which applications are hosted on that infrastructure. It always is claimed to be in a "CMDB" or similar, but when you go looking for it, it’s nowhere to be found. So what are the contents of each database? Is there data shared between databases/applications? And here's the real challenge—try and find and identify all of the access databases, spreadsheets and word documents scattered across multiple file shares/servers and document management systems. It's likely that some of the most sensitive information in your organisation is sitting in your executives’ voicemail, or their inbox, or My Documents folder.
It's likely you’ll need to drop some serious coin on a discovery activity using Data Leakage Prevention technology to be able to even get a picture of what data your organisation is working with. A good first step is putting in place a data classification scheme and a mandatory requirement for data classification of new documents—perhaps in your main document management system. Then uplift the security controls on your document management system, use your "knowledge management team" to educate personnel to store all of their documents in it.
All the risk is in existing systems and processes! All we have to do to focus our security program on the important things to identify all of the critical business processes and critical applications
Real World Experience: How often is the main business process responsible for all of the company's profit documented? Almost never, unless the organisation is heavily regulated. (Note the distinction made between revenue and profit. You can lose revenue and survive through some "right-sizing", but if you lose profit you're dead in the water.) See MCI Worldcom for a good example, they had massive revenue from one business unit, but when the tiny business unit providing the majority of the profit got into trouble, Chapter 11 proceedings soon followed.
If your organisation has undertaken a very involved modern business continuity program (BCP) you will have one of the best building blocks for a strategic security program already in place. A modern BCP program will identify key business processes and their importance to the organisation by documenting agreed recovery requirements. A BCP program is a good start for an information security program, but don't neglect non-critical business processes that deal with a lot of personally identifiable information or that may have a reputational impact.
Let's just try and risk-assess all projects, at least we can stop new risks being added to the organisation!
Real World Experience: What defines a project? Does your organisation have a Project Management Office (PMO)? If not, how are you sure that you have captured all of the "formal projects" across your business? The next challenge after this is the volume of projects, how can you sort the risky projects from the safe-to-ignore ones?
Looking at projects in detail, you may discover that the vast majority of required security controls are not implemented in a project, but inherited from the existing environment. The more advanced your security program is, the more security controls will be inherited.
A good start is to require project managers to complete a risk assessment on security governance's behalf, pushing the responsibility to them to engage with security governance if they have a high risk project. Another good step is to produce a methodology for quickly providing architects with relevant security controls they need to directly address in their design documents (e.g. use of a central identity management system) and key existing security controls they need to consider and integrate with (e.g. firewall rules).