Web Application Security: Integration or Extinction

354-29.jpg

 

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. Often, these attacks exploited easily mitigated vulnerabilities in the application code.

Web applications are vulnerable due to a number of factors, which 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.

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

In a traditional 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.

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.

Cybersecurity Managed Services Require the Most Reliable Partners Explore how Svitla Systems can safeguard your business with expert cybersecurity management and innovative solutions. Contact Us

As with DevOps, a well-planned DevSecOps framework encourages engineers and developers to try innovative solutions instead of trying to complete the design before beginning implementation. Solutions that do not 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 substantially more code to be verified, tested and integrated over a given period.

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.

Article specially prepared for www.uscybersecurity.net

 

FAQ

What are the security issues with web applications?

Vulnerabilities in the web allow malware to be planted and run inside browsers, while increasing complexity disguises flaws that can be left unaddressed. Since these applications are available over the Internet, it becomes easier for an attacker to get access to a company’s sensitive information and internal IT infrastructure. Many companies further heighten their risk by conducting security as one of the last activities in the SDLC, thereby leaving code vulnerabilities that could have been easily addressed much earlier, until right before release.

What are the different types of security attacks in web applications?

Browser-delivered malware exploitation is a common attack, but other attacks include vulnerability-driven attacks by which architectural weaknesses are abused to execute malicious code within the user’s browser and vulnerabilities that reside within complex application code. The next big category is Internet-facing intrusion attempts, where external attackers try to gain access to publicly accessible apps on confidential data or internal IT environments. Most of these map well to very well-defined classes of web risks, often long considered critical even within general “top critical vulnerabilities” lists.

What is most likely to pose a security risk to a web app?

The most probable vulnerability in a web application is in its code. This relates to vulnerabilities that are easy to fix but get missed because of the pressure for quick delivery and increased complexity. If it is exposed over the Public Internet, then external attackers have more chances of finding and exploiting these weaknesses to access sensitive information or connected IT environments. When security checks are delayed until late in the lifecycle, this risk is more likely to reach production.

What is the future of app security?

The future of app security is shifting left-right-and-center; that is, by injecting security into every aspect of delivery rather than treating it as a final gate prior to going live. Security requirements and acceptance criteria are defined upfront, automated testing and assessments run continuously in CI/CD, so issues are found and fixed close to real-time by the developers themselves. This new way of thinking relies heavily on automation, integrated tools, and rich operational logging to catch the bad guys quickly and eliminate human error from the equation.