I want to start off by saying I don’t believe compliance is a bad thing. It’s an important part of doing business and a way to provide assurance to customers and partners in the absence of any other method. We also need a way to evidence that we are meeting a law or regulation, and compliance provides a way to do that. I do believe there is value in attaining certifications and accreditations, much in the same way I do for my personal career, but they are only ever half of the equation.
Also, all compliance is not equal. If you took two similar sized companies in the same sector who both hold ISO 27001, they would vary wildly on the digital maturity scale, and even more if you looked at their technical security infrastructure configurations.
This is not a criticism of ISO standards, if followed and implemented ethically they provide an excellent template to build an effective information security management system, however it will not necessarily lead to improved technical configurations. Compliance tends to encourage documentation over technical work, again strong documentation is absolutely required for a well rounded security program, however it shouldn’t exist in a void.
For example, conducting an annual penetration test (which is more often a vulnerability scan rather than an actual penetration test) to meet a compliance requirement, then recording the findings on a risk register contributes nothing to reducing your attack surface and making you more secure. Risk registers are one of the best and worst risk management tools, however this is more about the way they are used, rather than the tool itself.
Simply running the test is not enough, you must also act on the findings, and track the remediation. You should not have the same findings two years running, unless something has been accepted at board level as a tolerated risk, and this should not be the norm.
In my experience most orgs tend to focus on, and provide more resources for compliance over technical security. It’s an easy trap to fall into as being “compliant” is tangible, you have an audit, and you get an outcome. It’s nice and tidy, you produce evidence and receive a reward, whereas secure configuration is not like this. It’s a moving target of variables, nonsense, zero-days, CVEs, evolving best practices, endless documentation and conflicting opinions. You don’t ever get a certificate, or something tangible you can show someone to say “look how well we’re doing”, but it is vital it’s given at least equal consideration.
Well configured technical controls can actually reduce the amount of compliance and governance work you need to do, however the opposite does not apply.
The harsh truth is, no matter how good a policy, or standard operating procedure is, it will not make your org more secure, and is not a replacement for a technical control.
One small technical configuration improvement will reduce your attack surface, and combined over time these incremental changes result in drastic improvements.
Writing a policy telling users what they should not do, and having every user sign it to state that they will abide by its contents is far easier than securely configuring a device which also allows users to effectively fulfil their role.
Technical security is not ensuring you are doing what you say you are doing in policies and compliance standards, it goes way beyond that.
Let’s look at a typical compliance example – “Do you have antivirus software installed on all endpoints and is it updated daily?” We tick yes, provide evidence by referring to a policy which states this must be done, and pat ourselves on the back for a job well done.
We can confirm this is the case by going to our management portal, or preferred reporting method, and confirming this is being done. AV on all seen assets and updating is set to daily.
Yes, of course it’s good we have a regularly updated AV installed and a policy which states the requirement, but this is a bare minimum and doesn’t account for many other factors. For example if we were using Microsoft Antivirus, there are several other questions we should be asking.
- Are we using just Microsoft Antivirus or are we using Microsoft Defender for Endpoint (MDE)?
- Is it in active or passive mode?
- Is network protection enabled?
- Is tamper protection enabled?
- Do we have P1 or P2 licensing?
- Do endpoints support and use credential guard?
- Are Attack Surface Reduction (ASR) rules being enforced?
- Is SmartScreen enabled?
- Are policies enforced locally, via MDE, or Intune?
- Can users override or disable settings?
- What exclusions are configured and who is able to configure these?
- Have we validated that the devices are configured, and behaving as expected?
- Are the alerts monitored by a competent team or individual?
- When a threat is marked as automatically investigated and resolved by MDE do we confirm this, and validate the finding?
These are just some of the further considerations we need to understand and configure appropriately for our infrastructure.
Device and infrastructure hardening is difficult in every conceivable way, which is why many give up, resigned to the fact they are fighting a losing battle against an unwillingness from the wider organisation to engage in the process and participate in the testing. There is always a reason why a more secure configuration can not be used, and the most common is an impact to the current way of working. The office of “we’ve worked like this for years and never had any security problems” is an all to familiar tale.
I can’t tell you how risky this mind set is.
Cyber security moves so fast that something that might be considered secure today may not be the tomorrow, and orgs should accept that the absence of a cyber attack does not equate to a secure infrastructure.
Cyber security is not just an IT problem, although whenever there is a breach the finger always points squarely in their direction, and is accompanied by the obligatory tuts and head shakes, “can you believe they still used X, or hadn’t patched Y?” Often the IT or cyber teams are aware of what needs to be done, but have been unable to apply the required remediations due to wider business issues, but you can bet your house they had excellent policies and procedures and some form of compliance accreditation.
Most businesses are defending against auditors rather than cyber criminals, which is why orgs that on the surface appear to be doing all the right things often fall prey to the same types of attacks as everyone else. Strong compliance can create a false sense of security, and although it is important, it should not be at the expense of everything else. Compliance and technical security are two sides of the same coin, if you do a controls review and the majority of them fall under process, and people with very little under technology, then it may be time to re-evaluate how you are focusing your efforts.
In conclusion, we need to ensure we are giving secure configuration equal resource in comparison to compliance work so allow relevant staff time dedicated to improving current configurations. This must have exec level backing to ensure all business teams are engaged in the process and allow time in their own teams to work with cyber or IT towards secure by default. You’ll reap the rewards from this with improvements both in efficiency, and security posture. It also encourages a relationship between IT/Cyber and other business teams which is critical for achieving secure by default and efficiency of system implementations, as it requires open conversation and collaboration to achieve the required balance between functionality and security.
Cyber security is easy, right?
@2codemonte 