Products + All Products + Software Integrity + Semiconductor IP + Verification + Design + Silicon Engineering
Posted by Synopsys Editorial Team on December 1, 2015
Who should ‘do’ software security?
Sadly, solving software security is not as easy as picking only one population to hang the security problem on. In fact, software security does (eventually) take “all of the above,” but ultimately must be coordinated by a central software security group (SSG).
The seven software security myths are common misconceptions about software security best practices. These myths explore how software security initiatives should work, and aren’t simply about how to secure a particular application. Start your journey toward security truth with the first myth of software security.
We know from the Building Security In Maturity Model (BSIMM) that a software security initiative (SSI) should be led by a SSG. In fact, a SSG is a necessity to execute software security, application security, product security, or whatever you’d like to call it. The point is, creating a SSG is the first step when your firm is ready to tackle software security.
The notion that developers—and only developers—should collectively and magically be responsible for software security sounds great in theory, but it never actually works in practice. So if a SSG is not just a bunch of developers, what does it look like?
Here are a few key things to consider when forming your SSG:
We asked real firms how they went about organizing their SSG. At the fall 2014 BSIMM Community Conference in Monterey, California, we posed these questions to the BSIMM Community. During a break-out session, complete with plenty of cocktails to get the conversation going, 23 firms presented and discussed their SSG structure. Once we heard from all presenting BSIMM firms, five major groups emerged:
Seven of the presenting firms built a SSG to provide software security services. This is the most common organizational approach in our data set. These SSGs are structured in terms of specific services they provide to the rest of the organization (i.e. penetration testing, code review, architectural risk analysis). Among the seven firms in this category, the most commonly provided service was code review with static analysis.
Five firms built a SSG around setting policy. This approach sets policy that is to be enforced by technologists outside of the SSG. For example, the SSG may declare that code review is mandatory and must be completed with no high-risk vulnerabilities resulting, but does little to steer development groups directly in how to get this done. In many cases, the SSG doesn’t hold much power beyond what they can influence, and they take a “set a goal and hope” approach.
Two firms built a SSG mirroring business unit organizations. This approach is a more difficult way to get things up and running. The idea is to provide the same kind of help to each of the business units in an organization, tailored to their way of working.
Four groups built a SSG with a hybrid policy and services approach. In some cases, the SSG finds itself conflicted in a sense that it sets policy that is mandatory, but doesn’t have the service bandwidth to execute the work for all the teams that want it. This leads to questions like: “who pays for what?” and “who gets the blame when delays occur because of lack of software security service bandwidth?”
Three firms with very mature initiatives had SSGs structured around managing a distributed network of others doing software security work.
And just for the record, the two remaining firms (among our 23 total presenting firms) were organized in unique ways found only in their firms. In some sense, replicating this approach is not really possible.
Now that you know the first step is to form a SSG, the next step to take into consideration is to make sure the SSG includes both software people with deep development know-how, security people with strong architectural knowledge and people who can interact with the business.
It should be obvious from what we’ve said here that the idea of simply training all of the developers is another one of those “yes, do that, but not only that” software security best practices. Should you train your developers and arm them with software security know-how? Yes! But you also need to check code for bugs, check design for flaws and check systems for security holes. Why? Well, aside from the obvious reasons, your developers don’t write all the code you deploy. Even if your code is perfect, all that vendor code and other stuff created in groups without a SSI will trip you up every time.