In recent years a disturbing trend should have come to light to anyone closely following the security industry. We have seen a large uptick in investment in security tools by organizations, but we have not observed a decrease in breaches and ransomware attacks.

In fact, the number of data breaches and ransomware attacks are still arguably increasing despite this increased level of investment in security tooling. This should be raising a serious question among security leaders as to what we as an industry are strategically doing wrong. Why are we not getting improved outcomes against attackers with all of this increased investment?

In the realm of application security, it has long been known – and is an oft repeated mantra – that you must build security in and not bolt it on later, as having an application that is secure by design and that has various security controls like input validation, escaping etc. built into it will lead to far better security outcomes than just sticking a poorly designed application behind a firewall or CASB.

There is a huge body of evidence to support this mantra on the app sec side of the house, and it should be viewed as a mantra that as security professionals we all take to heart, whether we work in app sec or not. If it’s well established that we can’t bolt security on later, then on the larger healthcare-delivery organization network scale why do we as an industry often just invest in tools and then assume we are safe?

This is not to say that tools don’t offer benefits and that we should not invest in tools (we should), it’s just that a strategy that relies on tooling alone will not be adequate to keep us safe, and the uptick in data breaches and ransomware attacks shows this.

For example, we are increasingly seeing a number of threat actors leveraging living off the land techniques or employing legitimate IT tools like ADFind and ADExplorer as a part of their attack strategy.

The reason behind these approaches is fairly straightforward: They are legitimate IT tools with legitimate uses, and as such most endpoint security tools will not be configured by default to block them.

This is not highlighting a deficiency in the endpoint security tools, as they don’t want to break the legitimate use of these IT administration tools and harm their customers, but it demonstrates that the protection from tools in their default configurations alone is never going to stop every stage of an attack that we need them to, without some additional security being designed in.

If we put some thought into our network design, however, attacks like this can be stopped with the very same endpoint security tools. ADFind is likely perfectly acceptable for use by someone on the Active Directory team, but it’s a tool that a doctor, nurse, or almost any other HDO employee will never need to use, and the attempted use of the tool should probably be a cause for alarm.

With a little legwork, additional security can be readily built into our network by blocking the use of ADFind and other tools like it on all systems but the systems used by the Active Directory team. Designing hardening strategies like this and building such security in offer far better protection than just deploying a tool with default configurations and hoping for the best.

Moreover, if one ventures down the road of taking an evidence-based approach to security and actually testing and measuring control efficacy, it becomes evident that, while tools definitely can detect and stop certain attack vectors, their detections are never perfect.

Consider PowerShell 2 fallback attacks as an example. PowerShell 2 did not have the same level of logging as newer versions of PowerShell and does not integrate with AMSI, which allows for malware scanning. As such, many endpoint security products don’t always reliably detect attacks that force their malicious script to downgrade to the PowerShell 2 interpreter.

Because no tool is perfect, we need to identify their weaknesses and make sure they are accounted for by other compensating controls. In other words, thought also needs to be given to building security by having properly hardened system configurations, such as disabling PowerShell 2 and other nonessential functions everywhere they are not explicitly needed. This will work to lessen the ways an attacker can bypass our protections and remain undetected.

To extend the use case for the necessity of building security into system configurations and network architectures, let’s consider some additional points. As security professionals, we have all heard of and used tools like VirusTotal to help analyze a suspicious file. VirusTotal is a multi-scanner that will tell us if any one of dozens of endpoint security products consider a file malicious. It has long been known that attackers maintain their own no-distribute multi-scanners to test their malware against so they can be assured that out-of-the-box detections won’t trigger.

It’s naïve to think that attackers are not able to afford a license or two of any of our favorite products and that they are not testing for control efficacy or more pertinently the lack of it.

As such, in most cases they likely know the strengths and weaknesses of our security tooling better than we do. In fact, as a longtime proponent of evidence-based approaches to security, it is in many ways sad that we as industry still primarily treat security as an art form and base our actions on “I think” and “I feel,” while our adversaries are out there actually measuring control efficacy and using more empirical forms of testing to defeat us.

This needs to be a wake-up call that defense-in-depth strategies that involve more than just out-of-the-box tooling are essential to keep an organization secure.

We need to rethink how we approach security as an industry. As healthcare delivery organizations, we need to design our networks with security in mind (e.g. zero trust) and need to ensure that we are deploying systems to those networks with properly hardened architectures.

We also need to increasingly ensure that we take a defense-in-depth approach to security and that additional compensating controls are present to account for areas where an existing control may not have a high enough efficacy to meet our needs. Identifying the areas that require improved efficacy requires we take an increasingly evidence-based approach to security and stop just deploying tools and assuming we are now secure.

As an industry, we’ve bought into the illusion for too long that we can buy some security tools and be safe. The patient safety issues that all the recent ransomware attacks have caused means it’s time for us as an industry to see past the illusion and begin to build security in, and not just keep failing at trying to bolt security on. The patient safety cost to this is just too high not to.

Christopher Frenz is Information Security Officer and AVP of IT Security at Mount Sinai South Nassau.