Where the rubber hits the road: Risk acceptance vs Risk Exception

One of the things you regularly get involved in as a CyberSec practitioner (sometimes several times a day) is an implementation of a piece of technology to enable a process wherein the technology is being implemented with less than the required security controls.

Now this comes from several factors: lack of planning on the part of the technologists, lack of understanding of security requirements, usually from lack of consulting with CyberSecurity resources to have them explained to them, or the most common, being “its too hard, lengthy or expensive to do, so we’ll just skip it. We are behind a firewall, so what can really happen?”

For any number of reasons in previous blog posts, this is wrong, bad behavior, and wooly headed thinking in a risk rich environment.

Some of this is tunnel vision: the business/technologist/auditor only sees the risk through the lens of their specific problem or regulation. That’s great if the risk can be isolated. But, often it cannot due to cost, time constraints, resources, and the underlying limitation of the technology.

CyberSecurity, however, when it is done properly, is about accessing risk everyday across the whole firm in every environment balancing one set of risks against another and the rewards that the firm wants to achieve. A complex job to be sure. In other posts, I recommend this be done quantitatively for the best results (“you can't manage what you can’t measure” and red, yellow, green are not measures) so that you can compare risks across the firm.

So, what does one do with a project/piece of technology and people that have gotten themselves into a risk corner for any of the reasons above?

If this project is large, its like a moving express train. Standing in front of it is, as my first and best boss (she knows who she is) often said, “is a career limiting decision”. It also, in the end doesn’t help the firm, as someone has put a lot of time, money and effort into project x, and making everyone go back to the drawing board is a waste of all 3. This falls under the old adage of “its much harder to turn around the oil tanker than to put it on the course from the start.” This project already picked the wrong course. Now what?

The other option is pretending risk goes away. It never does. In fact, it will fester. But, many firms “document” the risk with something called a “risk acceptance” form, file it, and do just that. They are surprised when a regulator calls them out this practice. They are doubly surprised when this vulnerability gets exploited. There is no royal road here, and working for a large firm doesn’t exempt you from common sense risk management.

Let do Audit it? Audit is really about process and rules and your compliance to them. Their job is to look at a specific control and process and see if you are following the process you have set out and applicable regulations. In that sense, Audit is examining at any one time only a very isolated subset of risk speaking to a particular control. They don’t, and it isn’t really their job at the end of the day, to balance that risk it against the risk of the firm. T

Report them to Enterprise Risk Management and let them deal with it? At the end of the day, Risk Management groups are keeping the risk registers of the entire firm. They are trying to report on risk in a consistent way so that everyone knows what they need to manage down to bring the overall risk of the firm down. This is hard enough to do without asking them to step into problems with specific data point of risk, or for CyberSec technical control failures. That is really your job as a CyberSec practitioner to fix/help fix specific control failures for specific technology.

So what is a CyberSec practitioner to do? The process is generally called risk exception. This doesn’t mean that risk is “accepted”, “exempted” or ignored. You are instituting a process whereby the risk is recorded, accepted by all, and you have worked with the business/technicians/risk holders to put mitigating controls into their process which will temporarily reduce the risk to an acceptable level so they have extra time to get to a secure solution. This is about the only factor CyberSec can work on, as we can’t get them more money or resources for their project.

Sounds simple right? Often it is not. Remember, you are dealing at the end of the day with people, process and technology. The last 2 are simple. The first one has personalities and different motivations from you. If we were appointed security dictators, that would not be a concern. But, at the end of the day, a lot of what we do is persuade, cajole and try to move the security culture of the firm in the right direction. You are trying to discourage bad security behavior, encourage the culture of security as part of the basic cost and foundation of a project. It’s something that needs to be thought of from the get go. Not bolted on later.

Risk is like money, but in a negative way. You want to minimize it, while maximizing the opposite, safety and security. That is not always an equation with one right answer. There are a range of outcomes you can live with.