Don’t be the slowest zebra in the herd
At lunchtime on the African savannah, you needn’t be the fastest zebra to survive –you need to avoid being the slowest. You can only be sure you’re not the slowest zebra if you can see what the rest of the herd are up to. Efforts in software security to share information on attacks, responses, and best practices are important to understanding what the herd is doing, writes Paco Hope, software security consultant, Cigital
Banks have long understood the value of shared experience, gathering at oases like the Financial Services Information Sharing and Analysis Centre (FS-ISAC) every year to share critical cyber threats and incident response practices. This kind of collaboration lets the whole herd benefit from best practices that only a few members have discovered or mastered.
By using the Building Security in Maturity Model, many of these same firms are also sharing information about how they build and develop software securely. BSIMM, a free-to-download benchmark of best practice metrics for developing secure software, documents the real-life activities and processes employed by 67 world leaders in software development including leading financial organisations such as Bank of America, HSBC, JP Morgan Chase and Wells Fargo. This data enables CISOs to gauge their own performance across parameters such as policy and governance, threat modelling, security training, configuration and version control etc.
Gathering at the BSIMM Watering Hole
The BSIMM is observational science that offers companies a yardstick against which they can measure themselves. To use another jungle metaphor, we often say the BSIMM tells us ‘monkeys eat bananas’. This observation comes from being in 67 jungles and seeing monkeys eating bananas in about 54 of them. That doesn’t necessarily mean that everyone should eat bananas or that there are right and wrong ways to eat bananas. It simply states a fact based on the evidence available. If you’re a banking technologist – as opposed to a software development expert – this gives you a list of best practices you can pick from when building your own software security practice.From an industry standpoint, financial companies and independent software vendors are two of the most represented groups in the model. For ISVs, software is the product they sell; for banks, software drives their core business. One might expect major differences between the typical BSIMM profiles of these two groups. Actually, this isn’t the case. There are some differences of course, but they are small shifts in emphasis, not dramatically different ways of doing things. For example the financial firms show a bit more average maturity in compliance, policy, and governance. ISVs show a bit more mature activity in configuration management and maintenance of software.
Most important foundational elements, like training, code review, and architecture analysis show very little difference.
Just as a herd shifts around in response to threats, the BSIMM community is a dynamic community that changes over time. The model itself changes as the industry adapts, innovates, and explores new techniques of securing software. ‘Bug bounty programmes’, for example, have been adopted by some BSIMM participants to accept vulnerability disclosures from outsiders. The model was updated for version 6 to assign an identifier to that activity and record observations of it. So, as new security requirements evolve and firms adapt new techniques to improve their software processes, the BSIMM observes, records and shares out those techniques.
When considering what to do to build security into your software, the BSIMM documents the practises of a herd of clever firms. Knowing how your firm scores in the BSIMM is valuable information about your position relative to the herd. After all, as animals know instinctively, there’s safety in numbers and none of us want to be the lone impala, left exposed to all sorts of predators, whilst the rest of the herd has moved on to safer grazing grounds.