Web Application Security: Integration or Extinction

Web applications have become a primary vulnerability for modern business 

Today, almost every enterprise produces, leverages, transacts business or depends upon web or Cloud enabled software. As a result, web applications have become the number one target for malicious attacks. According to Gartner, 80% of attacks target web applications.¹ Often, these attacks exploited easily mitigated vulnerabilities in the application code. The most common issues found in the native code are log forging and cross-site scripting.²

Web applications are vulnerable due to a number of factors. These include:

Security weaknesses inherent to the web’s architecture that allow malware to be installed and executed inside a web browser;

Increasing complexity that obscures flaws; as the underlying code becomes more complex, it contains more obscure syntax, making it difficult to spot vulnerabilities; and

Public Internet accessibility that allows external attackers a path to a company’s confidential data and IT environments.

This combination of widespread employment and inherent vulnerability demands a transformation in how application security is conceived and how software development incorporates security across the software development lifecycle (SDLC) from requirements definition through deployment and operations.

Implementing DevSecOps 

DevOps, or the structured collaboration between developers, business leadership and information technology (IT) professionals emphasizing continuous, rapid, automated software integration and delivery and infrastructure change management, was developed to increase the speed with which business responds to customer demands.

In a traditional software development lifecycle (SDLC), security is often executed at the last stage, immediately before a product’s release. For example, most organizations are relying on downstream activities to mitigate security risks, such as pre-production penetration testing.³ In many enterprises, development and security activities take place in separate, independent silos with little to no interoperability. In such organizations, the development team is primarily measured by rapidity of delivery and functional quality. Under pressure to release quickly, developers may not put enough emphasis on software security.

DevSecOps, a paradigm in which security becomes an integral part of the DevOps process, requires that development and operations teams consider security requirements during every phase of software development.

The ability to rapidly, and continuously, integrate and deliver high quality software has been achieved through the DevOps paradigm. However, DevOps, with its emphasis on rapid integration and delivery, can fall victim to the same pressures as legacy development methodologies. To ensure that security is integral to the continuous integration, continuous delivery processes that enable DevOps to rapidly deliver value, software development organizations should look toward DevSecOps.

DevSecOps, a paradigm in which security becomes an integral part of the DevOps process, requires that development and operations teams consider security requirements during every phase of software development. Security requirements and acceptance criteria are included in the planning process, and security features are tested, as with any other functionality, as early and often in the process as possible. Feedback is delivered directly to developers (not security personnel as in case with legacy ITIL or COBIT), who are responsible for testing their own code for security issues and resolving them in near-real time.

As with DevOps, a thoroughly planned DevSecOps framework encourages engineers and developers to try innovative solutions instead of trying to complete the design before beginning implementation. Solutions that don’t work are not considered failures, and are used to inform subsequent efforts at software and process improvement.

DevSecOps, like DevOps, emphasizes the use of automation to enable continuous integration and continuous delivery. Security tools and practices can be readily integrated into existing DevOps automation frameworks such as Puppet and Chef.⁴ The result is that security assessments are an automated part of the integration process. The use of automation also reduces the risk of introducing security flaws due to human error, and allows for a substantial amount of more code to be verified, tested and integrated over a given period.

The rapidity of software development, integration and delivery demands a new approach, one where security instrumentation is integrated into an application’s code base.

Additionally, DevOps automation platforms (throughout build, test and integration cycles, and deployment and release processes) create a large volume of log data and detailed information about the code as it moves through the SDLC. This data becomes an effective security log. Events generated by services, application servers, databases and operating systems are automatically collected and managed by a central platform. The resulting logs can help determine if a security incident is in progress. For example, a security team can set up an alert whenever a user gains administrative access to an application.

Establishing a strong DevSecOps foundation ensures that the OWASP Top 10 (a list of the most critical web-based attacks that is provided and managed by the Open Web Application Security Project⁵) are mitigated through secure coding practices during each stage of web application development lifecycle.

The need to address the OWASP Top 10 becomes, under an Agile (Scrum) SDLC, an epic or set of security relevant user stories inserted into the overall product backlog, which are then broken down into tasks. Validation against known critical vulnerabilities is achieved through unit testing that enables rapid spot checking. Test failures cause deficient modules to be kicked back to the development team. This cycle repeats until the vulnerabilities are resolved. By integrating security requirements into the development, integration and delivery processes to ensure that only software that passes the security tests is delivered, DevSecOps is able to improve the security level of the developed software.

Evolution of AST tools in the Agile environment 

Tools enabling traditional web application vulnerability detection methodologies such as static analysis⁶, and dynamic analysis⁷ have been available for more than 15 years and reached the limits of their technological potential to support the speed of modern Agile software development.

Traditional vulnerability scanning tools require significant configuration and tuning, and the time required for these efforts means that the tools cannot usefully keep up with the release cycles made possible by DevOps and automated integration and delivery environments. Additionally, legacy application security testing tools do not provide contextual analysis for their test results, leading to false positives that undermine the accuracy, reliability and effectiveness of security testing overall.

The rapidity of software development, integration and delivery demands a new approach, one where security instrumentation is integrated into an application’s code base. Integrated instrumentation can take advantage of internally generated contextual information providing for more accurate examination and assessment.

Instrumentation is possible with new technologies such as Interactive Application Security Testing (IAST) and Runtime Application Self-Protection (RASP) that enable a continuous, real-time approach to application security. Both IAST and RASP can be delivered as either integrable modules or on a subscription basis following a Software-as-a-Service (SaaS) model. Vendors offering IAST and RASP tools include IBM, HPE, Acunetix, and Contrast Security.

In an IAST deployment, a software agent is used to add instrumentation to applications. A second component then generates malicious traffic as per predefined test cases, attempting to force failures and catch coding flaws that lead to exploitable vulnerabilities. IAST allows teams to scan more code with significantly fewer false positives, thus increasing the speed at which high quality and secure software is delivered. There is a cost, however. Current IAST implementations are complex and their use requires specialized training to parse test results and determine the root causes of identified issues.

IAST identifies security vulnerabilities at a testing stage while RASP addresses security attacks in deployed products.

RASP is implemented as instrumentation to the application runtime engine – either the application VM (e.g. Java Virtual Machine (JVM) and .NET Common Language Runtime (CLR) or the application servers (e.g. Tomcat, JBoss and Microsoft Internet Information Services (IIS), adding a protection layer against application level attacks.

RASP products are integrated with an application’s underlying source code libraries, and provide full insight into the application’s logic, data flows, and configuration during execution of application ensuring continual contextual security analysis. RASP intercepts all calls at runtime from the client application to a system and validates requests directly inside the application checking it against the application’s runtime context.

The way RASP works is conceptually comparable to Attribute Based Access Control (ABAC), a next generation identity and access management technology – where RASP, like ABAC, embeds data request validation into the application and determines at runtime if execution is permitted.

RASP enables the application to continuously monitor its own behavior, and block only those activities that are incongruous with expected application behavior, and that can be addressed immediately without human intervention. For example, RASP will block the execution of queries to a database server that appear to be a SQL injection attack.

Since RASP is embedded into the application and highly adapted to it, there is no need to re-configure the RASP as the application undergoes changes – e.g. migrating to the cloud, implementing microservices architecture with containers, adding REST or SOAP web services, or scaling up or down.

Since RASP resides in the application server, it uses CPUs and memory (RAM), staying inside the application throughout all its lifecycle. This means that even if a security incident occurred, attackers will not be able to penetrate an application to get to the data in or behind the application.

Having the latest security testing tools will not make an application as secure as building security into the application across the SDLC. Establishing a secure development lifecycle is critical. Web application security is continually evolving, and an organization’s security policies and guidelines must keep pace.

Having a “secure development lifecycle” implies proactive planning and implementation of security-first design during development. First, threat models should be created and threat mitigations included in technical specifications. Next, developers perform static security analysis of their source code as they write prior to compilation. This allows them to identify and fix vulnerabilities in software before the QA phase. During the QA phase the team makes a final secure code review before the release, analyzing the runtime configuration for security vulnerabilities.

Keeping pace with the modern threats during the whole software lifecycle 

An application’s security state is static, and can only be evaluated against criteria that reflect a particular point in time. Consequently, the application may be demonstrated to be secure today, but there’s no way to know if it will be secure tomorrow. It’s vital to conduct continual security reviews focusing not only on new features, but also conducting regression analysis of old code with new and updated tools.

Website owners should have a support team maintaining code with the latest patches and updates and executing continuous fuzz testing⁸ to harden the code against potential attacks. It’s vital that digital businesses have regular, rigorous maintenance and patching programs that enable them to address vulnerabilities as they are discovered.

Even though it means extra expenses that small businesses and startups may not be ready to pay at the beginning, security incidents can result in much higher post-breach costs and even destroy a startup completely.

Implementation of security solutions might be challenging for small businesses due to budget constraints. That’s why it’s important for smaller businesses to understand what threats are relevant to them so that they don’t waste resources remediating non-threats. This can be done by hiring or retaining security experts who can evaluate the cyber threat landscape for the company, build in-house threat intelligence, customize solutions and maintain it up-to-date to protect against specific vulnerabilities.

Small and medium businesses don’t have to make significant investments to implement DevSecOps. There are a number of open source and affordable configuration management tools, such as Chef, Puppet, Jenkins⁹, etc. that help to automate any project.

Developers can scan the code for flaws throughout the development cycle with open source static analysis tools available at the Software Assurance Marketplace (SWAMP)¹⁰, as well as open source dynamic analysis tools, such as Cuckoo Sandbox.¹¹ Even if a company decides to implement RASP, there is an affordable way to do it by getting a cloud-based RASP solution with pay-per-use models.

With the increase of application layer attacks, companies must assess the risks they face and build a well-balanced SDLC. This can be effectively achieved by adopting DevSecOps, a continual process of code security review during development and on all new releases. New self-protection technologies such as IASP and RASP can be integrated into DevSecOps, ensuring more accurate security vulnerabilities detection, that mitigates web application vulnerabilities. Nevertheless, we need to secure the application code itself as early in the development cycle as possible.

Sources 

1. HP Security (feat. Gartner). “Work Smarter, not Harder, to Secure Your Applications.” Issue 2, 2015.
2. HPE Security. “Cyber Risk Report 2016.” 4AA6-3786ENW, February 2016.
3. Hewlett-Packard Enterprise report. “Application Security and DevOps.” 4AA6-8302ENN, October 2016. https://saas.hpe.com/en-us/sites/default/files/resources/files/HPE%20 Application%20Security%20and%20DevOps%20Report.pdf
4. Puppet and Chef are open-source software configuration management tools for infrastructure that fully automate deployment during SDLC.
5. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
6. Static analysis is testing of application from the “inside out” by looking at source code, byte code or binaries without executing it in order to ensure conformance to coding guidelines.
7. Dynamic analysis is testing of the application from the “outside in” with code execution in runtime environment in order to detect security vulnerabilities .
8. Fuzz testing is a software testing technique used to discover coding errors and security loopholes in software by inputting massive amounts of random data to the system in an attempt to make it crash.
9. Jenkins is an open source automation server that provides hundreds of plugins to support building, deploying and automating any project.
10. SWAMP : the ready-to-use cloud computing platform (https://www.mir-swamp.org) and the SWAMP-in-a-Box (SiB) open-source distribution downloadable from GitHub (https://github.com/mirswamp/deployment).
11. Cuckoo Sandbox: https://www.cuckoosandbox.org.