Best Practices for Driving Software Quality through a Federated Application Security Responsibility Model
0 likes149 views
The document outlines best practices for improving software quality through a federated application security (AppSec) responsibility model, emphasizing the need to bridge the gap between security and development. It highlights the importance of integrating AppSec into DevOps workflows while maintaining security policies and compliance, aiming to empower developers and streamline vulnerability management. The document also discusses the challenges of achieving uniform buy-in from stakeholders and proposes solutions for effective issue routing and prioritization of security risks.
Best Practices for Driving Software Quality through a Federated Application Security Responsibility Model
- 1. Best practices for driving software quality through a federated application security responsibility model
- 2. 2 The growing chasm between security and development Application Security Tools Back Office Systems (2000) Software Development Velocity Risk Chasm • No visibility into software vulnerabilities or risk • Unable to prioritize remediation • Remediation slows software delivery • Conflict between development and security TheDigitalTransformation • Financial Services • Healthcare • Manufacturing • Retail • Transportation • Education • Power & Energy • Media & Hospitality Software-Defined World (2020s)
- 3. 3 Risk Management Security Compliance Traditional, Centralized IT De-centralized IT Federated Responsibility Model DevOps guides a new model for AppSec
- 4. 4 • Maintain corporate standards for security • Define security policies centrally, enact locally • Enforce security policies based on application and business risk • Deliver board-level metrics and reporting for security, risk, compliance Maintain Enterprise Control The foundations of the federated responsibility model for AppSec • Integrate AppSec scanning automation and orchestration into DevOps pipelines • Continuously scan for vulnerabilities without slowing delivery • Streamlining vulnerability findings into meaningful and manageable outputs • Reduce release friction by accelerating vulnerability discovery and prioritizing remediation Accelerate Pipeline Velocity • Meet security standards without impacting DevOps workflows • Prioritize vulnerabilities for remediation by risk and business impact • Enable developers to enact security, without interacting with security tools Empower Developers
- 5. 5 The value of the federated AppSec responsibility model Provides Board/LOB/enterprise and governance reporting on software risk, compliance, pipeline and development productivity Balances centralized security policy with the velocity and agility of DevOps Facilities a partnership between product, engineering and operational teams Motivates development teams to prioritize security even with the demands of pipeline velocity Provides oversight for the deployment of AppSec strategies across disparate DevOps teams and toolchains
- 6. 6 Common Challenges Uniform Buy-in from all stakeholders • Rowing in the same direction Consistently Inconsistent • Application Security and Heterogeneity, name a more iconic duo Issue Routing • Who should be told about what, when, and how What to Fix & When • Not everyone will agree on what should be prioritized
- 7. 7
- 8. 8 Uniform Buy-in from all Stakeholders • Who are we talking about? • Application Security Team/Product Security Team (probably not a problem) • Application Development Team • DevOps Team/IT Operations Team • Business Leadership &/or Corporate Governance Why would anyone not want to embrace a Federated Responsibility model? • "That's not how we do things" • Security is outside of their comfort zone • Unclear how AppSec ties into their role
- 9. 9 How to get Uniform Buy-In • Olive Branches - Give the stakeholders something they can't get anywhere else • Providing useful reports that they couldn't produce themselves • Providing a strategic view • Simplifying something those stakeholders must perform periodically (like scans for compliance) Acknowledging the sins of the past • If there's been friction and adversity in the past, ignoring that history won't resolve itself. Acknowledge the prior pains caused by the AppSec program of yesteryear • AppSec is now a resource to support development, not a barrier to delivery Proof in Doing • Find an Application team that is friendly towards the AppSec Program and focus on enabling that team • Once you can point to that success, it's easy to get additional buy in
- 10. 10
- 11. 11 Consistently Inconsistent • Application Portfolios are diverse • Code Languages • Web Application Frameworks • Application Architectures • Build Processes • Security Assessment Tool Portfolios are diverse • Scan types (SAST/SCA/Container/DAST/Network/Cloud Environment/etc.) • Language & Framework Affinities • Scan Execution Models (Host Based/Agent Based/Passive/Active) • Data Outputs (Risk Scoring/Verbosity/Remediation Instructions/Issue Granularity) • Which scanners and how to implement them may wildly vary across you App Portfolio. That's a lot of snowflakes and nobody has time for that.
- 12. 12 How to Solve for Seemingly Infinite Inconsistency • Identify the meaningful attributes about your applications that demand differentiation • What are the coding languages present in your Application Portfolio? Does your SAST tool support them all? What about new languages like Golang that pop up? • What are the CICD platforms the Application/DevOps teams use? Centralized or discrete for each App? • How do your Web Apps handle user authentication? You'll need to authenticate past the login page to perform DAST assessments. Do all the Apps use the same auth layer? How does QA get past the login page to perform regression tests? Build a playbook to make the App onboarding process simpler • Based on these differentiating attributes, you can put together standard "Plays" – e.g. All Java apps built on the centralized Jenkins instance w/ no external facing Web App surface area will be scanned by X & Y at build time, and Z during QA. Normalize and abstract the scans so Dev & DevOps don't have to see how the AppSec sausage is made
- 13. 13
- 14. 14 Routing the issues to the right people • When people receive communications that aren't pertinent to them, they will cognitively suppress those messages in the future • If the person responsible for remediating an issue isn't aware there is an issue, risk will never be reduced. It's not always obvious who is responsible for fixing any given issue • It's incumbent upon AppSec to intelligently route issues to the right people or teams in a way that engenders engagement • The structure and content of the message is as important as the accuracy of delivery – you can't email a CSV file with 30k issues and expect someone else to sort it out • This is extremely hard and is a problem that scales geometrically as organizations grow
- 15. 15 How to Overcome the Issue Notification Barrier • Use existing resources (organizational connectors, reference data sets like CMDB/App Portfolio/IPM/Active Directory Groupings/etc.) • No tribal knowledge – document what gets sent to whom • You'll likely already know a lot of this intuitively – doesn't scale, nor does it hold up when something falls through the cracks. As you uncover new routing pathways that need to be supported, document those communication lines in one place • Determine what an issue notification will look like before you send the first communication • What is the minimum amount of information the remediator will need to resolve the issue? How will that effort be tracked in the remediator's tasking/ticket system? What happens if it should go to someone else? • Make the deliverable consistent with the other task/tickets that the remediators interact with • Security issues shouldn't be some alien format or wall of text - ask to see samples of functional bug tickets and model after that syntax
- 16. 16
- 17. 17 What to fix and when? Low/High High/High High/LowLow/Low Effort to Remediate RiskReduced • Getting to agreement on risk and effort to fix • Remediation prioritization matrix • Everyone agrees on two out of the four boxes – focus on the low effort, high risk issues first, deprioritize the high effort, low risk issues • What to fix after low/high? Development teams tend to focus on low/low next. AppSec teams tend to focus on high/high next • How does a business prioritize what to fix after the obvious stuff?
- 18. 18 How to Agree on What to Fix Next? • Most applications have enough low effort/high risk remediations to tackle that this challenge may not emerge for a year or more • Backlog vs net-new issues: ongoing scanning throughout the SDLC reduces the likelihood of newly introduced issues that are high risk or high effort to remediate, so typically this problem is isolated to the backlog of security issues • Both teams are right some of the time – bricks & mortar • Low effort/low risk issues should be tackled in an ongoing fashion • High effort/high risk issues need to be addressed in concert with the Development team's initiatives. As the development team rearchitects parts of their app, AppSec can piggyback to remediate issues related to the components that are being rebuilt • Compensating controls/individual point remediations to reduce risk in the near-term, but only if there is an acknowledgement that
- 19. 19 ZeroNorth AppSec Automation & Orchestration Platform
- 20. 20 A Federated Responsibility Model for AppSec Uniting security, DevOps & the business Maintain Enterprise Standards Enable corporate security to enact centralized tools & standards – and gain visibility for risk & compliance Unburden & Empower Developers Arm developers with tools to deliver secure software without disrupting DevOps processes Accelerate Pipeline Velocity Pinpoint critical risks earlier to avoid late-stage discoveries that jeopardize software releases
- 21. 21 Learn more or request a personal demo at zeronorth.io Check out the new Federated Responsibility for AppSec White Paper: go.zeronorth.io/frm