I love helping security teams measure control performance (metrics) and improve risk analysis and management programs. Providing visibility into current performance and putting the data in context of business goals helps improve decisions. What happens when the executive team doesn't want to know, how about they know but refuse to make a decision, or perhaps they make a decision that's obviously not defensible if an incident ever went public?
Some security teams have formal job descriptions to provide information security governance. To me this means they provide visibility into performance, help define performance expectations, and facilitate decisions when expectations aren't meant. However I've seen these teams pull their hair out because the control owners or decision makers prohibit or resist supporting their mission. Sometimes the resistance is reasonable e.g. too busy, sometimes it's political e.g. don't want to look bad. Either way it puts the security team in a pickle. Do they swim up stream, grab the data, and report to the Board without the control owner's support? Do they perpetuate the situation by going through the motions of spot audits without closing the loop on findings? If there's no mechanism for you to exercise or establish a governance process, should the security team become a whistle blower or take a complicit role?
I started thinking about analogs outside IT. Most are too controversial so how about the recent Rutgers Controversy? The basketball coach abused his players over a long period of time. I don't think the NCAA has a compliance check-list of "do not abuse players" so it probably wasn't a compliance failure. However I believe there are governance processes to protect the welfare of students. So when governance failed it took a whistle blower to leak video evidence to the public. + 1 for social media. I assume some accountable group e.g. Board of Regents, is seeing how far up the ladder the negligent decision making went.
Now I'm not equating control owners who ignore obvious control deficiencies to abusing players or any other situation that requires a whistle blower. I know many devs and IT ops folks and they love their children too. But the pattern is pretty interesting. How can the security team fulfill their governance function without being a whistle blower? It's a tough question and I don't have all the answers. I am happy to share my experience and what I've observed to work well.
- Baby steps: whatever path you choose to improve visibility and encourage treatment decisions, take it slow. The business hasn't collapsed or may be doing just fine. Highlighting deficiencies when there isn't evidence of impact might get you a spot in a dark corner.
- Create the risk story: If you're measuring something irrelevant to the business, you're done. Create a well formed story across the potential impacts and their frequencies related to your control data. Much has been written here about framing risk so I'll move on.
- Relationships: Obviously support for governance is a top-down culture issue. Get to know the decision makers and control owners. Earn as much goodwill as possible, you'll be making withdrawals soon enough.
- Bottoms-up: Consider working directly with a control owner you think will support you before blowing any whistles. Understand their situation and emphasize with their position. If you have experience in ops you'll have a much easier time. See if you can get them to emphasize with you! There's a reason why things got the way they are. Include the background when you tell the risk story. See if the control owner wants to cooperate in a solution or prioritizing the solution against their backlog. If these efforts fail, time to...
- Move up a rung: If the control owner won't play ball, contact their boss in an informal setting and ask their advice. Every manager knows what you're doing and will respond in an overt or covert manner. It's unlikely they'll just ignore you. Let them know the story will be told and you need their support. If you're fortunate, you'll be able to associate your risk story to an objective important to the control owner. If not, time to communicate with someone who has an objective associated with the risk, the...
- Business Owner: Much has been written about mapping control performance to the biz e.g. my What Matters To You post. If your story falls on deaf ears or you get smacked down, you're getting closer to the whistle.
Internal politics are snowflakes and the above might be exactly wrong for you. However I hope the above inspires some ideas. The ultimate answer is a governance process that reports to an accountable group outside dev and IT. The trick is to create a process that partners with the control owners. No one likes surprises, especially when they make you look bad.
On a positive note: if you have no choice but to blow the whistle and it falls on deaf ears, there are plenty of businesses looking for your skills and experience. Please share your stories or correct my thinking in the comments. Or contact me directly if you need an empathetic ear.