The best way to secure applications in 2018? Learn from 2017

Posted by Charlie Klein on Wednesday, February 7, 2018

2017—a turbulent year in application security

From breaches making headlines to exciting new technologies, 2017 was abuzz with conversation around securing applications and the implications of access to personal data. We saw what can happen when sensitive data is not properly secured, providing a sharp reminder of why application security is so important. Looking ahead, we need to reflect on emerging threats, technologies, and practices in application security in 2017, so organizations can prepare for building secure applications in 2018.

Undoubtedly, the most infamous headline regarding application security in 2017 was the breach at Equifax. 143 million consumers had their social security numbers, addresses, and birthdates exposed and 200,000 more lost their credit card numbers to hackers. Had Equifax identified its open source components and understood the security risks associated with those components, it would have found the Apache Struts vulnerability, which was publicly disclosed months prior to the attack.

The top threat on OWASP’s Top 10 Application Security risks is SQL Injection (SQLi), a common way of hacking an application. 2017 saw a 62% increase of SQLi attacks, according to the State of Internet Security report by Akamai. SQLi usually targets web applications, which were subject to 69% more attacks than in 2016. One hacker stole 700,000 email addresses and passwords from DaFont.com, a font sharing website, by exploiting “a union-based SQL injection vulnerability in the site’s software, a flaw he said was ‘easy to find.’”

DaFont.com was far from the only victim of a breach in 2017. Hackers found a bug in Cloudflare’s software, which gave them access to passwords, cookies, and authentication tokens. Search engines cached the data once it was released, so Cloudflare approached Google, Yahoo, and Bing to ask that the data be found and erased manually. Data from the Securities and Exchange Commission (SEC) was also compromised after hackers exploited a vulnerability within an application — giving them insider information such as merger announcements and company financial statements to trade illicitly.

DevOps – a bridge over troubled security waters?

To keep up with fierce competition to deliver software quickly, DevOps teams are leveraging Continuous Integration (CI) tools and containers to quickly develop and deploy applications. While the root cause of breaches varies, building a security review process that keeps up with the rate of software delivery was a defining challenge to application security in 2017. As organizations aim to reduce their time to market by introducing automation and CI to their SDLC in 2018, application security practices need to adapt to continuously review and monitor software as well.

According to a 2017 survey by the SANS Institute on the state of application security, increasing speed in software development introduces new risks. SANs states: “Changes [to applications are] being made so quickly, and so often, that it is difficult to understand and review them for risk.” Additionally, IT Operations might “Not [have] enough time to do exhaustive testing or reviews before changes get pushed to production.” When speed and security are both requirements for successful software delivery, integrating security with CI tools becomes paramount. “SAST/automated code review tools integrated into automated builds or directly into developer’s [IDEs catch] mistakes as developers make changes.” By building security into the software, DevOps teams can prevent code from slipping through the SDLC without checking for vulnerabilities.

In addition to CI/CD tools, application development teams use open source software to speed development times and cut costs. To do so safely, organizations need visibility into which open source components they’re using and understand the associated security risk of each component. When a vulnerability is publicly disclosed, it launches a race between hackers and application security teams to find that vulnerability. Given that roughly 96% of applications analyzed by Black Duck contain open source components and 67% of those components had vulnerabilities, organization need full control over open source risk management to find the vulnerability first. To manage this risk at scale, SANs suggests organizations utilize “Automated software component analysis (SCA) for open source and third-party libraries, integrated into automated builds, and as part of code check-in.”

Maintaining secure applications in containerized production environments

Application security doesn’t end with secure software development practices. The rise of containers in production environments presents challenges to securing applications after they’re deployed. 451 Research, Forrester, and Cloud Native Computing Foundation found that 50-70% of container users began leveraging containers to deploy applications in production in 2017. As container adoption continues en masse, traditional security solutions “may not be able to operate at the scale of containers, manage the rate of change in a container environment, and have visibility into container activity,” according to the National Institute of Standards and Technology (NIST).

The difficulty of managing containers at scale provokes concerns around security. The surveys above revealed that 35-45% of participants indicated security as a primary concern regarding containerizing production environments—making it the most common anxiety around container adoption. Participants in Aqua Security’s survey indicate that 80% of container users believe they can improve their approach to container security.

Organizations can adopt container-native tools to give IT Operations teams visibility into their images so that they can identify vulnerable containers before moving them into production. NIST cautions that “…traditional tools are often unable to detect vulnerabilities within containers, leading to a false sense of safety.” Rather, “adopt container-specific vulnerability management tools and processes for images to prevent compromises.” Once container images are deployed, containers should be continuously monitored for newly reported vulnerabilities. NIST warns: “…an image created with fully up-to-date components may be free of known vulnerabilities for days or weeks after its creation, but at some time vulnerabilities will be discovered in one or more image components, and thus the image will no longer be up-to-date.”

Will 2018 be any better?

Fortunately, 2017 served as a wake-up call for organizations who disregarded application security. Gartner predicted that “Worldwide spending on information security products and services will reach $86.4 billion in 2017, an increase of 7 percent over 2016, with spending expected to grow to $93 billion in 2018.” Additionally, 88% of respondents to an Adaptiva survey regard compliant security hygiene as “Very” or “Extremely” important.

Software delivery teams used to develop, conduct security tests, and then deploy software as separate steps. However, modern tools like CI and container orchestrators are rapidly changing that model; now that software is being produced continuously, security practices must adapt to review that software continuously as well. If custom and open source code is continuously reviewed in both development and deployment, organizations have an excellent base for their application security program in 2018.