I’ve spent more hours than I can count studying compliance and governance. Reading and re-reading PCI requirements, Sarbanes-Oxley law, theory, and applied theory. Spent mind-numbing hours combing through BASEL and BASEL II docs. I’ve spent many long weeks with external auditors, internal auditors, assessors, risk management personnel, corporate governance officers, and government officials – trying to understand their jobs, their roles, and how the world functions from their perspectives. I’ve spent months mapping those ideas and processes into policy implementations, process modifications, and the rules that actually enforce policies. I’ve written audit reports for these various compliance and policy management frameworks to demonstrate policy compliance and efficacy. When you sell security and risk management software these efforts are necessary, because compliance drives your company’s revenue. So I feel I understand policy and compliance pretty darn well, but I am bothered by the trend toward policy being the focus – at the expense of the task it was originally designed to govern.

I got started on this thread during a review of an instructional “how-to” on the secure-software development lifecycle (SDLC). The more I read of this SDLC description, the more I realized that it was not SDLC at all. It was a risk and management process to gauge the effectiveness of the SDLC program. It contained next to nothing on SDLC itself! There were very few instructions on tools, processes, or things you need to know to actually develop under an SDLC – just management and policy oversight. Don’t get me wrong – risk management and development management policies are very important for SDLC. When we track and monitor we get a better idea of whether what we are doing is having a positive effect, weigh the relative merits of different types of security efforts, and over time learn whether we are getting better. But policy and management are not for the sake of policy and management – they only exist to ensure the core effort (in this case SDLC) is actually working.

I find that a lot of this stems from people developing policy when they have never done whatever the policies are meant to govern. And sometimes that’s okay. It’s not a requirement that you have developed code, managed teams of developers, or been responsible for process development to comment on SDLC and SDLC governance. But without that experience in whatever practice you are trying to manage, efforts to improve it rarely work out well – the policy mindset does not mesh well with the development mindset. Agile programming even has a name for these people: chickens! From the parable of Chickens and Pigs, the Chickens have lots of input but are not part of the actual process. And developers make this distinction because chickens can be detrimental to the process of developing software. This particular brand of chicken I usually call “policy wonks”, and I am convinced they do at least as much harm as good.

I’m pretty pragmatic. I prefer easy over hard, and when it comes down to it I just want to get my work done and move on. In fact all of us at Securosis are this way – Mike so much that he authored the Pragmatic CSO guide that remains in use and gets downloaded pretty much every week. Developers, if I can be so bold as to generalize on the culture as a whole, are usually anti-bureaucracy and anti-policy. It’s whatever works quickly and effectively. And I have this trait in a big way. But after years spent with policy development and compliance, gathering metrics and measuring outcomes, I know they actually are critical. But I keep running into people who only do policy, who only give us the (to steal a phrase from David Mortman) Utopian Policy Ideal, without any consideration whatsoever for actually getting $#)^! done!

Policy is to help us avoid repeating mistakes and guide us on how to get work done the way we want to get it done. But it’s not all about policy. Policy is not the work to get done. Are policy and governance important? Hell, yeah! But if we keep spending 50% of our time on this 5% of the picture, we will suck at the other 95% of the stuff that needs to happen in order to get things done. You know – real work.

Note from Rich: Adrian asked me to review this before posting so I thought I’d insert a line. This is my single biggest pet peeve in security today. Especially in cloud. Far too many people seem to want to be policy wonks and focus on GRC to the exclusion of actual security.

Share: