What happens to security when your apps go to the cloud

When Marc Andreessen wrote, “software is eating the world,” he meant that every business is literally turning into software. The problem is that every line of code you write makes you easier to attack. Historically, we dealt with security by putting up walls and scanning. But the complexity of modern software environments has made these approaches ineffective and unscalable.  If we can enable applications to assess and protect themselves, however, the need for walls and scanners disappears. We envision a future when all applications are “self-protecting” and can guarantee their own security and resilience despite an increasingly complex and hostile environment.

We had a recent conversation with Jeff Williams, Co-Founder, Chief Technology Officer, of Contrast Security about the pros of applications moving to the cloud, the security dilemma's surrounding the moves, and the explosion of software defined networks and tools.

ADM: What is Contrast Security and how does it differ from competing application security vendors?

Williams: Traditional approaches to application security like SAST, DAST, and WAF come at application security from an external perspective. At Contrast, we invented a way to integrate all these capabilities into a powerful application-layer agent. This agent takes less than a minute to install in application environments, and enables “Self Protecting Software.” That means these applications are empowered to assess themselves for vulnerabilities *and* protect themselves against attacks. Contrast transforms applications into self-protecting software without requiring any changes to how you build, test, or deploy your code. And Contrast is a distributed approach to application security.  That means no more scanning applications one-by-one.  Instead, we can continuously assess and protect an entire portfolio of applications in parallel. Even better, because Contrast works from inside the application themselves, it has an unfair information advantage over legacy tools, which makes it dramatically faster and more accurate than anything that has come before.

ADM: What happens to security when an application moves to the cloud?

Williams: Typically, it’s not good. When an application moves to the cloud, there are two major changes. First, the entire foundation and all of the security assumptions about the environment are completely changed. This isn’t just about technology, the people, processes, and even the legal framework for operating the application all change.  Second, all the connections made by the application are now exposed in new ways. The application that once previously connected from a trusted network to internal systems must now connect over public networks and may lack a trusted way to store credentials.  Essentially, the developers made a certain set of assumptions about the environment when the designed and built the application, and when they change, it is extremely likely to result in both security improvements and security vulnerability.  Certainly, not all private data centers are well run, and many cloud providers offer excellent security services, so the net change may be positive, but you will certainly want to carefully think through the new threat model.

ADM: How can we block application attacks in the cloud?

Williams: Unfortunately, application attacks are difficult to block whether they’re in the cloud or not. In 20 years, we have not been successful at getting developers writ large to write code that detects and blocks attacks.  And WAF has never been very satisfying because it attempts to use network techniques to stop application attacks. I believe that RASP represents the best of both worlds, as it integrates attack protection directly into applications, but doesn’t require developers to change the way that they develop, test, or deploy code.  Ultimately, when applications defend themselves against attack, then they can be moved from datacenter, to container, to cloud and the security will go with the app. This level of agility is critical for modern software development.

ADM: What do you think is the most hyped cloud security risk?

Williams: As organizations move to cloud + mobile architectures, the focus on the mobile part is clearly overhyped. Based on data collected for the Verizon DBIR over the past few years, it’s clear that the number of serious breaches resulting from insecure mobile applications is zero. Yet there are many dozens of companies and large enterprise budgets dedicated to mobile security. It’s understandable, because there is real risk from mobile apps.  But it’s important to keep the mobile risk in perspective. Most of the serious risk is in the part of the application hosted in the cloud… the APIs. As discussed below, these APIs are almost impossible to test with legacy tools, yet are susceptible to the full range of vulnerabilities that we’ve come to know and love for traditional applications.

ADM: What is the most under-hyped?

Williams: The biggest under-hyped risk in cloud deployments is multi-tenancy. The cost and complexity benefits of supporting multiple customers with a single application are enormous. However, multi-tenancy introduces the need to keep multiple organizations data separate from each other, resulting in complex, custom access control code. Every organization builds this logic themselves, meaning that there are some good and some extremely poor implementations. Yet the consequences can be devastating when a vulnerability allows one organization to access some or all of another’s. The best approach here is to be sure to build a fundamentally strong access control model, use standard components to enforce it (not zillions of custom queries), and continuously verify that every developer is sticking to the plan.

ADM: Many organizations are putting their dev and test servers in the cloud. What does this mean from a security standpoint?

Williams: Most organizations don’t think enough about the security of their code. If an attacker can gain access to the source (or binary) code they are much more likely to be able to find vulnerabilities. And if they can Trojan that code, their malicious logic can make its way into production and seriously damage the enterprise. So when all development machines are internal to the organization, much of this risk can be mitigated with traditional network and host security controls. But when the development pipeline moves to the cloud, it can be difficult to understand all the pieces and exactly what is exposed. Organizations should treat their development pipeline like other infrastructure and their code as a critically sensitive asset, from both a confidentiality and integrity perspective. It’s an interesting but often overlooked threat model.

ADM: What are some good approaches for security testing APIs (microservices, JSON, XML)?

Williams: APIs are incredibly important. Even web applications these days are being built as an API and a Javascript client in the browser or a mobile interface. Unfortunately, these APIs have the full range of vulnerabilities, but are extremely tricky to test for security. One problem is that the messages have very complex formats that are impossible to analyze on the wire or with a scanner.  This means that DAST tools simply can’t work on these APIs. Further, SAST tools struggle with APIs because they tend to use large amounts of framework and library code that their control and data flow algorithms simply can’t handle. I believe the right solution is to use IAST to get the security analysis inside the API itself. In this way, the protocol doesn’t matter and the data and control flow are easy to follow. Just like applications, all APIs need to be able to detect their own vulnerabilities.

ADM: What is the future of application security?

Williams: The future of application security is “self-protecting software.” SPS is software that can identify its own vulnerabilities and protect itself against attacks.  You enable SPS with the latest application security tools IAST and RASP.  There are a number of reasons why this approach wins. First, doing security from within the application dramatically improves accuracy and removes false alarms, so feedback can go directly to the development and operations team members that need it without an expensive applications security team.  Second, SPS provides instant feedback, enabling high-speed modern software practices like DevOps and Agile. And finally, SPS enables flexibility because wherever the application is hosted, regardless of how the network is architected or how the containers are deployed, SPS moves with the application, protecting it wherever it goes. SPS is available now and being used by dozens of the largest companies in the world.


Read more: https://www.contrastsecurity.com/