Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Autonomic Software Patches Won't Help

DZone's Guide to

Autonomic Software Patches Won't Help

While in theory, the ability to have self-patching software seems like a game changer, one security expert argues that it won't really matter that much.

· Security Zone ·
Free Resource

Protect your applications against today's increasingly sophisticated threat landscape.

At the end of 2016, 7 teams from across the country met at the Paris Hotel in Las Vegas, Nevada for the first all-machine hacking tournament. The teams each were tasked with defending groups of air-gapped systems by identifying software vulnerabilities, generating patches for those vulnerabilities, and deploying those patches to the running systems in real-time.

And they were successful! The teams were, in fact, able to do this, and the systems they developed for the competition did so with no human intervention.

The point of this was to show that we could actually defend computer systems in an automated way. By doing so, defender action cycles could shrink, speed up, and hopefully execute faster than attacker action cycles. This could give defenders an advantage over attackers.

The Cyber Grand Challenge (CGC) showed that this was possible.

But it's not possible at scale.

Where could it work? So, first, let's think about where this kind of technology could work, and why. We know it can work in simple cases, with simple executables. After all, the CGC was more a proof of concept that anything else. But can it work with larger, modern programs? Programs with extensive concurrency and external library dependencies? Perhaps, but that has yet to even be investigated.

This kind of approach could certainly be used with custom software by that software's original owner or creator. Customware could use this approach. But to be useful, even in this context, we'd need to be able to extract and deliver the patches to other installations of the code as well.

We could run this kind of patching system against our code in a lab, for example, capturing and distributing generated patches to other installations. This certainly seems possible in light of the DARPA results.

But this is a very small percentage of installed software. The vast majority of software is developed by commercial companies, not by the organizations using that software.

Where won't it work? Commercial software.

Say I buy a word processing program from a well known international vendor whose name rhymes with "pikehosopht." And I have this kind of patching system running on my computer, scanning my software and automatically patching any vulnerabilities it finds. And say it finds a flaw in my word processing program and patches it, but that flaw causes the side effect of emailing profanity to everybody in my email application's address book.

This is clearly contrived, but in this case, who's at fault and who is liable? What if the code that's emailing all that profanity is not code that my patcher patched, but rather is code that was included by the original author that was activated by my patch?

Or what if the patched system was drug distribution software in a hospital?

So there are clear liability and responsibility problems with this kind of approach. And it's of questionable legality based on the DMCA anyway.

Does this really help? Maybe short term, but it assumes that attackers don't begin to use similar technology to win the advantage back from defenders. Is this kind of approach a game changer? Sure, but not for everybody. And attackers will catch up. They always do.

Rapidly detect security vulnerabilities in your web, mobile and desktop applications with IBM Application Security on Cloud. Register Now

Topics:
security ,automated security ,cybersecurity

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}