Chapter 1 by Sogeti
Business ●●●○○
Technical ●●○○○
Listen to the audio version
When considering application security from end-to-end, four areas deserve special attention. This chapter will attempt to describe the various facets, associated benefits, the scope of each area, and how each area differs from the others in terms of benefits.
The customer problem
A customer approached me when I was working with them on another assignment several years ago. They were frustrated because security was falling behind in the work with shifting left in application development and testing. As a financial institution that deals with client card data and bank statements, they were required by law to conduct third-party security verification of their applications, ensuring compliance with PCI DSS and other frameworks such as OWASP Application Security Frameworks.
To ensure compliance, this verification uncovered a slew of issues that needed to be addressed prior to go-live. The issue was that this verification occurred late in the process, resulting in the necessity of resolving issues late in the development process, a time-consuming and cost-increasing process that the customer desired to eliminate.
Of course, in 2021, we've evolved significantly since then, embedding security testing into the build process and scanning for security issues with each iteration deployed, but there is still a significant amount of work to be done on the source code and solutions to audit the findings, remove what are known as false positives, and train developers on how to become compliant editors.
Historically, application security testing was a manual process carried out by skilled security experts who read code and fixed security issues in accordance with the publicly available vulnerability lists at the time. The longer this list becomes, the more work the security auditor will have to do, and thus the more time the auditor will spend on this. Adding to that, we typically hire 20 developers for every security expert we hire. As a result, the more developers we add, the further we fall behind security experts.
Along with scanning the code for security vulnerabilities, there is always a chance that the application you have developed contains vulnerabilities that are not detected by code scanning. A penetration test of any running application and APIs is required to verify this. SQL Injection, Command Line Injection, Cross Site Scripting, and traffic redirection have all been popular methods used by hackers to intercept passwords and other sensitive information. This must also be checked and verified for security.
In today's modern, object-oriented world, agile developers introduce third-party libraries to address specific issues that developers do not see a reason to develop themselves. Let's face it, humans are lazy, and innovation is motivated by our constant desire to eliminate tedious work that can frequently be seen being performed by others. Thus, with this in mind, we import, implement, and deploy libraries about which we have no idea who developed them, what they actually do in addition to what we already use, or what risk they may introduce. Thus, to ensure the safe use of these third-party components, there is a library of safe components against which you should always verify your own components. Again, this is a tedious task that is time consuming and frequently results in the omission of some elements.
Add to this the requirement to monitor the security of running applications. Relying solely on network/infrastructure security, such as firewalls and encryption, is highly opportunistic, as applications, particularly web applications, are vulnerable to penetration attempts and should be hardened and monitored. By implementing application security monitoring, you can enforce protection on an application that is also in production, maintain tight control over it, and detect attempts to break into the application.
If you apply a strategy to all of these, you should be covered in terms of application security. However, some of these traditional approaches are also potentially tedious, ineffective, and costly, and are inevitably omitting some security checks due to a lack of time, money, and, most importantly, the human factor, which can overlook obvious security issues.
With security attempting to close the gap between development and testing in terms of testing frequency, tools are becoming more standardized for each development organization. There are numerous tools available, some of which are free and open source, while others are commercial, off-the-shelf products that are all attempting to compete in some way. This also means that customers and procurement organizations face a bit of a struggle to find a tool that meets their needs, which is why there is a lot of emphasis on implementing open source solutions, as they are a good starting point for many and have de-facto become the standard internally. This has both a beneficial and detrimental effect.
The advantage of this is that you will quickly have a tool at your disposal for performing the necessary security checks. However, the disadvantage is that security rules are frequently out of date or are maintained by a small number of individuals, putting you at risk of missing out on the latest security threats on the market.
Regardless of the tools chosen, one fundamental requirement that will be prevalent in 2021 is that the tool of choice must be able to integrate with your CI/CD pipeline, automate security testing, and provide feedback on critical and high severity vulnerabilities, such that the pipeline build will prevent the deployment to production if security requirements are not met. This is critical in 2021, as you want to automate as much of the CI/CD chain as possible.
Generally, any COTS vendor will endorse this approach and provide constructive feedback to the development teams. It is critical that developers receive notification of a security issue and immediately begin resolving it, as this is the only way to improve the overall quality of the software deployed. The goal here is to automate as much as possible from the DevOps perspective, while also adding security to the equation.
However, even if much of the security assessment process is automated, there is still a need for auditing the results of an automated scan. A security auditor is responsible for a variety of tasks, including flagging an issue as relevant and a genuine defect, while other issues discovered may be flagged as irrelevant or even a false positive. And it is within this complexity that much of the complexity associated with security testing and verification exists; even if the process of performing security tests is automated, manual work on identified issues must still be performed. And that requires both time and expertise.
To verify these issues as a security auditor, you must be skilled, quick, and add value to the project. When we consider the fact that the number of developers far outnumbers the number of security auditors, we see that this equation is doomed to remain unresolved.
When focusing on application security from an end-to-end perspective, there are four areas that require special attention. This chapter will attempt to explain the various aspects, the benefits associated with each area, the scope of each area, and how each area differs from the others in terms of benefits. As a software developer and tester, I will follow the delivery chain and attempt to use it as a guide for implementing the various security verification techniques.
SAST is defined by Gartner® as "a collection of technologies for analyzing application source code, byte code, and binaries for coding and design conditions indicative of security vulnerabilities." SAST solutions perform a "inside-out" analysis of an application in a non-running state.
This implies that when performing a static application scan, three things should be considered: how the regular source code is managed with a particular emphasis on security, how the compiled byte code is composed, and finally, how the final binary is validated and verified for security issues. These three distinct areas are fundamentally distinct in their execution, as are the content checks. Modern tools, particularly those from large vendors such as Synopsys, CheckMarx, and Micro Focus, place a premium on all three of these areas.
Several techniques are used during the application scan execution. According to OWASP®, the major techniques are:
Each of these techniques examines a different aspect of the code and produces a comprehensive report that informs you as a developer where an issue exists, what you should do to resolve it, and which areas within a security body the issue originated from (OWASP, CWE, PCI/DSS, GDPR, etc.).
The benefit is self-evident; by utilizing a robust SAST automation tool, you will quickly identify defects spanning multiple techniques. However, there is a clear disadvantage to this as well. The sheer volume of issues that you discover can be overwhelming, perplexing, and in some cases, difficult to prioritize. We will discuss how this is handled in greater detail in the AI section of this document.
Nowadays, the majority of development organizations leverage the vast libraries available on platforms such as GitHub, Gitlab, and others. Numerous libraries have been developed in order to create solutions that meet your specific requirements for completing a task. These libraries are open to all, not just for use, but also for development, refactoring, and improvement. With this in mind, version control of these libraries is critical, even more so when considering security. What assurances do you have about the security of these libraries?
By examining this, we frequently discover the necessity of maintaining a register of "safe libraries." This is currently handled by a number of different organizations and is maintained and verified through the use of open source component analysis. This works by inputting an inventory of the libraries you use into these tools, and you will be presented with a list of components you use that may have security vulnerabilities or have not been verified yet. In these instances, it is clear that these components should be removed. Generally, you will be directed to select a package that has been verified as safe.
Consider implementing one of these libraries and then discovering during production that a hacker updated the package you're using, exposing data to third parties or, worse, injecting code capable of hijacking PCs, as was the case with the NotPetya attack in 2017, which infected customers such as Maersk, Mondelez, Reckitt Benckiser, and others. This is not the sort of thing you want to be associated with. Ascertain that all open source libraries you use are safe, or refrain from using them.
This analysis is a critical component of any security validation, and, as with SAST, the risk assessment process is evolving toward an AI/ML-driven approach.
According to Gartner®, dynamic application security testing technologies are intended to detect conditions indicative of a security vulnerability in a running application. In other words, whereas SAST is concerned with detecting issues prior to putting a system into production, DAST is frequently concerned with the running state, attempting to determine whether the application is vulnerable to penetration using well-known techniques such as SQL injection, command line injection, and cross-site scripting.
From the beginning, critical security flaws such as SQL injection were introduced to the general public in the late 1990s and have remained a well-known threat to any application exposed to the internet since then. When releasing an application to a web portal, it is necessary to conduct a thorough dynamic analysis to ensure that these techniques are covered. It's a time-consuming task, and many organizations lack the resources necessary to conduct all necessary checks prior to go-live. This poses a significant risk, and manual work will once again be overlooked, either by accident or on purpose, relying on development teams to have done an excellent job on security.
To mitigate this risk, several vendors have developed DAST tools that assist in reducing the time required for this process from hours to minutes. Add to this the ability to implement techniques for interactive application security testing, ensuring that you overcome security barriers such as two-factor authentication, identity-based authentication, and similar, difficult-to-automate authentication methods, and you have a solution that gives you a high degree of confidence in identifying issues within an application context.
As with SAST, this process is heavily burdened by false positives and needs to reduce them before forwarding issues to the development organization for resolution. Again, this will be extensively covered in the AI/ML section, allowing you to save time, stress, and frustration without sacrificing quality or security.
The final component of the application security equation is that once the application is deployed, it must be protected from external attacks. RASP is defined by Gartner® as a security technology that is embedded in an application or its runtime environment in order to protect the application.
Traditional operational monitoring focuses on the physical aspects of services or the processes available to the systems in a variety of ways. From a security standpoint, this rarely stands out as sufficiently secure. You must incorporate self-protection mechanisms into your applications in order to have confidence in their security. Today's tools can protect the application surface from hacker attacks based on known patterns and user behavior, and can also block users attempting to exploit available web applications.
The benefit is that you will be able to protect the application against known vulnerabilities, but the world of hackers moves at the speed of light. So what about the yet-to-be-discovered vulnerabilities? We will review these in the following chapter and discuss how machine learning, in conjunction with AI, aids in the generation of threat models.
From a quality and test perspective, it is self-evident that security must be prioritized, and testing teams must act as advocates for a security mindset. With the availability of tools, processes, and frameworks, it is critical to incorporate them into test management and planning, ensuring that testing is included early in the development lifecycle.
As we all know, the sooner an issue is identified and resolved, the more efficient and cost-effective the project will be. This should come as no surprise to test managers. The following chapter will discuss how we can further improve this by leveraging the availability of tools that incorporate and integrate AI and Machine Learning components. To truly embrace DevSecOps, this is a required drill that must be executed flawlessly.
Thor Olav Sørnmo
Thor Olav Sørnmo is a distinguished solutions architect, with more than 20 years experience from multiple roles in the IT-industry. Over the last decade, Thor Olav has been focusing on automation, efficiency and agility in smaller and larger projects, developing solutions that provides commercial value and cost savings for the clients he has worked for. Thor Olav has been focusing on security in the automation space, covering code analysis and application verification using a modern approach and tools that enables deployment at a fast pace.
He is in Capgemini responsible for automation and performance for testing complex software solutions, where security proves to be more and more important to the clients for every month. Thor Olav also liases as an advisor internally for the evaluation of, and procurement of tools for his clients which will bring the best value when evaluation criterias lies withing cost, benefit and long term KPIs, such as improvement in quality and a satisfied end user.
Currently, Thor Olav operates as a managing consultant and advisor to key important clients on a national and global scale for Capgemini, covering test automation and performance testing, in addition to managing the test processes for one of his clients.
Thor Olav is an expert in performance engineering, security testing and verification and also operates and manages test process improvement for clients where this is fit. But he always blooms and brings the most value to his clients whenever he can help in finding ways to automate and effectively manage the processes in development and test, ensuring that innovation is kept alive, delivered rapidly, and with high quality and low risk.
Part of the Capgemini Group, Sogeti operates in more than 100 locations globally. Working closely with clients and partners to take full advantage of the opportunities of technology, Sogeti combines agility and speed of implementation to tailor innovative future-focused solutions in Digital Assurance and Testing, Cloud and Cybersecurity, all fueled by AI and automation. With its hands-on ‘value in the making’ approach and passion for technology, Sogeti helps organizations implement their digital journeys at speed.
Visit us at www.sogeti.com
Capgemini is a global leader in partnering with companies to transform and manage their business by harnessing the power of technology. The Group is guided everyday by its purpose of unleashing human energy through technology for an inclusive and sustainable future. It is a responsible and diverse organization of 325,000 team members in nearly 50 countries. With its strong 55 year heritage and deep industry expertise, Capgemini is trusted by its clients to address the entire breadth of their business needs, from strategy and design to operations, fueled by the fast evolving and innovative world of cloud, data, AI, connectivity, software, digital engineering and platforms. The Group reported in 2021 global revenues of €18 billion.
Get the Future You Want!