Here's my question of the day: Is it possible to prevent detailed technical security standards from devolving into a compliance regime (or does it even matter)?
In thinking about this question a bit today (while reading-up on NIST RMF), I started thinking about how this notion fits into risk management approaches. Specifically, in looking at RMF, it appears that rather than achieving a true risk management program, NIST has essentially created a very heavy, bureaucratic compliance regime. Now, I don't think this was even remotely their intent, but rather wonder if it's really just an inevitable outcome from how we as an industry have historically approached information/IT/infosec risk management.
A Quick Analysis
I'm going to assume that you agree with the assertion that most applications of technical standards do, in fact, devolve into compliance regimes (if not, please just play along). When I say "compliance regime," I'm literally talking about going away from a judicious decision process based on a reasonable risk analysis, and instead falling into the rut of "these are best practices, we must do them" followed by "we're the auditors, and we're here to check the boxes." It seems to me that the very act of recording detailed implementation requirements means an inevitable slide into a compliance regime. After all, if you've decided to make something a requirement, then all that's left is to make sure it's implemented, right?
Now, mind you, I'm not (necessarily) saying that this is a bad thing, at least in terms of an actual operational response to levied business requirements. However, the problem comes when this becomes the heart, if not sole component, of the security and risk management program. I'm sure you've been in one of those conversations where someone (often an auditor or pentester) says "you should implement change X" and you say "really, why is that?" and their response, quite plainly, is "well, it's an industry best practice." Hopefully you hear screeching brakes in your mind as you try to stop this statement cold in its tracks. "Just because" or "because I said so" is rarely a good business reason for making a technical change; especially if it's going to cost money to implement (and, pretty much everything does).
All of this brings me back to two related notions: 1) That security and risk management should be deoperationalized into a comprehensive GRC program (GRC as a discipline), and 2) That the duty to implement security requirements should be relegated to true operations teams, which are in turn abstracted from the decision and enforcement authorities (i.e., from those who set and enforce the requirements).
How To Solve The Problem
Ultimately, I don't think a compliance regime at the operations level is a bad thing. In fact, I think it could be very useful, a la Gal Shpantzer's discussion of using procedures to minimize errors in his talk Security Outliers: Cultural Cues from High-Risk Professions. That is to say, IF the requirements specified have a proper vetting and risk management basis, THEN it is absolutely, positively appropriate to allow them to devolve into a compliance regime.
However, this then opens up an interesting challenge. If we're ok with allowing technical security standards to devolve into a compliance regime that makes use of checklists and well-documented procedures, then how do we make sure that those artifacts are in fact derived from a reasonable lineage? The answer is "a risk management program," though I can't say it's "just that simple."
What does this mean? First, it means you need to have a formal risk management program in place. Second, as part of that program, you need to have a reasonable risk assessment capability that can be used to vet the organization in determining context and respective value classes. Third, you need to then bring requirements through the risk analysis process to understand their business impact within each respective value class (e.g., different portions of a networked environment will vary... all data and systems are not created equal, and context is everything!). At the end of the day, this may mean having different sets of technical standards for each value class, which then must be enforced as appropriate. There will also likely be some common core requirements, such as around monitoring, response, and routine assessment, though even some of the specifics there may vary (e.g., a low priority system may not need to be recovered as quickly as a high priority one).
Today much of this may look like manual effort, though this is changing. Specifically, we're starting to see movement toward integration of tools like security configuration management with audit and compliance management products that allow for mapping of resources, control requirements, and implemented controls to continually monitor and report on the state of each environment. Similarly, integration with risk management capabilities furthers this integrated approach such that the mandated controls can go through a vetting process before being published into the compliance regime for administrators to deploy.
The last question that all of this may raise is if it's worth it, and if so, how to measure it? The answer is two-fold. At the operational level, measuring the state of compliance should be sufficient, combined with monitoring and response capabilities, assuming that proper risk management consideration has gone into the specification of control requirements. At the strategic level, there is then an increasingly important need for a formal, well-defined, well-documented risk management process that leads to legally defensible decisions that help the business establish reasonable risk tolerance and risk capacity levels, and that ensures business survivability (because survivability should be the goal, rather than the failed perspective of trying to stop all badness from happening). Note, by the way, that following this bifurcated approach is then fully compatible with outsourcing arrangements, such as with cloud services providers, at least provided that specifying and enforcing reasonable controls is written into the contract and SLAs.
So, to conclude the post... yes, a compliance regime does seem to be inevitable when specifying technical security standards, and that's ok - provided that there is a reasonable GRC program in place to ensure that the dictated standards are appropriate, reasonable, defensible, and enforce the survivability mission.
