BSIMM: Bringing Science to Software Security
•Download as PPTX, PDF•
2 likes•1,197 views
There is an old management adage that says “You can’t manage what you don’t measure.” The Building Security in Maturity Model (BSIMM) applies scientific principles to the field of software security to effectively measure security activities across industries and business units. The BSIMM enables experts like you to discover what exists in the application security universe, how those things work today, how they worked in the past and how they are likely to work in the future.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to BSIMM: Bringing Science to Software Security
Similar to BSIMM: Bringing Science to Software Security (20)
More from Cigital
More from Cigital (17)
Recently uploaded
Recently uploaded (20)
BSIMM: Bringing Science to Software Security
- 1. Science is a way of discovering what's in the universe and how those things work today, how they worked in the past, and how they are likely to work in the future.
- 2. BSIMM: Bringing Science to Software Security info@cigital.com @cigital
- 3. Why study security?“Because I said so” doesn’t work as a strategy.
- 4. Software security axioms • Software security is more than a set of security functions • Not magic crypto fairy dust • Not silver-bullet security mechanisms • Non-functional aspects of design are essential • Bugs and flaws are split 50/50 • Security is an emergent property of the entire system
- 5. In the beginning… We made up prescriptive frameworks: • Microsoft SDL • CLASP (OWASP) • Cigital’s Touchpoints
- 6. BSIMM is a scientific study measuring activities companies are actually doing.
- 7. Measurements matter • Understand today, plan for tomorrow • Metrics drive behaviors • Enable management • Continuous process improvement
- 8. 78 firms in the BSIMM6 Community
- 9. What the numbers tell us BSIMM6 BSIMM5 BSIMM4 BSIMM3 BSIMM2 BSIMM1 Firms 78 67 51 42 30 9 Software Security Group (SSG) Members 1,084 976 978 786 635 370 Satellite Members 2,111 1,954 2,039 1,750 1,150 710 Developers 287,006 272,358 218,286 185,316 141,175 67,950 Applications 69,750 69,039 58,739 41,157 28,243 3,970 Avg SSG Age 3.98 4.28 4.13 4.32 4.49 5.32 SSG Avg. of Avgs 1.51/100 1.4/100 1.95/100 1.99/100 1.02/100 1.13/100 Financials 33 26 19 17 12 4 ISVs 27 25 19 15 7 4 Healthcare 10 Consumer Electronics 13
- 10. Monkeys eat bananas • BSIMM is not about good or bad ways to eat bananas or banana best practices • BSIMM is about observations • BSIMM is not prescriptive • BSIMM describes and measures multiple prescriptive approaches
- 11. A software security framework Governance Intelligence SSDL Touchpoints Deployment Strategy and Metrics Attack Models Architecture Analysis Penetration Testing Compliance and Policy Security Features and Design Code Review Software Environment Training Standards and Requirements Security Testing Configuration Management and Vulnerability Management
- 12. Example domain Intelligence: standards and requirements Objective Activity SR1.1 meet demand for security features create security standards (T: sec features/design) SR1.2 ensure that everybody knows where to get latest and greatest create security portal SR1.3 compliance strategy translate compliance constraints to requirements SR1.4 tell people what to look for in code review use secure coding standards SR2.2 formalize standards process create a standards review board SR2.3 reduce SSG workload create standards for technology stacks SR2.4 manage open source risk identify open source SR2.5 gain buy-in from legal department and standardize approach create SLA boilerplate (T: compliance and policy) SR3.1 manage open source risk control open source risk SR3.2 educate third-party vendors communicate standards to vendors
- 13. Example activity [AA1.2] Perform design review for high-risk applications. The organisation learns about the benefits of architecture analysis by seeing real results for a few high-risk, high-profile applications. The reviewers must have some experience performing architecture analysis and breaking the architecture being considered. If the SSG is not yet equipped to perform an in-depth architecture analysis, it uses consultants to do this work. Ad hoc review paradigms that rely heavily on expertise may be used here, though in the long run they do not scale.
- 14. The software security group (SSG) • Security as a day job • High expertise • “Group” level or central role • Cross business units / projects
- 15. The “satellite” • Not directly part of the SSG • Developers, testers, architects • Have an affinity for security
- 16. Real world data Software Security Initiative Age Software Security Satellite Size Average 4 years Average 27 people Newest 5 months Smallest 0 people Oldest 12 years Largest 400 people Median 3 years Median 3 people Software Security Group Size Development / Engineering Staff Size Average 14 people Average 3680 people Smallest 1 person Smallest 23 people Largest 130 people Largest 35,000 people Median 6 people Median 1200 people
- 17. Scorecard Overview • Number of firms performing various activities • Highlighted activity is most popular in its practice
- 20. Lessons learned • Your company isn’t unique • You’re on your own when it comes to getting started • Your security team can’t do everything • Security still needs people • Security usually exists before the security team
- 21. What do you do next? • Read the BSIMM report at www.bsimm.com • Join the BSIMM community • Measure your program • Build security in
- 22. BSIMM: Bringing Science to Software Security info@cigital.com @cigital
Editor's Notes
- (Screen that greets attendees while they wait for the session to start)
- (Share session ground rules, introduce Paco)
- If we think about application security the same way we think about science then we know that advancement and improvement come from refining and expanding our knowledge based on what we already know. While “Because I said so” may sufficient when dealing with a toddler, it isn’t enough to build your security program.
- Discuss the difference between the prescriptive and descriptive methods
- Detail how and why BSIMM got its start. First released in 2008. BSIMM-6 was released on 10/19/15 BSIMM-6 now includes data from 78 firms and the data set is made up of 202 measurements. BSIMM-6 describes 112 activities in 12 practices During the lifetime of BSIMM more than 100 firms have been measured for a total of 235 measurements (some firms measured multiple times and others have had multiple divisions measured separately) BSIMM-Vdescribes the work of 974 SSG members working with a satellite of 1954 people to secure the software developed by 272,358 developers. (this detail needs updated The BSIMM remains the only measuring stick for software security initiatives based on science. It is extremely useful for comparing the initiative of any given firm to a large group of similar firms. The BSIMM has been used by multiple firms to strategize and plan their software security initiatives and measure the results. Finally, FWIW, the government is woefully behind when it comes to software security.
- By measuring where you stand with you software security initiative you can also determine how to evolve your efforts over time. With an assessment you gain Visibility Visibility into the current status of an existing functional area or process Education and a common language Lexicon for the information security team to communicate with and educate stakeholders and sponsors Improvement Enable better management, promote informed decision-making, and drive change throughout the organization
- See the informIT article “Cargo Cult Computer Security”(January 28, 2010) http://bit.ly/9HO6ex
- With the activities that we observed, we were able to categorize them into 4 domains and 3 practices per domain (making a total of 12) (if asked) The four domains are: 1. Governance: Those practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice. SM: planning, roles and responsibilities, identifying metrics and gates. CP: identifying controls for compliance, SLAs, software security policy, auditing against that policy. Training. 2. Intelligence: Practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization. Collections include both proactive security guidance and organizational threat modeling. AM: think like an attacker: TM, abuse case, data classification. SFD: security patterns for major security controls, building middleware frameworks for those controls, proactive security guidance. SR: security requirements, standards for major security controls & technologies, standards review board. 3. SSDLTouchpoints: Practices associated with analysis and assurance of particular software development artifacts and processes. All software security methodologies include these practices. AA: concise diagrams, applying lists of risks and threats, process for review. CR: use of CR tools, customized rules, tracking/measuring results. ST: integrating security into standard QA processes: use of BB security tools, code coverage analysis. 4. Deployment: Practices that interface with traditional network security and software maintenance organizations. Software configuration, maintenance, and other environment issues have direct impact on software security. PT:vulnsin final configuration, direct feed to defect management and mitigation. SE: OS and platform patching, Web application firewalls, application monitoring, code signing. CMVM: patching and updating applications, version control, defect tracking and remediation, incident handling.
- Explicit security requirements, recommended COTS, standards for major security controls, standards for technologies in use, standards review board.
- There is a paragraph like this describing each of the 112 activities. Note the REAL examples.
- This is the 78 firm raw data about activities. Each highlighted activity is the most common one one for each practice.
- Spider graphs have been created with the 78 firm data. This is the curve for all 78 firms in the study. This is a comparison of a FAKE firm’s high water mark score against the top 10 curve. Note where the blue is INSIDE the orange. These are practices where the firm is substantially behind what we have observed elsewhere. In general, firms with a“round”curve have a more balanced program than firms with a“prickly”shape or worse yet a“butterfly”shape. Remember, this is not a value judgment, it is simply a comparison to what other firms are doing.
- A higher-resolution view of the same data shows how the spiderdiagram curve relates to the 112 activities in the BSIMM. We have also highlighted the 12“things that everybody does”for a quick comparison of the basics. Blue shift practices are those practices in the spider diagram (see previous slide) where the firm was behind the average. By noting which activities other firms are carrying out in those practices, the target firm can create a data-driven strategic plan.
- These bullets tie to a piece we are developing based on feedback from Sammy which covers things they’ve found to be interesting while doing measurements over the years. Will forward draft copy of this to you.
- (Share session ground rules, introduce Paco)