Application security is integral to software development, and the majority of organizations now have dedicated AppSec programs. In the past five years, there has been a marked cultural shift, with application security becoming a strategic initiative that spans departments rather than an activity, like periodic scanning, code reviews, or testing or a transactional event related to a security assessment.
Several factors are driving the rethinking of AppSec as a broader strategic program, including the evolving threat landscape, the adoption of nimbler, more incremental software development frameworks, like Agile, and recent trends in things becoming deliverable as code, as with infrastructure as code and security as code.
With the acceleration of software development and the deeper-than-ever role of code in modern business infrastructure, application security is having to shift further left in the process and infuse every step to make sure that the products reaching customer hands can be trusted.
What Is Application Security?
Application security infuses every step of the process of creating trustworthy software. It includes security testing and having the right technical tools, but goes further than that. An effective application security program also pervades the processes your teams use to develop software and the culture of your teams developing it. Looking at security through all these different lenses from design through the release cycle, and building a program that addresses security from all of these different perspectives, will put you in the best position to produce secure products.
Trust in an Era of Supply Chain Attacks
Attackers are evolving along with technology. With the increased digital transformation across industries with access to valuable information, they have realized that instead of focusing solely on individual targets, it can be a better use of their time to target their targets’ vendors. The highest-profile example of this is the SolarWinds breach, where an attacker compromised the build process of a network monitoring tool and pushed a malicious update that made it onto corporate and government networks. Since the network monitoring tool was a trusted product that had access to sensitive data, the attackers gained access to that sensitive data as well.
With major companies and government agencies compromised as a result of the breach, this made it clear to companies of all sizes that depend on software products that they need to take their vendors’ security into account. However, supply chain breaches affect more than just SolarWinds and their clients: according to the 2022 Verizon Data Breach Investigation Report, 62% of intrusions connected to supply chain breaches.
More than ever before, clients are asking about the information security programs of their vendors, since their own security depends on the products they trust. This is not only stemming from a general sense of concern, but also from increased regulatory activity around supply chain security. In light of the SolarWinds attack there has been an executive order dictating increased security precautions and supply chain scrutiny. Congress is also debating bills that will require increased coordination on cybersecurity initiatives between federal, state, and local governments, as well as building a federal supply chain security training program.
This all means that if you are releasing a product and want to earn the trust of customers and potential customers, you need to build an application security program.
Issues an Application Security Program Can Address
An application security program can address a range of security vulnerabilities. A strong place to start when building and tuning the focus of your application security program is the OWASP Top 10, an industry-respected summary of the most pressing vulnerabilities. Revised periodically, the OWASP Top 10 highlights common security vulnerabilities that are present in applications. And, like the real security landscape, the most recent version has shifted to encompass a broader view of what application security means.
Part of application security is code-level security. Code-level issues are the classic vulnerabilities you think of when penetration testing software. These issues include input validation problems like cross-site scripting and SQL injection, as well as other problems like buffer overflows or remote code execution. These are the kinds of issues that relate to using insecure methods in code, and are often addressed with code scanning or secure coding training.
However, application security begins before the first line of code is ever written. In addition to the instructions in a piece of software, a program also needs to pertain to the choices made in how applications solve problems. Solving design-level problems requires performing threat modeling in the initial planning stage, as well as when new features are added. This threat modeling can then inform the choices of algorithms, frameworks, libraries, authentication, and cryptography for solving each problem.
Design-level considerations also extend to configuration: in these times of DevOps and cloud, software is more configurable than ever. Providing customers with secure software requires building in the necessary tools for a customer to run your software securely, and making those configurations accessible to clients who are implementing software. Just because a security option exists does not mean it is well-designed; it needs to be usable and documented, so clients can make informed choices about the best way to implement your product.
Application security also extends to the environment in which software is built. After all, the SolarWinds compromise occurred because attackers were able to compromise the build process and get their malicious update pushed as if it were a real SolarWinds patch. Weaknesses in your build environment can include over-privileged accounts, accounts with weak or hardcoded passwords, or unpatched development tools or machines. Even if your developers follow coding best practices as they design or write the software, a weakness in your development environment can be the best way in for an attacker who wants access to your customers’ data.
Elements of an Application Security Program
Application security is not just a technical initiative. Building a strong program is about integrating security through company culture, its processes, and its technologies. By making security part of every step of the application lifecycle, issues are addressed sooner in the process and customers get more secure software.
People
It used to be that application security, and cybersecurity in general, was a team that operated completely separately from developers. They acted like the gatekeepers: they assessed the software, informed developers when things were not secure, and informed them what needed to be fixed before the product reached the wider world. However, especially with more incremental software development, that is no longer the case.
Though there is still a role for application security experts, modern security requires breaking down silos and building a security culture across everyone involved with a product. Cybersecurity experts can no longer be detached gatekeepers. Instead, they must be familiar with the business goals and software development processes, and know what the developers do day in and day out. With that knowledge, they can communicate on an ongoing basis with developers to design and improve a security program that supports the software lifecycle, as well as help developers build security skills, consciousness, and mindset. Through this, as developers build their knowledge of designing and writing secure software, developers can also build the engagement needed to keep learning and contributing to the security culture on their product team.
Processes
A team cannot build secure software without secure build processes. After all, the build process is what developers are doing day in and day out to create the product that customers are trusting. Secure build processes should be documented and revised to embrace security best practices, but that is only part of the story. After all, a piece of process documentation is not going to stop an attacker. As part of securing the build process, you must ensure that developers are actually following those security best practices while building software. You need to be able to monitor what they are doing on a daily basis, and continuously improve both compliance and coverage of the policies themselves.
Technology
Though technology is not the whole picture of software security, it is still an important part of the software security picture. Modern software development depends heavily on external libraries, so the security of software depends on choosing secure libraries and implementing them properly. Tools in the build environment such as IDEs, compilers and interpreters, and version control platforms also need to be implemented securely, and configured in a way to support secure development. It also matters to make it as easy as possible for developers to use a secure build environment, meaning that teams should use automated tools that allow for repeatable deployment of appropriately configured and hardened containers and virtual environments.
Security automation is also a key technical component of a modern application security program. Software teams should integrate static analysis tools throughout the process, since they can help identify security vulnerabilities at check-in as well as further along in the development of features. As versions of software get closer to release, dynamic analysis is also important to test business logic and find issues. Finally, security automation also includes repeatable deployment of containers and virtualized environments, in order to ensure that.
Application Security Trends
As you build your application security program, keep these trends in mind.
Security Champions
In recent years, security champions programs have risen in popularity because they are an effective way to scale up security capabilities and culture throughout different parts of the business. A few security experts will never be enough to build security at the scale of an entire business, which can be a problem as more and more responsibility for security is shifted away from a dedicated security team and toward the day-to-day operations of product teams. With a security champions program in place, it is easier to scale up security: a central application security team can work directly with the security champions, who can then work with their own teams to strengthen security capabilities.
Security Automation
Given the scale and pace of modern software development, security automation is taking flight. Going faster is the name of the game: customers expect more tools and more features. They need it at a pace where not all software testing can be manual. Tooling needs to be smart, and manual assessment needs to be targeted to the places where effective automated tooling does not yet exist.
However, security automation cannot effectively be put into place in a company that has not modernized its approach to application security. With incremental development methodologies becoming the new norm, security testing has gone from a monolithic penetration test every year, or before each new major release, to a part of the development of each new feature or update.
Modern security automation means that security testing is happening throughout the development cycle: from linting in the IDE to static code analysis to dynamic code testing, as well as automated ways to deploy containers and virtual environments for developers. Using this broad range of security tooling effectively requires smooth integration with the development process, and security buy-in throughout the team.
Threat Modeling
The role of threat modeling is still taking shape. The idea is one that security experts can universally get on board with: identifying and understanding the potential threats against a product, figuring out how to mitigate those threats, and then validating and adjusting the model and mitigations as necessary. In modern incremental software development, thread modeling is relevant throughout the lifecycle, since each new feature or update can have an effect on the threat model. However, security experts still dispute how best to do it, including how much should be done manually or through tools.
Challenges in Creating and Maintaining an Application Security Program
As you build or modernize your application security program, it helps to think about common challenges now so you can be ready to overcome them.
Resourcing
The most common challenge in building a stronger application security program is resources. Hiring and retaining experts is difficult. Finding the right professional can be hard due to the skills shortage, and keeping them on staff can be just as difficult given the high demand for security experts. The demand for application security experts is expected to increase as well, especially given the increased regulatory focus on supply chain security.
Even if an organization decides that it will best be able to build its security program with the help of an outside partner, choosing the right one is another challenge. Being able to effectively execute a security strategy requires a broad range of skills. After all, it is not just about standing up a tool or two. It requires knowledge of the full range of development and security tools to support secure product development, as well as the ability to guide the people and process aspects of a security program. Before committing to work with a partner, you need to make sure that they have the full range of skill sets necessary to not only suggest a security program, but help you enact it and help you build the culture and capabilities you need to sustain it.
Sustaining and Assessing your Program
Sustaining a security program, in particular, is a challenge all its own. As the threat landscape changes, and as the available methods and tools for software security change, a good security program is able to adapt. Part of an effective security program is being able to assess what is and is not working in your current program, improve upon what could be working better, and embrace new capabilities as they become available and practical. This requires both the momentum to keep applying energy toward improvement without getting discouraged when things do not work as well as hoped, as well as the expertise to assess and update the program.
Working with the right partner can help you face this challenge, as well. In addition to having a broad skill set, they can bring the experience of working with a broad range of clients and initiatives. That experience can help them avoid pitfalls from similar situations in the past. It also helps you stay focused on building your security program, since they have been through those cycles of trial and improvement before.
Assessing an Application Security Program
Building an application security program is a serious commitment, and being able to track its progress and justify its business case is crucial. Fortunately, there are industry-standard frameworks that can help you assess the strength of your program.
OWASP Software Assurance Maturity Model (SAMM) is an open-source and community-driven model for analyzing, quantifying, and improving the secure software development lifecycle. It is not limited to a particular technology stack or choice of processes. It can help your business identify the state of its software security program, target improvements, and see how well those development efforts are working. Building Security In Maturity Model (BSIMM) is another prominent framework for measuring the effectiveness of a software security program, released under a Creative Commons license and based on an ongoing study of participant firms.
Whether you choose to assess against SAMM or BSIMM, the process for quantifying your security maturity is similar. You would start with a gap assessment or a maturity assessment, to determine where your program is and score it against the framework. Then, your company can take the next steps toward improving your posture against the framework. In this place, working with a partner can also be helpful. Though the frameworks make it clear how to measure your security posture, an experienced partner can help you understand the gaps and make the most impactful decisions for improving your security posture in light of the product you are creating and the threats you are facing.
Moving Forward with Application Security
With the increasing focus on supply chain security, customers have never cared more about the application security practices of the companies who create their software. A strong program will help you maintain client trust and satisfy their security as well as regulatory needs.
To learn more about next steps for defining and implementing an application security program and how the experts at Kroll can help, talk to us today.
