Working your flanks: a new approach to application security

This is the second part of the application security series; the first is Seven common mistakes of secure software development programs. Like all other business investments, cybersecurity investments are business investments, prioritized by risk to get the most value from them — and as cybersecurity professionals, most of us are aware of this fundamental principle. Yet we find ourselves taking a purist view of our investments and treating cybersecurity as an absolute. As the focus on cybersecurity increases, a more pragmatic, value-based approach is far more pertinent. The concept of putting cybersecurity investment where the business gets the most value is the key behind this approach.

An application security program usually starts with a benchmark assessment against a set framework or standard — BSIMM, Microsoft SDL, OpenSAMM, or something similar. Once a gap analysis is complete, an organization has an idea of what it might be lacking in its Secure Software Development Lifecycle (SDL) practice. This starts the process of creating new processes, introducing security tools, training, and other skill-development initiatives to achieve the desired results and maturity, measured against the selected framework.

Sometimes achieving a certain level of maturity is the overall objective; at other times the goals are more tactical. This article does not debate which is the better approach, but recommends one that is not based on the maturity of the process but on overall risk reduction as the clear outcome of any SDL process. Over time, the maturity of the implemented processes can help you sustain your efforts; but the first and foremost goal should be an immediate, short-to-medium-term risk reduction. How safe is the organization today compared to yesterday? This pragmatic approach, coupled with some maturity targets, provides a meaningful reduction of risk and significantly more return on cybersecurity investment.

As the industry has adopted Agile and CI/CD methodologies, it has become increasingly clear that cybersecurity has to move at the speed of the business. Cybersecurity practices should not become a roadblock but a value-add that allows the business to deploy functionality to customers with a significant reduction in the risk of a breach or major incident resulting from insecure software development practices.

There has been a lot of focus on moving to the left side of the SDL: threat modeling, security training, and static and dynamic code analysis as early in the development lifecycle as possible. However, through the deployment of these practices, we have observed the following shortcomings, which usually manifest a couple of years after an SDL program is implemented:

1. Security training is at best an evangelization exercise; the engineering workforce does not develop meaningful secure-development skills through it.
2. Due to the high turnover of the engineering workforce, training has to be administered continuously, and changes in leadership support and business priorities can undermine the program.
3. Static code analysis creates significant false-positive rates, resulting in significant time from the security and engineering teams to validate the results and implement fixes.
4. The whack-a-mole approach of static and dynamic analysis leads to engineering fatigue, where the workforce feels these are tasks without a clear win. Coupled with Agile and CI/CD, this can introduce a defeatist mood among engineering organizations and reduce enthusiasm for SDL initiatives.

Based on these observations, this article introduces a new approach: moving cybersecurity investments to the right and the left of the SDL. Instead of focusing on security training and static and dynamic analysis, we recommend the following.

Move to the left

1. Increased emphasis on threat modeling during the design phase of any engineering project, focused on core design elements, and taking the most time. This must not be skipped: insecure design-level decisions are the hardest to fix in live applications and create legacy security issues that are hard to remediate. To scale, threat modeling should be embedded into development workflows and streamlined to focus on the key design elements not covered by non-functional requirements (NFRs). If the organization uses STRIDE, the following can be moved into the security NFRs:
   • Mandating HTTPS across all development projects protects against spoofing, tampering, and information disclosure.
   • Mandating multi-factor authentication for identity systems prevents spoofing through stronger authentication.
   • Mandating log generation for all critical application functions mitigates non-repudiation.
   • Standardized, vetted access-control and authorization systems reduce the risk of information disclosure and elevation of privilege.
   • Rate limiting reduces the risk of denial of service.
   • Standardized security libraries prevent the most common web attacks: cross-site scripting, cross-site request forgery, injection, and so on.
   • Standardized hardened operating systems and application components make exploitation of vulnerabilities harder.

   The short list above can be expanded, but even this list significantly improves the security profile of any application.

2. Increased focus on NFRs, which are often treated as a step-child of the SDL. They should be the focus of the security and engineering organizations. In addition to the ones above, NFRs should be created for the type of application being developed. Whether they are shared as a wiki list of mandatory tasks or through a custom application that adds them to the engineering backlog, they must be implemented and validated as part of each deployment.
3. Integrating security practices into engineering practice. Most engineering organizations have a dedicated engineering practice group, or at least a set of rules and principles that govern the software engineering process. Security teams should leverage this culture and process to inject security initiatives; one of the most effective is the use of standardized security libraries as part of the overall engineering practice.
4. Standardized third-party components across the engineering organization. Again, the use and distribution of these components should be part of the engineering culture.

Move to the right: production environments

Technologies and practices should be evaluated that provide immediate risk reduction against exploitable vulnerabilities in existing, deployed application code. An argument can be made that by not focusing on remediating every vulnerability identified by static and dynamic analysis, we are saving security dollars in engineering and security resources — and perhaps in analysis tooling — and those dollars can be moved to active protection against a vulnerability today. The following should be implemented to the right of the development lifecycle:

1. Active protection against existing vulnerabilities in the application: real-time application protection, web application firewalls, CSP headers, and the like. Implementation falls on the DevSecOps or security team, reducing the cost burden on engineering while allowing the business to keep its velocity with a level of assurance against known, and at times unknown, attacks.
2. Continuous penetration testing, through a bug bounty program or an internal penetration testing team, whichever is more cost-effective. Focus the bug bounty program on logic and access-control flaws to get the most from the investment.

What happens to analysis and training?

Static and dynamic code analysis and security training sit in the center of the SDL, tailored so as not to impede the flow of development. If the organization has an existing investment in these tools, use them to measure progress in the adoption of security libraries and to measure vulnerabilities in code. We would not recommend them as the source for identifying vulnerabilities in the codebase or the application; they have diminishing returns over time. Security training should move from once a year to just-in-time, giving training and assistance to the engineering organization as close to development as possible. Just-in-time training has the most impact on building security skills, and acts as a reminder to follow specific engineering practices.

Wrapping up

By moving to the left and right of the SDL, organizations can improve the security of their application portfolio over a very short period — measured in months instead of years. This approach results in effective, rapid risk reduction by optimizing cybersecurity investment where it matters most, making it much harder to exploit existing vulnerabilities in code, and giving the engineering organization the flexibility to adopt more sustainable SDL practices.