My Top 5 Cyber Security Predictions for 2016

It's that time of year for my top predictions for 2016.  And, let's review how well I did for 2015:

My 2016 predictions include:

1. We will see a major attack that takes advantage of our totally unprotected development infrastructure.
2. We will see cybersecurity threat sharing legislation, but nothing about building secure code.
3. We will see attacks that target so-called "internal applications.”
4. We will see a major attack that targets an API instead of a traditional web application.

In 2016…

1. We will see a major attack that takes advantage of our totally unprotected development infrastructure.

Software development involves an entire ecosystem of tools to support the process of writing, managing, compiling, integrating, testing, and deploying an insane amount of source code, libraries, frameworks, and other components.  A lot of this infrastructure is free and open source — comprising thousands of projects and people around the world. And some of the infrastructure is commercial from companies like Apple, Atlassian, Sonatype, and many others. Here’s the problem. Any tiny piece of this infrastructure has the opportunity to inject malware into the software being built. An attacker that is able to add a few lines of malicious code to any library that runs as part of your development organization can completely undermine your business. So the software tool chain is an incredible target for attackers, and could completely compromise your entire company.

2. We will see cybersecurity threat sharing legislation, but nothing about building secure code.

Politicians are outraged, outraged I say, about cybersecurity but their instincts about what to do are wrong. The knee-jerk reaction is to focus on the attacks, trying to identify threats and threaten counterattack. But the so-called “attribution problem” means that identifying perpetrators is hugely time-consuming and almost always unproductive. Do we know exactly who hacked Sony yet?  Sharing threat information isn’t necessarily bad, but it’s not going to make a meaningful impact. Our best long term strategy is to get better, a lot better, at building secure code.  I’m not recommending attempts to legislate security, but legislating visibility into how code is built and security tested could be the most effective way to affect the market dramatically.

3.  We will see attacks that target so-called "internal applications.”

As doing business involves increasingly sophisticated connections between desktop, phone, cloud, apps, servers, home, and “things,” the ability to enforce a network "perimeter" has all but ceased to exist.  And if there is no more perimeter, then it’s time for the whole idea of “internal” and “external” applications to die.  We need to be writing applications (and APIs) that are protected no matter where they are deployed, in the datacenter, in the cloud, or in a container.  And we have to realize that just because a host isn’t “pingable” it’s not hard for attackers to get on the “intranet.” Oops, there’s another term that has to die.

4. We will see a major attack that targets an API instead of a traditional web application.

Development teams are rolling out APIs of all kinds — web services, REST interfaces, microservices, etc…  Modern web applications, mobile apps, desktop apps, and automation tools all rely on these services. Unfortunately, there’s a catch. These APIs are just as susceptible to attack as traditional web applications. Unfortunately, they are basically untestable with legacy static analysis (SAST) and dynamic scanning (DAST) tools.  Look to newer instrumentation-based (IAST) tools that can handle the complexity of the frameworks and protocols here.

5. We will see a major vulnerability in IoT protocols and implementations, making a bunch of existing products unfixably vulnerable.

The Internet of Things (IoT) involves a whole new family of protocols that doesn’t have 20 years of security analysis like HTTP.  When vulnerabilities are discovered in these protocols, and the devices, sensors, and APIs that implement them, how will we respond. Many of these devices don’t have the ability to apply a patch easily, which virtually guarantees that these vulnerabilities will stay around for many years. It’s time for every Internet thing to include the ability to automatically update itself easily.

So way back in 2015 – here were my predictions and how we did…   Maybe 3 1/2 out of 5 :-) 

1.“The Internet of Things will kill someone.  Whether it be a dishwasher, thermostat, car lock, furnace, drone, wallet medical device, you name it – hackers will exploit it – and this will have actual, real world effects that ultimately end in tragedy. We’re not sure what device or how it will happen but it will probably be the last thing you expect.”

Not exactly, but a factory robot did kill a guy.  Of course the first robot killing was back before Terminator in 1979.  Incidentally, the guy killed was named Robert Williams - the name of my father - so I warned him about a possible Terminator scenario where the future robots have been killing people with his name for 36 years.

2.  “Apple Pay will significantly change the credit card breach landscape and will provide a significant reduction in breaches for companies that are part of the Apple Pay ecosystem. Companies will begin embracing Apple Pay, which will significantly overshadow Bitcoin’s growth in the market.”

No. Both Apple Pay and Bitcoin have been very slow to take off.  However, despite a variety of technical weaknesses, the chip-and-pin system has *finally* reached the US.

3.  “Vulnerability burnout will take hold.  A major vulnerability will be discovered in a widespread product and nobody will care. The news will be overshadowed by bread and circuses, like yet another Kardashian scandal.”

Yes. The Java deserialization vulnerability from November 2015 is incredibly widespread. 

WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and many custom applications are vulnerable. However, this vulnerability was released without a cute name like ShellShock or HeartBleed. And it isn’t easy to tell whether applications are vulnerable or not. The reaction from Brian Krebs (via email) was "

it's just hard to make readers care about amorphous threats like this that they can't do anything about.” Although there are easy things people can do, vulnerability burnout prevented any reasonable response. The world’s applications are still quite vulnerable. 

4.  “2015 will see more senior executives fired over security breaches, despite the fact that they repeatedly explained security to the board and were not fully funded.”

Yes. Office of Personnel Management (OPM) Director Katherine Archuleta was fired after the  massive OPM breach. At some point, we need to evolve past scapegoating and focus on putting reasonable security defenses in place. 

5.  “Government will continue to call for breach disclosure instead of tackling the hard problem of improving application security.”

Yes. Although mostly they are calling it "threat sharing" and it is not going to change anything.