Cybersecurity Exceptions - Part 2

As I mentioned in my previous episode, there’s much more to discuss on cybersecurity exceptions, such as the risk they pose to the organization and the hidden dangers of cumulative risk.  

Exceptions to any cybersecurity policy or standards must be reviewed and approved by management, and this will vary by organization; however, a good rule to follow is the basis on residual risk, for example: 

• Very high: Senior Vice President 
• High: Vice President 
• Medium: Director 

• Low/Very low: Senior Manager 

Your organization may have different titles or a three-tier risk level (high, medium, and low) instead of a five-tier level. It is also vital that two individuals sign off on the exception, the requestor’s management, following the same residual risk-based process, and the cybersecurity leadership. The only difference is that the cybersecurity leadership would have the veto power to deny it.  

As with any request asking either not to follow a cybersecurity control or to use alternative methods that bypass or weaken the controls designed and selected to protect the organization’s system, vulnerabilities in the environment may appear. Exceptions, such as: 

• Extending the retirement of the system reaching end of life status 
• Postponing the patching of production systems, or 

• Asking administrator access to workstations 

These exceptions must be evaluated under the context of the most valuable assets in the organization, identifying the crown jewels and business-critical systems and how the exceptions you consider will directly or indirectly impact these assets. For example, Malware outbreaks on the crucial business system rather than crown jewels or business-critical system should not be risk-rated at the same level. A technical person will see these as high or very high from their perspective; however, the tangible and intangible resources, capabilities, and processes were not affected from a business perspective.  

Now, I must admit, this statement alone can generate some heated discussions with powerful arguments going either way, but you need to keep focus that you are not going to stop every attack. That should not be your goal, but rather business resilience, so risk-rate accordingly. 

The other challenging topic is cumulative risk triggered by cybersecurity exceptions. Detecting cumulative risk is a challenge for businesses, as exceptions build up over time. There’s no easy way to identify effectively; however, that does not mean you won’t do anything. Start by identifying exceptions to your crown jewel and critical systems; list them in a spreadsheet or dashboard so that you can do further analytics. Depending on the data that you ask and collect from your cybersecurity exception process, the following questions should be asked from your data, at least: 

• Is there any specific cybersecurity control that has the most exceptions? 

• Is there any specific application receiving most of the exceptions? 
• What is the risk rating breakdown? 

The analysis of this data will provide you insight into potential cumulative risks to your most guarded systems in the organization.  

Could you ask more exploratory questions? Could you get more insights from the data? Could there be more variables? The answer is YES, but I want to remind you of the difference between theory and practice. Bre Pettis, the founder of Makerbot, and Kio Stark created the “Done Manifesto,” which contains 13 maxims to bring a vision to life. Rule number 6 states, “the point of being done is not to finish, but to get other things done,” while rule number 8 states, “laugh at perfection. It’s boring and keeps you from being done.” 

Your findings will go through several managerial layers with reviews for accuracy, language, tone, and message impact before it can be called finished. So, collect the information, use these facts in your risks discussions, and challenge risk owners. 

I want to leave you with three final thoughts:  

• First, focus on the crown jewel and critical systems  
• Second, identify the patterns in your exceptions related to my first point  
• Third, leverage your findings as an input to your risk register discussions. 

Next time, in part 3, we will discuss exception tracking and expirations.