A CISO's Guide to Application Security

CISO Executive Summary

Application security differs in a number of ways from IT security, Network Security, and Information Security, so standard solutions from those domains don’t necessarily address the challenges of Application security. It is a very knowledge-dependent discipline, and defense in depth is rarely achieved with technology solutions alone.

Application security is hard to do well for a variety of reasons: systems are often large and complex; the teams may not have the skills or toolsets to securely design, build, test, deploy, and maintain software; the attackers are frequently more knowledgeable and have better tools than the builders and defenders; development teams often trust without sufficiently verifying the security of the application. Application security vulnerabilities are almost always the result of a failure in the engineering process; therefore solutions must be focused on process improvements, including improved education, standards, and security testing throughout.

Thinking about Application Security

Building and deploying secure applications depends on the following key principles:

Security happens at every phase of the software development lifecycle (SDLC).
Each team member has a different, yet essential, role to play with application security (it’s not just the security team’s responsibility).
The Development Team needs to have the knowledge and the tools to do their jobs successfully.
Security assessment and validation must be performed in every phase of development.
Build a culture of security that encourages and rewards for good application security – make this a part of the business DNA, not just a slogan.

Improving Application Security

People and Organization

Given the challenge of secure software development, each member of the software development team should possess a specific set of skills to perform their security activities:

Executives and managers need to understand the importance of designing and building secure applications from the start and to provide their development teams with the necessary tools, training, and resources to ensure secure applications.
Architects need to create a secure architecture that serves as a blueprint for the developers.
Developers need to understand how to code securely to avoid vulnerabilities in the first place – and how to fix those security defects that slip through.
Testers need to understand vulnerabilities and attack techniques as part of their normal testing program so they can provide feedback on security defects as they are detected.

Robust application security policies and secure coding guidance are necessary to ensure development teams focus on their core competencies – writing software to implement the business rules for the application. Good application security decisions are best left to security professionals, and having a comprehensive set of policies and secure coding guidance ensures consistency in how security is baked into the application.

Process

Developing an inventory of applications and the relevant threats are necessary in order to effectively focus on high-risk areas and efficiently utilize limited resources.

Application security testing is often not done or not done as thoroughly as it should be. Continuous security testing throughout development can dramatically improve the overall resilience of the application by addressing security issues earlier in the lifecycle where it is easier, faster, and less expensive to fix them.

"Security testing" is used broadly and typically implies testing done after coding; but it also should include validating the design and the architecture, developing a threat model to guide design and test efforts, having developers use tools while they are coding to find common security defects, and verifying the security and configuration of the deployment environment. These types of activities uncover security defects in the application architecture, code, and deployment infrastructure before they can be exploited by an attacker.

Technology/Tools

Technology and tools are an integral part of a secure SDLC as they can flag common problems faster than humans. However, tools alone are not a complete solution, and it’s important teams understand the limitations of the tools so the teams can pick up where tools leave off in the form of manual efforts.

If tools aren’t integrated throughout the SDLC, much of their value is lost. It’s important to provide the development team with the appropriate set of tools to address security beyond the traditional “testing” phase and into design and coding phases, too. Additionally, because the technology and tools can be complex and hard to use, it’s important that the development team get the training to understand how to effectively use all of the tools in their toolbox and interpret their findings.

Moving Beyond the Pain Points

The following table lists some common application security pain points and what to do next to move beyond them.

Pain Point	Next Steps
We made a significant investment in tools and haven’t gotten much value from them	Understand the limitations of the tools. Learn how to operate them effectively. Integrate the tools into the software development lifecycle to get full and continuous use.
We are doing automated security code scanning with Static Application Security Testing (SAST) tools, but get large numbers of false positives	Learn how to fine tune these tools and integrate them into the SDLC. Augment with manual code reviews to cover high-risk and security-specific sections of the code.
We are doing dynamic application security testing (DAST) for select applications, but the results aren’t particularly helpful or significant	Manual assessments (penetration tests) are a must to get full security testing coverage Consider 3^rd party penetration tests for high risk/complex applications and leverage their reports to help your team understand what to do going forward
We've done some computer-based training (CBT), but we still have a fair number of security defects in the applications.	CBT training is great for foundational skill building and for groups that are geographically disperse; supplement with instructor-led training with hands-on laboratory exercises that turns the theoretical into practical Provide role, technology, and platform based training to the entire team so each person gets training tailored to their situation.
We often have to do costly design rework as vulnerabilities are found later in development. This costs time and money.	Conduct a threat modeling exercise to "security test" the design to find design flaws before any coding is done. This validates the design and helps ensure the right security controls are built in. Leverage the threat model throughout subsequent phases.

No single tool can adequately defend and protect complex applications. The concept of "Defense in Depth" – multiple layers of defense – should be used to reduce risk. During each phase of the software development lifecycle, there are different activities that help to create a secure application. Each team member has an important on-going role to play in the secure software development process. This has to be backed up with the commitment of resources and the expectation that security is built in, rather than added just before release.