The Surprising Truth about Digital Transformation: Skipping Security

This is the third blog in a series on the challenges arising from digital transformation.

• The Surprising Truth about Digital Transformation
• The Surprising Truth about Digital Transformation: Cloud Chaos

Skipping Security.

It will be no surprise for many IT veterans to know that when app performance becomes an issue, security is often the first service out the door. Firewall falling down in the face of an attack? Turn it off. Services overwhelmed by sudden demand? Turn them off.

For twenty years we’ve been systematically shoving security out the door when application performance becomes problematic.

So it should be no surprise that in the face of pipeline performance, security is often skipped.

Nine out of ten executives admit to feeling pressured to get apps to market faster and more frequently thanks to digital transformation.

Whether executives explicitly or implicitly transmit that pressure to those responsible is irrelevant; developers and operations often feel under the gun when it comes to getting apps out the door in record time.

And perhaps because of that, they admit to skipping security. Nearly half (44%) in an IBM/Arxan survey of mobile and IoT developers did, and it’s likely that developers in other industries would admit to the same.

Security is hard, after all. There’s a lot of attack surface out there – and no layer is untouched. From the network to the platform to the application, there are more ways to infiltrate apps and exfiltrate data than there are layers in the network.

But if we look at the biggest breaches in recent times, we’ll see a pattern emerge that may help everyone focus their limited time on the most risk.

We have all heard about the Equifax breach. We know the sordid details, and like many other organizations they were caught by a published vulnerability executed against an unpatched third-party framework via a web platform. Discovery was likely, but not verified, achieved via a bot / automated script searching out likely targets. Likely because a significant majority of bot activity these days is not attack traffic, but probing reconnaissance missions.

It’s been a long time, it turns out, since someone managed to shim in via SSH or through a network vulnerability. Today’s attackers are after apps and credentials, and they’re using bots to find lucrative vulnerabilities – and carry out the attack.

The top three security risks you need to protect apps against are:

• OWASP Top Ten. SQLi, XSS, command injection, No-SQLi injection, path traversal, and predictable resource
• CVEs. Apache, Apache Struts, Bash, Elasticsearch, IIS, JBoss, JSP, Java, Joomla, MySQL, Node.js, PHP, PHPMyAdmin, Perl, Ruby On Rails, and WordPress.
• Bots. Vulnerability scanners, web scrapers, DDoS tools, and forum spam tools.

This is where standardization of security platform and policy meet per-app architecture to effectively to provide a way to remediate risk before it becomes an existential threat. Standardizing on a platform means the ability to standardize on policy. Using that combination, security pros can create a standard, base security policy that can then be deployed automagically to every app, immediately protecting it against the latest threats. Because it’s per-application, app-specific protections can be added to provide additional protection, but at a minimum you’ll be more confident knowing the most likely attack vectors are covered.

The other benefit in a per-app architecture is that apps not normally protected by something like a WAF (yeah, I know, why would that be? But trust me, there are) can be protected in the near-term by injecting a new instance with the appropriate policies into the app pipeline for as long as necessary. So when that CVE is published – and it will be – security pros can immediately implement a mitigating policy and inject it into the path of every vulnerable application before it can be exploited.

The answer to developers skipping security thanks to pressures to deliver from digital transformation is to standardize. Standardize on a common application security platform so you can leverage its ability to standardize policies and push them into the pipeline like a pro.

Stay tuned for the next post in this series, in which we’ll dig into how you can deal with the Diseconomy of Scale arising from digital transformation’s tendency to create more apps than there are ops.