This is the second part of the Application Security series. Here is the link to the first part, Seven common mistakes of Secure Software Development Programs. Like all other business investment, Cybersecurity investments are business investments prioritized by risk to get the most value out of the investment and as Cybersecurity professionals most of us are aware of this fundamental principle. Yet we find ourselves taking a purist view on our investments and taking Cybersecurity as an absolute. However, as the focus on Cybersecurity increases, a more pragmatic, value-based approach is a lot more pertinent. This concept of Cybersecurity investments where the business can get the most value is the key behind our new approach.
An Application Security program usually starts with a benchmark assessment against a set framework or standard, like BSIMM, Microsoft SDL, OpenSAMM or something similar, there are a few out there. Once a gap analysis is complete an organization will have an idea of what they might be lacking in terms of 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 overall desired results and maturity measured against the selected framework.
Sometimes achieving a certain level of maturity is the overall objective while at other times the goals are more tactical. The article does not debate which is a better approach but recommends one that is not based on the maturity of the process but rather an overall risk reduction as a clear outcome of the implementation of any SDL process. Over time, the maturity of the implemented processes can help you sustain your efforts, however, 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 will help provide a meaningful reduction of risk and significantly more return on Cybersecurity investments.
As the industry has adopted Agile and Continuous Integration/Continuous Deployment (CI/CD) methodologies, it has become increasingly clear that Cybersecurity has to move at the speed of the business. The Cybersecurity practices should not become a roadblock but a value-add that allows business to deploy functionality to customers with significant risk reduction — against a breach or a major security incident resulting from insecure software development practices.
There has been a lot of focus on moving to the left side of the SDL, focusing on threat modeling, security training, static and dynamic code analysis as early in the development lifecycle as possible. However, through the deployment of these SDL practices, we have observed the following shortcomings which usually manifest a couple of years after an SDL program is implemented.
1. Security training at best is an evangelization exercise and engineering workforce does not develop meaningful secure software development skills through this exercise.
2. Due to the high turnover of the engineering workforce, training exercises have to be administered continuously and additionally, change in leadership support and business priorities can impact the effectiveness of the training program.
3. Static code analysis creates significant false positive rates resulting in significant time investments from the security and engineering team to validate the results and implement fixes.
4. The whack-a-mole approach of Static and Dynamic Code Analysis leads to engineering fatigue, where the workforce feels these are tasks without a clear win. This coupled with agile, CI/CD approach can introduce defeatist mood among the engineering organizations leading to reduced enthusiasm for SDL initiatives.
Based on these observations the article introduces a new approach — moving Cybersecurity investments to the right and left of the SDL. Instead of focusing on Security training, Static and Dynamic Code Analysis we recommend the following:
Move to the left:
1. Increased emphasis on Threat Modeling during the design phase of any engineering project with a focus on core design elements and should take the most time. This must not be skipped as it is often the case that insecure design level decisions are the hardest to fix in live applications creating a legacy security issues which are hard to remediate. In order to scale, Threat modeling should also be embedded into the development workflows and streamlined as much as possible to focus on key design elements that are not covered by Non-Functional Requirements(NFRs). See details below:
If the organization is using STRIDE, then the following should be moved as part of Security NFRs:
· Mandating the use of HTTPS across all development projects will ensure protection against Spoofing, Tampering, and Information Disclosure.
· Mandating the use of Multi-Factor Authentication (MFA) for identity systems will prevent attacks against, Spoofing (stronger Authentication).
· Mandating log generation for all critical application functions will ensure mitigation against non-repudiation attacks.
· Use of standardized and vetted Access Control and Authorization systems will reduce the risk of Information Disclosure and Elevation of Privileges.
· Use of rate limiting will reduce the risk of Denial of Service.
· Use of Standardized Security libraries will prevent most common web attacks like Cross Site Scripting (XSS), Cross Request Forgery(CSRF), Injection Attacks, etc.
· Standardized use of Hardened OS and application components will make the exploitation of vulnerabilities harder.
The short list above can be expanded to cover additional areas, however even the above shortlist will significantly improve the security profile of any application.
2. Increased focus on NFRs, which are often treated as a step-child in SDL. However, they should be the focus of the security and engineering organization. In addition to the above-noted ones, additional NFRs should be created based on the type of application being developed. Whether NFRs are shared as a wiki list of mandatory tasks or through a more sophisticated approach of using custom applications that can add these to the backlog of the engineering team, this must be implemented and validated as part of each deployment
3. Integrating security practices as part of engineering practices. Most engineering organizations have a dedicated engineering practice organization or at least a set of rules and principles that govern the software engineering process. The security teams should leverage this culture and process to inject security initiatives. One of the most effective ones here is the use of standardized security libraries as part of the overall engineering practice.
4. Use of standardized third-party components across the engineering organization. Again, the use and distribution of these components should be part of the engineering culture.
Moving to the Right (Production Environments):
Technologies and practices should be evaluated that provide immediate risk reduction against exploitable vulnerabilities in the existing and deployed application code. An argument can be made that by not focusing on remediating all the vulnerabilities identified by Static and Dynamic code analysis, we are saving security dollars in terms of engineering and security resources and perhaps even reduced investment in Static and Dynamic code analysis tooling. Furthermore, those dollars can be moved to active protection against a vulnerability today.
The following technology and processes should be implemented to the right of development lifecycle:
1. Technologies that allow active protection against existing vulnerabilities in the application, Real-time Application Protection, Web Application Firewalls, CSP headers, etc, all fall under in this category. The implementation of these technologies falls on the DevSecOps or the Security team, reducing the cost burden from the engineering teams while at the same time allowing the business to keep its velocity with a level of assurance against known and at times unknown attacks.
2. Continuous penetration testing can be accomplished through a bug bounty program or internal penetration testing teams, whichever is more cost effective. The organization should focus on logic and access control flaws for its bug bounty program to get the most out of this investment.
What happens to Static/Dynamic Code Analysis and Security training? These sit in the center of the SDL process and be tailored to not impede the flow of development. If the organization has an existing investment in these tools these should be used to measure progress with the adoption of Security Libraries and measuring vulnerabilities in code. We would not recommend the use of these as the source of identifying vulnerabilities in the code base or the application as they have diminishing returns over time. Security training should be moved from once a year to just-in-time, giving the training and assistance to engineering organization as close to development as possible. Just-in-time security training has the most impact on building security skills within the engineering organization and can also act as a reminder for the engineering workforce to follow specific engineering practices.
Wrapping up:
By moving to the left and right of the SDL, organizations can improve the security of their applications portfolio over a very short period of time, measured in months instead of years. This approach can result in an effective rapid risk reduction by optimizing Cybersecurity investments in areas where it matters most, making it much harder to exploit existing vulnerabilities in code and allow the engineering organization flexibility to adopt more sustainable SDL practices.
I would like to thank Hemanth Srinivasan for his contributions on this new methodology.
