Software [In]security: You Really Need a Software Security Group
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
BSIMM Data Show an SSG is a Software Security Necessity
Deep in my Powerpoint pile I have a list of 58 major firms with software security initiatives underway that I have collected over the last few years. Just for the record, 31 of the companies on the list are financial services firms like Wells Fargo, nine are Independent Software Vendors like Microsoft, nine are technology firms like Google, five are retailers, and the remaining four firms are in defense and energy with one uncategorizable behemoth…(GE). So far, twenty-six of these firms are captured in the BSIMM study with four more firms under analysis.
There are almost as many ways that these companies have chosen to get started with software security as there are initiatives. Way back in January 2008 I wrote about four particular ways to get started that I had experienced first hand: buy a tool first, train your staff first, create a top down plan first, or start with a portfolio risk assessment. Two years of further experience consulting with ten software security initiatives in combination with careful study of twenty-six real world initiatives in the BSIMM reveals a key insight: having a software security group is necessary for a software security initiative.
Who Should Do Software Security?
Management 101 teaches that in order to get something done in an organization, someone or some group needs to be put in charge. No job does itself.
So why is it that some companies believe this basic fact doesn't apply to software security? In some backwards firms (surely not yours), if you go to the development organization and ask about software security they will immediately refer you to the network security people. "We have a department for that security stuff," they say while ushering you out the door. But when you make your way to the network security department and ask them about software security, they say something like, "Yeah, those developers really should produce code that doesn't suck. Those guys ruin our perfectly configured network with their broken applications."
See the problem? Dev points to security, and security points right back to dev, leaving nobody in the middle. Guess who ends up doing software security in organizations like that? You got it — nobody.
To make perfectly clear that this is a management issue, ask yourself who gets fired when your firm experiences a software security problem? Who gets rewarded when your firm does a good job with software security? If the answer is "nobody," then you have a real problem.
Job one is to fix the "nobody problem." Create an SSG to stand between dev and security for everyone to point to. Empower the SSG with real responsibility and authority for software security, and give them the resources they need to get the job done.
Here's what page five of the BSIMM document has to say about the SSG:
… Every single one of the nine successful programs we built BSIMM around has a sizeable SSG. Carrying out the activities in the BSIMM successfully without an SSG is very unlikely, so create an SSG before you start working to adopt BSIMM activities. The best SSG members are software security people; but software security people are often impossible to find. If you must create software security types from scratch, start with developers and teach them about security. Do not attempt to start with network security people and teach them about software, compilers, SDLCs, bug tracking and everything else in the software universe. No amount of traditional security knowledge can overcome software cluelessness.
A good SSG will include both people with deep coding experience and people with architectural chops. As you will see below, software security can't only be about finding specific bugs such as the OWASP Top 10. Code review is a very important best practice, and to perform code review you must actually understand code (not to mention the huge piles of security bugs we all know about). However, the best code reviewers sometimes make very poor software architects, and asking them to perform an Architectural Risk Analysis will only result in blank stares. Make sure you cover architectural capabilities in your SSG as well as you do code. Finally the SSG is often asked to mentor, train, and work directly with hundreds of developers. Communications skills, teaching capability, and good consulting horse sense are must–haves for at least a portion of the SSG staff.
Of course, if the SSG is bigger than one person (see below for guidance on SSG size), you'll need someone to lead it. Of primary interest to successful software security initiatives is identifying and empowering a senior executive to manage operations, garner resources, and provide political cover. Grassroots approaches to software security sparked and led by developers and their direct managers have a poor track record in the real world. Likewise, initiatives spearheaded by resources from an existing network security group often run into serious trouble when it comes time to interface with development groups. By identifying a senior executive and putting him or her in charge of software security directly, you address two basic management 101 concerns: accountability and empowerment. You also create a place in the organization where software security can take root and begin to thrive.
How Big Should Your SSG Be?
Don't tell anybody, but we used to guess what the answer to the SSG size question was. Now we know.
By studying 26 software security initiatives, we observed that in general an SSG is 1% of the size of the development organization. That is, for every 100 developers in a firm, we observe one full time member in the SSG. This is a number that has borne out over the course of the BSIMM study even as the study has tripled in size. (Note that we reported SSG numbers and this same basic ratio from the original nine BSIMM firms in an earlier article.) Over all twenty-six firms currently in the BSIMM, the average SSG size is 1.13% the size of development, with a range in headcount from 0 to 100 and a median of 13. The size of the development group in these firms ranges from 40 to 30,000 with a median of 3000.
Unfortunately, we only have one data point in the BSIMM for firms with less than 100 developers. (If you were wondering about the size 0 SSG above, well that was the firm.) Because of this dearth of data, there is not much we can say about smaller firms at this point. As soon as we analyze the BSIMM Begin data we will revisit the small company question.
In the meantime, the 1% number holds true for larger firms, though the particular structure of the SSG itself is always a matter of corporate culture, and no two SSGs are constructed exactly the same.
How Many Software Security People are There Out There?
If you sum up all of the SSG members in the twenty-six firms that we studied in the BSIMM, the total headcount is 562. That is an impressive number of hard core software security types. Not only is that number large, but those people not directly employed in the SSG but still playing a critical role in a firm's software security initiative (for which we term the satellite) sum to a further 992. If we combine the SSG and the satellite total, we end up with 1554 people working every day in software security as observed in 26 firms. Incidentally, the average satellite size is 2.8% the size of development, with a range of 0 to 300 and a median of 11. (As you can see from the numbers, the existence of a satellite is not as common or as important as the existence of an SSG.)
The average SSG size among our 26 firms was 22, so if we extrapolate to the 58 firms on my list we get 1276 SSG-level people. Factoring in the satellite, where the average size is 40, and extrapolating to 58, we get an additional 2320 people. Of course all 3596 of those people have full time jobs, but these numbers go to show that not only is software security a great career choice, it's also actually possible to both find and employ software security types.
Does your firm have an SSG? It should.