software security assessment network security companies

software security assessment network security companies, originally uploaded by cpusecuritysolutions.

Building secure software isn't as simple as adding cryptography and authentication. Nor is it a matter of plunking down a firewall in front of your Web apps. It's about adjusting the software development life cycle, teaching developers about security, choosing the right tools and techniques for writing code, and adapting the development culture to care about security. Each of these activities is made easier and more doable with not just careful planning but also objective measurement.

Many companies have large-scale software security initiatives. I know of 75 such efforts from my research alone. They cover a broad spectrum of industries, from financial services and independent software vendors to healthcare and energy providers. Any company that develops software or relies on it needs a software security initiative and metrics to measure its effectiveness.

Over the last decade, a number of software security methodologies have evolved, including Microsoft's Secure Development Lifecycle; the Comprehensive, Lightweight Application Security Process, part of the Open Web Application Security Project; the Web Application Security Consortium; and the Seven Touchpoints for Software Security. All are grounded in good software engineering and require attention to security throughout software's life cycle. Companies must understand common risks, design for security, and subject all software artifacts to thorough, objective risk analyses and testing.

What's Really Happening

That's what companies ought to be doing anyway. For a look at what they're actually doing, BSIMM--short for Building Security In Maturity Model and pronounced "bee-sim"--is an extensive research effort under way to analyze software security activities of companies such as Adobe, Bank of America, Capital One, EMC, Google, Intel, Microsoft, Symantec, VMware, and Wells Fargo. I'm one of the researchers.

BSIMM currently describes the work of 635 people in 30 companies who together have 130 years of experience working on software security. The success of these companies' programs hinges on having an internal group devoted to software security. The average size of these groups at BSIMM participants is 22 people, helped by about 40 others--developers, architects, and people directly engaged in and promoting software security. These companies have an average of 5,061 developers--so around 1% of the development team is directly promoting security.

BSIMM delineates 109 activities, such as getting upper management buy-in when it comes to compliance and privacy, and protecting the integrity of software by using code signing. These activities are organized in 12 categories such as compliance and policy, code review, and security testing. The 12 practices are divided into four groups--governance, intelligence, touchpoints, and deployment (see box, p. 44). For BSIMM's most recent study, researchers counted each time they observed one of the 109 activities.

The greatest value of BSIMM is in measuring and comparing software security initiatives among companies in different industries. To do this, we calculated the level of activity in each of 12 practices for a company, then we average those scores for companies in the same industry. We've done this for financial services companies and ISVs in the chart at left.

By creating spider charts like these from the BSIMM data, it's possible to compare and contrast how an industry approaches software security. Not surprisingly, the data shows that financial services companies emphasize compliance and policy activities and the creation of security features and design to a greater extent than ISVs. However, the most striking result is the huge amount of overlap between the two disparate industries. Financial services and software companies generally do the same thing when it comes to software security.

Even more interesting than pooling data from multiple companies is comparing the scores of an individual company with the BSIMM averages. This can give a clear indication of how a company's software security initiative stacks up against that of others.

BSIMM released its original study describing software security in nine companies in March 2009. In May, it released BSIMM2, covering 30 companies and providing statistically significant results. BSIMM plans to add more companies, and it's also been remeasuring current participants to mark the evolution in the maturity of their software security initiatives.

For Adobe, BSIMM provides a useful framework and data repository that lets its Secure Software Engineering Team measure its activities against other companies in the industry, says Brad Arkin, senior director of product security and privacy. He adds that it also helps the security team to answer questions such as "Are there things we don't do now but could or should be doing?" and "Are there things we should be doing differently because a shift in the threat landscape?"

Leveraging BSIMM

How can you leverage the BSIMM model? For starters, examine and organize your security initiatives along the lines of BSIMM's 109 activities. Think about which will work in your culture and which you're already doing. Download the BSIMM2 model (it's free and available at www.bsimm2.com). Compare your data with the BSIMM average and make your own spider charts.

If you want an objective measurement, you can join the project, be scored by the authors of the model, and have your data added to it. A BSIMM score will give you a baseline that you can use to compare your software security initiatives to other companies and show progress as your initiative matures. Bottom line, this data will let you create a software security strategy that's directly informed by what others are doing and what works.

10 Most Common BSIMM Activities

1. Put security basics in place

2. Build features like authentication and role management

3. Use external penetration testers to find problems

4. Create policies

5. Identify gate locations

6. Know regulatory issues

7. Identify privacy obligations

8. Provide awareness training

9. Create security standards

10. Perform feature review

ISVs Vs. Financial Services

BSIMM metrics show that ISVs emphasize testing and configuration and vulnerability management; financial services firms emphasize compliance and policy, security features and design, and training

[Note: This article contains charts that are too complex and therefore cannot be represented using text. To view this article, please refer to a printed copy of the magazine or to a PDF version, which is available at www.informationweek.com.]

Data: Building Security In Maturity Model aggregated data from seven ISVs and 12 financial services companies

4 BSIMM Groups

And the categories they include

1. Governance

Strategy and metrics, compliance and policy, training

2. Intelligence

Attack models, security features and design, standards and requirements

3. Touchpoints

Architecture analysis, code review, security testing

4. Deployment

Penetration testing, software environment, configuration and vulnerability management

Gary McGraw is CTO at Cigital, a software security and quality consulting company, and the author of the Software Security Library. You can write to us at iweekletters@techweb.com.

Source Citation
McGraw, Gary. "Real-World Software Security." InformationWeek 1275 (2010): 41. General OneFile. Web. 12 Aug. 2010.
Document URL
http://find.galegroup.com/gps/infomark.do?&contentSet=IAC-Documents&type=retrieve&tabID=T003&prodId=IPS&docId=A233958487&source=gale&srcprod=ITOF&userGroupName=18551_mcpls&version=1.0

Gale Document Number:A233958487