Rapid Escalation of Application Integration Creates Major DevSecOps Challenge

They say the primary enemy of cybersecurity is integration. The problem is the rate at which application integration occurs is now exponentially increasing with each passing day and it would appear cybercriminals are starting to take note.

This week Menlo Security, a provider of container software that isolates applications from underlying infrastructure, published a report detailing how a Zero Day cyberattacks exploit what it describes as an integration flaw within Microsoft Word. The report notes that a recently discovered new zero-day exploit, dubbed CVE-2018, employs a zero-day vulnerability to fetch a malicious Small Web Format (SWF) file from the Internet. The attack embeds an ActiveX control in the Word document that maps to Shockwave Flash Player. The problem is that any ActiveX control that is marked as “Safe for Initialization” does not prompt the user with any security alerts. That means is that the remote SWF file is fetched without prompting the user with any security alerts.

This is hardly the first Zero Day exploit in Microsoft Word. But Vinay Pidathala, director of security research for Menlo Security, says it is an example of how cybercriminals are taking advantage of application programming interfaces (APIs) and integration protocols embedded within applications to deliver malicious payloads. In fact, Pidathala predicts Zero Day attacks being delivered across integrated applications are about to become a lot more common now that cybercriminals have figured out how to exploit that type of attack vector.

Arguably, this attack vector is a natural dividend of the so-called API Economy. As more applications become integrated using APIs created by developers not known for their cybersecurity prowess the greater the number of integrations there are to potentially exploit. In fact, this problem may be about to become a whole lot worse. Developers have been rapidly embracing what is known as microservices architectures to build next-generation applications. These microservices make it simpler to build and maintain applications at scale by isolating functionality in a way that allows those functions to be maintained and updated in isolation versus having to, for example, patch an entire monolithic application. While that approach makes developers a whole lot more productive, each microservice comes with its own set of APIs that need to be secured. The need to secure those APIs, in fact, is at the heart of a DevSecOps movement where more of the responsibility for securing an application is being “shifted left” on to the shoulders of application developers.

In the absence of a secure API, all it takes is for one trusted component of an application to become infected to not only infect the rest of the application but potentially every other application it connects with. Each application might be made up of hundreds, even thousands, of microservices so the scale of the cybersecurity challenge is significant. The good news is that should a microservice become compromised it’s a lot easier to rip and replace that microservice with one that eliminates whatever malicious code might have been injected.

Unfortunately, DevSecOps is not a concept easily mastered. Melding developer and cybersecurity teams together is a major exercise involving not just technologies, but also major cultural divides within the IT organization. As hard as mastering DevSecOps may be, however, it’s also apparent that when it comes to exploiting application integration vulnerabilities the inevitable countdown to a potentially catastrophic application timebomb being set off is now getting louder by the minute.