A few months ago during a conversation at a secops event, the topic of granting exceptions came up. One of the attendees was shared his dismay. “Management is always steamrolling me” he complained, “people are just being lazy, they should be able to do it right” and added “if it were up to me, I wouldn’t give any exceptions!”
I can empathize; even given recent trends, security is still often thought of as a necessary evil, a blocker to get past as quickly as possible. This is no good. If you’re a blocker people will avoid dealing with you; you won’t find out about things until its too late to fix, be forced to accept the risk and be held accountable if that risk materializes.
I take the opposite approach, I grant exceptions freely and easily. I strive to present myself (or my team) as partners and aim to create a culture where we’re not seen as blockers. The goal is to bring value to the company by managing risk and more often than not that means accepting it. This requires a bit of bravery, you as a security professional must personally accept that risk. It means that yes, occasionally that risk will materialize and you will need to defend your decision. However, by presenting security as a partnership as opposed to a blocker, will will gain more visibility, you’ll be able to document and track threats, better prioritize remediation and get a chance to mitigate as well. In short, you’ll be more effective.
Imagine an engineer needs to expose a DB to the public internet so that an ETL job can run and executives can get their dashboards. You can say no or demand the engineer rearchitect. This may work, but now the dashboards will be delayed and it will be your fault. Or perhaps the engineer will escalate, you’ll get steamrolled and then just have to hope that nothing goes wrong. Instead if you work with the engineer you can mitigate. Allow a public facing DB, but ensure authentication is setup correctly and lock down the firewall so it only allows from the specific service the ETL needs. Next time the situation comes up, the engineer might approach you earlier and you’ll end up with a working (security approved) pattern that can be used again and again. This scenario may sound like its right out of an ivory tower, but it’s not. This exact scenario happens all the time.
Naturally there are always situations where exceptions cannot be granted. You can’t just break the law and there are many situations where you “can” be as much of a blocker as you’d like. Banks, government and medical device companies have a much higher tolerance for “dealing with” security. Still, even if you are unable to grant an exception, adapting a partnership mentality, helping to brainstorm solutions, encouraging consultation early on in the process and explaining your rational will make you more liked in your company and will make your job easier.
I have a colleague who was once approached hostilely by a high level and influential executive. The executive accused him of “blocking” the project and threatened to have him fired. My colleague turned this into a constructive conversation, explaining first that breaking the compliance regulations would have devastating effect on the entire company, resulting in the loss of not just this one project but others as well. He pointed to examples of how within those constraints, his decisions and policies were geared toward moving things forward. He showed his commitment to help achieve the goals of the project and the company and to adding value. At the end of the conversation he had gained an ally, the executive thanked him for putting the company first and sent an email to her staff showing her support, reminding them that security was not optional and that the staff would have to play ball.
This is a new world for security. We have the opportunity to provide real value for our companies and customers. Security, while once seen as a cost of doing business is now ammunition for sales and marketing teams. By presenting ourselves as partners we reduce risk, improve visibility and gain allies.
Top comments (0)