Alex - stock.adobe.com
5 principles for AppSec program maturity
Applications remain a top cause of external data breaches. Follow these five principles to achieve application security program maturity.
Software and applications are present in everything from consumer goods to medical devices to submarines. Many organizations are evaluating their application security, or AppSec, to ensure their strategies are mature and not vulnerable to cyber attacks.
According to Forrester Research, applications remain a top cause of external breaches. The prevalence of open source, APIs and containers only adds to the complexity of the problem.
Most organizations struggle to understand how to approach AppSec program maturity. Given many organizations have switched from Waterfall to Agile in their software development lifecycle (SDLC), practitioners are asking, "How do we continue to evolve our AppSec programs?"
Additional questions include the following:
- How do we build automation at the right interval in the AppSec program and SDLC process so the results of its findings are not overwhelming?
- Do we need to change our application testing plans? How?
- How do we introduce technology and AppSec tooling into our continuous integration/continuous deployment pipeline?
- How do we help developers find issues earlier in the SDLC, so there aren't any surprises when it comes time for a penetration test?
Roadmaps can help navigate these issues. Organizations looking to develop mature programs need to be mindful of inherent team biases. For example, if the AppSec team comes from a pen testing background, the program may lean toward a bias. If the team is experienced in code review, then bias may shine through, too. While both disciplines are important and should be a part of an AppSec program, the experiences may cause bias when a more objective approach is needed.
Many mature AppSec frameworks exist, but a one-size-fits-all approach is not going to work. Every organization has unique needs and objectives around thresholds, risk appetite and budgets. This is largely why prescriptive frameworks, such as Microsoft Security Development Lifecycle, Software Security Touchpoints or Open Software Assurance Maturity Model, are not the answer. It's best to tailor roadmaps on the specific needs and objectives of a particular organization.
5 principles for implementing an AppSec program
These five tenets can serve as a guide for implementing a mature AppSec program.
1. Make sure people and culture drive success
People and organizational culture are what drive the success -- or failure -- of any corporate security initiative. While security education is critical for those in leadership roles, it should also occur throughout the entire organization. AppSec is a part of everyone's job. AppSec should not rest solely on pen testers or business analysts, and it's not just up to quality assurance testers, software developers or people doing deployment or pipeline work.
This point is important, so it's worth repeating: Security is part of everyone's job throughout an organization.
Improve your organization's security culture by developing security champions. Embed team members with a natural aptitude for security into the software development function. Once chosen, these individuals should get extra security training so they can evangelize its importance, challenge false perceptions and advocate that everyone throughout the organization use the same security language.
2. Insist on governance in the SDLC
Setting up governance within the SDLC is critical. If security teams don't define their goals or what security looks like within the SDLC process, it creates too much ambiguity around accountability. From a security vulnerability discovery perspective, creating governance around the SDLC also helps define where an organization needs to build in testing, both manual and automated. More on that in tenet No. 5.
3. Strive for frictionless processes
Friction within any business process is never good. When it comes to AppSec processes, friction can impede progress, create paperwork headaches or result in reputational harm for the organization.
An example of a possible friction point? Remediation timelines.
Many companies set timelines for remediations without considering a project's history. For example, setting an unrealistic remediation timeline -- like 45 days for a project that has never been achieved in that time frame before -- results in friction such as extra paperwork. In the end, the unrealistic timeline simply creates unwanted friction.
Another case? A security policy that forbids developers' access to beta systems -- for example, the rollout of a new iOS system from Apple. If developers aren't granted access before the public launch to set up AppSec programing and test vulnerabilities, it's unlikely a business and its customers will get the full version at the same time.
What if something breaks or a vulnerability is found? Not only will customers be frustrated, but a full-scale emergency remediation must commence. Unfortunately, in this case, the security policy is the friction point. It's understandable if concerns about risks or instability with beta systems arise, but organizations need to balance security and flexibility to best serve their business.
4. Employ risk-based pen testing
When creating an AppSec program, organizations should view pen testing as validation everything implemented in the SDLC is working, not just a discovery of vulnerabilities. Pen testing should be used to determine the effectiveness of your secure SDLC and all automated and manual processes. Organizations often approach this in reverse by starting with pen testing.
Additionally, a platform that offers data points and risk scores helps identify where AppSec is immature and what needs to be prioritized to remediate vulnerabilities with the greatest risk.
5. Determine when to use automation in vulnerability discovery
To build an optimum program, an organization must determine when it's best to use automation in vulnerability discovery and when to employ manual pen testing. In short, an effective AppSec program can manage and deploy threat modeling, manual pen testing and secure code review, augmented with automated vulnerability discovery tools that deploy at various phases of the SDLC process.
For example, automatic testing, such as dynamic scanning, static analysis and interactive security testing, may be sufficient day to day, but manual pen testing is needed when significant architectural changes or technology upgrades to software systems are made. Finding balance in vulnerability testing is important. It isn't an either/or.
What does an organization do once its AppSec program is mature? First, decide if a mature program is a long-term goal. Obviously, security always needs to be a priority, but ongoing maturity programming is expensive and time-consuming. Second, there will always be areas that need more attention. While addressing them, organizations should share their program success with the broader market. Use AppSec maturity to drive customer and team member morale, brand differentiation and market leadership.
About the author
Nabil Hannan is a managing director at NetSPI. He leads the company's consulting practice, focusing on helping clients solve their cybersecurity assessment and threat and vulnerability management needs. Hannan has over 13 years of experience in cybersecurity consulting from his tenure at Cigital/Synopsys Software Integrity Group, where he built and improved effective software security projects, such as risk analysis, pen testing, secure code review and vulnerability remediation, among others.
