- Last Week As A vCISO
- Posts
- One Size Does Not Fit All
One Size Does Not Fit All
Rules can sometimes be bent, but there's a way to do it.
“What you must learn is that these rules are no different than rules of a computer system. Some of them can be bent, others can be broken.” - Morpheus (The Matrix)
Rules, laws, and regulations are all things that are there to help keep order and maintain some sort of consistency among complex systems.
However, sometimes one size does not fit all.
That's where exceptions come in. Exceptions are mechanisms that allow the "bending" of rules to fit the situation. We have them everywhere in society.
Here are some examples:
Judges in court sentencing
City clerks and administrators with citizen requests
Police with traffic stops
Parents and Family with children
As you can imagine, without exceptions to rules, we would be a society of machines.
Exceptions In Security
Just as in life, security is not without its exceptions.
For example, this can be an exception to:
Processes
Requirements
Policy
Standards
With most exceptions however, there does not need to be a reasonable business justification for such an exception. It’s security’s job to communicate the business risk and industry guidance/expectations to the business for them to make a well rounded and informed decision.
When To Make A Security Exception
The basics of a security exception is when the negative impact to the business of a security process, policy, or requirement exceeds the security value provided or intended.
Exceptions are not rules. So if an exception needs to happen on a frequent basis, then the process / policy / requirement may be broken and needs to be addressed. Taking a holistic view at why these exceptions need to be made is required to reduce future friction and the need for exceptions.
How To Make A Security Exception
Now that we’ve established how to understand or recognize a security exception, the process of making an exception is quite important.
Have An Exception Process
Kind of goes without saying that you need to have an exception process in the first place, but you would be surprised how many companies don’t have a formal exception process. Start by figuring out who is authorized to make or sign off on an exception. This will determine a lot in and of itself.
Document The Security Exception
Make sure to document in clear terms why the exception is being made. Your exception should hold water in the event someone else looks back on it and want to understand context. The more documentation the better.
Add An Expiration To The Exception
Sometimes the business needs to act quick and get something done. Although you may be giving them an exception, it doesn’t or probably shouldn’t be permanent. Hold them accountable and ask them when they can get the resources in place to do it the right way.
Tip: If the security request/exception is being made via Jira for example, file another ticket for the expiration of the exception for tracking.
Ask Questions. Figure Out The “Why?”
Try to find out why the exception is being made. Take this as an opportunity to learn more about the business and the people involved. This is an excellent opportunity to show that security can be a good business partner as well as communicate the security rationale behind the process / policy / requirement.
From my experience, getting the business on board with the context of the security mechanism goes an incredibly long way and has resulted in the business coming up with security solutions on their own.
Security Exception Summary
Making an exception is not anything to be concerned about or embarrassed about.
It’s a part of life.
I have encountered security teams that didn’t have a security exception process or were not willing to budge on their requirements. This just ended up with frustration from the business on both sides of the issue. That can be between two different companies or two different business units internally.
The hope is that following some of the above guidance will reduce frustrations all around.
Reply