Overview
Over the course of the 3 decades of my career, I have designed, managed, inherited or advised on at least a dozen pieces of security infrastructure. What I’m going to try to do here is list out a few practical observations about how to operate them, specifically in the context of risk management. In no small part, this is because I have seen the same outcomes – either by act or omission – in more than one organisation.
This post is about what happens when policy, either set at the organisational level or manifest within the security infrastructure implementing a control, is telling you one thing, but for whatever reason, there is a requirement to contradict it.
Not all pieces of security infrastructure enforce control-oriented policy in the same way. At one end of the spectrum, there isn’t much debate about whether or not someone or some thing has been able to present an authentication credential or not. At the other end, the control may be telling you something of an advisory nature (rather than boolean) or it might be so fine-grained in nature that it is a million miles away from your department’s documented policies and standards.
And therein lies the problem.
Scope
What follows is a set of observations based on a mixture of experiences I’ve had working at different companies; it’s not a reflection on any one in particular. Security functions have to make practical decisions that can impact on the operation of security infrastructure, particularly based on the relationship they have with the corresponding technology organisation. I also don’t want to get too bound up in the definition of terms I’m going to use – again, these are open to interpretation from one company to another. By ‘security infrastructure’ I simply mean something that is used by more than one application or team. It could be inline (and blocking), it could be build aligned, etc. ‘Control’ can be a bit trickier to define. It could be a set of discrete elements associated with authentication. But it could also be much higher level: e.g., the implementation of a control requirement that specifies scanning your code.
Regardless of this variability, there are a few clear patterns that we can observe for effective operation.
Flouting the Policy
Every control applies and / or enforces some sort of policy. The more fine-grained the policy is, the less likely it is to be explicitly defined in a technical standard. In this instance, the ‘policy’ may not actually exist outside of the piece of infrastructure that implements it.
I’m going to draw on 2 examples. The first is where the control implementation is binary. More than 20 years ago, I ran the SSO service for a large bank. There was a constant debate over the (pre-federation) token lifetime which defaulted to 24 hours. Application business owners thought it was an impediment to their users.
The second is SDLC aligned tooling. The output of the scanning services was considered actionable, although in some cases (particularly for SAST findings), the findings tended to be more advisory in nature.
In both instances, there can be an organisational desire to flout the policy, for compelling business reasons: timeliness, viability of alternatives, etc. At this point it’s a risk management consideration which requires treatment in an auditable manner. This includes, in the longer term, deciding whether the 2 example issues are actually risks at all.
Policy Feedback Loop
It is critical, particularly in the early days of the operation of the control infrastructure, that there is a feedback loop to manage this. In the token lifetime example, it’s quite likely that you have an authentication standard which defines it (I’m going to ignore the potential nuances of doing different things for different risk classifications of applications). For the SDLC aligned tooling, your application security standard might say ‘scan code en route to production’. What it’s not going to tell you is how to deal with the minutiae of findings of the ‘this may be a cross-site scripting vulnerability’ type.
In the short term, if the development team says it won’t can’t accept the outcome, you are probably going to process this ‘risk’ via exception processing. Longer term, you need to have a feedback loop that is reflecting the fact that either the organisation has building appetite for changing token lifetimes, or thinks that an XSS finding for a certain type of application should not be actionable.
The feedback loop needs to trim and tweak the policy settings in order to reflect the security posture of the organisation, and do it in an auditable way. This may ultimately lead back to a change in the documented technical standards.
Control Effectivness
There is an inherent assumption in the feedback loop described above that the implementation of policy is doing what you think it should do. If analysis shows that it’s wrong, you need to fix it in a way that doesn’t involve the developers or their management in some administrative toil.
The Role of the Risk Register
In my experience, the risk register is an area where I’ve seen the most operational variability. In organisations with the most mature security programmes, it really is just a place for exceptions: something that requires senior technology approval where there is a clear rationale to diverge from accepted operational parameters – e.g., because of timing related issues, viability of the alternative etc. If you are jamming ‘sign-offs’ into the register simply to get a project over the line, yes, it’s fulfilling the requirements of an auditable outcome, but it may not be the best use of everyone’s time.
What it absolutely shouldn’t be used for is trapping failures in either the policy feedback loop or control effectiveness. Someone I worked with once said, ‘if we always process this as an exception, it’s not an exception any more’. It’s not the only time I’ve heard the sentiment but it was certainly the most succinct version of it, and it’s true: there is no point in having administrative burden to paper over the fact that the organisation’s risk appetite for the matter at hand has changed. Either fix the control or record the change in risk appetite and move on.
For completeness and, ignoring internet-scale companies, you should probably have only one register for the technology function and, if feasible, it should be the same workflow no matter what the exception is covering.
The Relationship with the Technology Function
Ultimately, the way the internal policy in the security infrastructure is managed and exceptions are processed has a major impact on the way the technology function perceives security. If you lose your audience, you have a problem.