Secure and Resilient Software Development, a new book by Mark Merkow and Laksh Raghavan, explains the problems that developers face in designing and building secure software, and where to find resources to help deal with these problems.
The book covers basic principles of secure software, and how to include security in analysis and design and coding and testing. It does a good job of mapping security problems and requirements to available solutions: where you can find training and certification, commercial software and services, and open source tools and checklists, especially tools and checklists from OWASP. It walks through the OWASP Top 10 risk list in detail, and introduces how to use OWASP’s open source Enterprise Security API (ESAPI) library to build secure apps.
The authors lay out a high-level secure SDLC explaining where checks and controls are needed. Like most secure SDLCs, it’s serial, waterfall-based, with gates between analysis and design and coding and so on. There’s no guidance on how to adapt these ideas to Agile methods like Scrum, or to maintenance, but they point to another (inactive) OWASP project CLASP which can help you integrate security controls into the way that you build software.
The book also covers publicly-available software security maturity models: BSIMM and OWASP’s SAMM, used to assess an organization’s software security program and identify gaps and weaknesses. I’ve used SAMM before with my own team as a management scorecard: it helped me structure my thinking and planning on how to improve our software security program. BSIMM is a much bigger beast, intended for enterprise-scale software security programs.
The Enterprise
And there’s the rub. Maturity assessment frameworks, and review-heavy waterfall-based secure SDLCs, are targeted to big companies - like the expensive commercial security testing and checking tools that are also covered in this book. Too much of software security is about the enterprise. There is a lot of money being spent (and a lot of money to be made) here, and big companies have more people and time to invest in software security work as part of their broader risk-management and compliance programs. Software security has made the big time, which is why IBM and HP have bought their way in, and why the remaining independent technology vendors are tooling up for the enterprise (and raising their prices).
Enterprise customers are an important market and this market demands and deserves to be well-served.
The Long Tail
But it’s important to remember the Long Tail.
Sure, a lot of software is built and used by enterprises. But most application software developers will spend their careers working in small software companies or in internal IT groups in small and medium-sized businesses. Small teams like these are looking for simpler and easier ways to build software cheaper and faster and better. Because they can, and because they have to. Agile methods to break projects down into 1-week or 2-week chunks and deliver features to the customer faster. Open source tools and frameworks that work. Practices like unit testing and refactoring that help developers get control over development. Continuous integration, and continuous delivery, even continuous deployment. Ideas applied from Lean Manufacturing to strip out waste. Whatever is practical, whatever helps them to get the job done.
And these ideas and approaches are making it into the enterprise. Teams in enterprise businesses, and in the enterprise software vendors and offshore companies that service big businesses, are adopting lighter-weight project management and development practices because they help them cut costs and deliver faster, and because they work.
There aren’t many small teams that are going to bother with a software security maturity assessment framework, or understand it. BSIMM has 109 different measurement areas: that's around 100 more than most small teams would be able to deal with. And asking small teams who follow Agile practices to measure themselves against a comprehensive process model and work their way up a maturity ladder doesn’t compute. Agile methods were created as a reaction against this kind of thinking and the costs and inefficiencies involved.
It’s important and necessary to find solutions and ideas that will help smaller, faster-moving software organizations – and bigger organizations that are also trying to find ways to move faster. We need practices and ideas that fit with the way these teams work. And that’s not going to be easy.
At OWASP’s AppSec USA 2010 conference, Adrian Lane critically reviewed the security challenges that Agile teams face and the security problems that they create, in his presentation Agile + Security = Fail. As is clear from the title, there are more problems than solutions. Agile teams move too fast for heavyweight security models, they don’t leave time for exhaustive systemic tests and reviews, they don’t have time to do everything right the first time – and they are trying to move even faster.
OWASP tools like ESAPI and the Top 10, and OWASP's secure development and testing guides and secure coding checklists are important and useful resources for developers trying to build secure software. It's good to have a book that points out where to get help like this. And Microsoft's SDL-Agile shows how a company with Microsoft-level capabilities and resources can build secure software using Agile methods.
But we need more. We need more tools and ideas that work for smaller development and maintenance teams, that we can fit in with lightweight methods and that work under pressure. We need patterns and practices that are simple to understand, easy to follow and practical. We need improved languages and frameworks that make it harder to write bad code; and simple and affordable tools that make it easier to find and fix vulnerabilities, because people will still write bad code. And we need the leaders of the development community and the Open Source communities to take security seriously and include security in the way that we build and delivery systems, and in the Open Source code that we share and rely on. We need more solutions that small teams can understand, can afford, and will use.
Because the challenges and problems of writing secure software are both bigger than, and smaller than, the enterprise.
No comments:
Post a Comment