Fault Injection is a podcast from Synopsys that digs deep into software quality and security issues. This week, hosts Robert Vamosi, CISSP and security strategist at Synopsys, and Chris Clark, principal security engineer at Synopsys, interview Sammy Migues, principal scientist here at Synopsys, about the new Building Security In Maturity Model (BSIMM) 8 report.
You can always join the discussion by sending us an email at firstname.lastname@example.org.
Robert Vamosi: Welcome to Fault Injection. I’m Robert Vamosi, CISSP and security strategist here at Synopsys.
Chris Clark: Hello again. This is Chris Clark, principal security engineer at Synopsys. We have a very special guest today.
Sammy Migues: Hi, my name is Sammy Migues. I’m a principal scientist here at Synopsys, and I work mostly in management consulting for building security programs.
Robert: Thank you, Sammy. We’re here to talk about BSIMM, and in particular, Synopsys will be releasing the BSIMM8 report. And we wanted to talk to you a little bit about how that came to be. This is BSIMM8, but that doesn’t necessarily mean that you’ve only been doing this for 8 years, does it?
Sammy: So no, it doesn’t match up one for one. We actually started in 2008 with our data gathering. Remember this is a science project. We didn’t set out to make a standard or anything. We wanted to go out and explore the world. That ended up creating BSIMM1, early in 2009. And now we’re on BSIMM8.
Robert: When you say it was a science project, could you tell me a little bit more about how you and your partners—I believe it was Gary McGraw and…who was the third party?
Sammy: At the time it was Brian Chess.
Robert: There we go.
Sammy: So yeah, this is a very interesting thing. There were others—including us, Gary McGraw in particular—who had said, you know, if you don’t have your own way to do software security in your organization, here’s our way. In other words, they had made some prescriptive standards. You know, you don’t know what to do? You’re just getting started? Just do this. Well, we didn’t want to make another one of those. Because it had been tried. It wasn’t working. Again, think back to 2007, 2008; it wasn’t really working. So what we said was, what if we do science and go out and talk to people and figure out what they are doing? Because the folks who are really advanced in software security, they’re doing good. They’re not the people we’re reading about in the newspaper every day. Maybe they are onto something. So we went out, and we talked to nine large organizations who had been doing software security for a while. We spent hours and hours with them. We asked them everything they do to make software security actually happen in their organization. And then we went back, and we just went through all that data. We threw out all the duplicates. We threw out all the wishful thinking. We threw out everything that was really so narrowly focused as to be particular to one organization. And we ended up with 110 activities. We put those activities into a framework, we used that to create a model, and that became BSIMM1.
Chris: Very cool. So you just talked about BSIMM1, and we’re moving up to BSIMM8. Have the criteria really changed that much? Or is it more of maturity in some of the categories that were already well-defined as part of BSIMM 1?
Sammy: We haven’t had any need to change our framework. Think of the framework of 12 practices as sort of an archeological grid. You know, we put some strings down on the ground, and then we went and we found some information, and we went, well, that goes into this square and that goes in this square. And those practices have remained stable since 2008. What we have done, however, is as we analyze the data that we find, we’ve created some more activities. So we started with 110, we ended up deleting 1, we’ve added 4, so now we’re on 113. And the reason why that part of BSIMM is so stable is the level of detail at which we defined the activities allowed them to stand the test of time. So we say things like “Have a software policy.” We don’t say “Write a 12-page Word document.” We would have had to change that 10 times, because people put it in wikis, all sorts of things. So “Have a software security policy” is not only stable—it doesn’t get old too quickly; it’s also universally applicable. So it doesn’t matter if you have three developers, a dog, and a squirrel launching the next big product or if you’re a Fortune 500 company. “Have a software security policy” applies. There are no special snowflakes. The BSIMM works for everybody.
Robert: You mentioned that you have a wide range of people participating. I know there are different levels of activities. So the activities are different at each level. Level 3 is highest, and very few companies have attained Level 3. So could you explain a little bit about the rationale behind that and how you’re approaching that?
Sammy: Yeah. Let me restate that just a little bit. We have, within each of the 12 practices, a variety of activities. We have different…each activity is a unique activity. So this is not like, let’s say, the software CMM, where at Level 1 you might say “Do something” and at Level 2 you do the same thing harder and at Level 3 you do it harderer and fasterer. That’s not how BSIMM works. At Level 1 there’s an activity that is at Level 1 because it’s relatively common, and we use frequency as a proxy for usefulness and ease of implementation. Because if we see it often in big companies, little companies, embedded companies, web app companies, then it’s probably pretty useful, and it’s probably pretty easy to do. So we’re going to put that at Level 1. So just think frequency analysis. Things we see very infrequently are probably more specific to certain verticals, or it’s really rocket science, so you’re not going to see it very often. We don’t see it very often, so through frequency analysis, that flows down to Level 3. Level 2 is everything left in the middle. And we really do see a curve of these things we see a lot, these things we see less of, and these things are really rocket science. So that’s the levels in BSIMM. We call it a maturity model because you have to mature—OK, this is the way we did it in 2008—because you really have to mature your organization to get a solid software security program. It’s not just a matter of buying tools or making someone responsible for it. You really have to change the way you do things. So we called it a maturity model. But it doesn’t work the other way, where you do it harderer and fasterer to get to a higher level.
Chris: You bring up something that maybe for some people might be a little unclear. When we’re talking about the BSIMM, as you said, we’re talking about the maturity of a software development program; we’re not talking about the maturity of an organization from a security program. Can you expand on what the difference is? Because I don’t that that’s completely clear to some members of the audience.
Sammy: I’m sorry. So the difference between maturity of program versus maturity of an organization?
Chris: Exactly. From a software security standpoint.
Sammy: OK, so let me start a little earlier than your question. You know, we used to do accounting with paper ledgers and pencils and guys with green visors and stuff like that. And to really get better at that, first we introduced some technology, we introduced some automation, we standardized some processes, we taught more people how to do it, we pulled it into computers, and then those folks kind of went away. But for a while, the organization itself wasn’t mature; the practice, accountancy as a thing, was maturing, if you get what I’m saying. And so then the organization pulled that in and said, “Aha, we are better at accounting.” So what we have today is, you know, development practices, software engineering practices, testing practices; all these things are advancing way faster than the average organization can move. So you’re behind in a management practice, and you want to get better. You want to collect all the cats. And you want to make a software security initiative instead of a bunch of individual things. You’re a manager; you want to get your arms around things. So what do you do? You start a software security initiative. You take a group of people, and you make it their responsibility to make software security happen in a predictable, cost-effective, compliant way. So that’s where we are right now. This is Deming 101. It’s a management problem, and we’re solving it with management solutions. In the time it takes to bring all of that into the company and make it business as usual, which could be a couple of years, we still need to write software and do security, because that’s how we pay the bills. So we’re going to do things in the software security group and in engineering using things like BSIMM so that we can improve, and we’re going to mature our software security and mature our SSIs and do all of that stuff as part of our whole risk management picture. But for it to become business as usual and for the whole company to be mature at this could take years. And so it’s that same kind of analogy.
Robert: You talk about the SSG. I know you also talk about, and you’ve observed, people that you’ve included that are called satellites. Could you explain their role and how they play?
Sammy: Sure. So let’s just walk down the stack, sort of. We have the software security initiative itself; that’s the business effort to get my arms around software security and make it happen in a way that’s right for me. Then we have the software security leader, the software security group leader. That’s the person who owns the execution of this. They have a team; they are the software security group. But we can’t take 40 people, 50 people, and put them up in overhead in corporate and say, “You own software security.” Plus they won’t have the reach into the business units and the development teams. So one of the BSIMM activities—or actually several of them—say you should have hands and feet in the business units and in the development teams. You need scale; you need the ability to reach out and touch people; you need the ability to do evangelism. The group we refer to that you should instantiate to get that done is the satellite. For example, you would take a person, you would train them on some basics of software security and your secure SDLC gates, and that person would be the representative to, let’s say, the embedded software developers who are making the head-end console for a car, and then you’d have another satellite assigned to the web team and another satellite over here. And all these people are dotted lines back to the SSG. So you now have a global group that’s worrying about software security without having to build a giant organization in corporate.
Chris: Along with that goes a direct need to share information among them, but BSIMM8 doesn’t focus on what information to share though, correct? It’s more of ensuring that there is a communications path between the satellite and the SSG team itself?
Sammy: There are 113 activities in BSIMM8. There are activities that address evangelism; there are activities that address publishing data so everyone can understand what the software security program is doing and how it’s progressing; there are activities related to standards and policies, having a portal so everyone can understand the software security program. So there’s a whole bunch of things, the collective effect of which is your software security initiative. We wouldn’t have an activity that says “Do the right thing” or “Accomplish software security,” so we wouldn’t have one that says “Communicate.” It would have a more specific objective. Like for example, we have an activity that says “Educate executives and the board on software security.” So that’s a little more specific than what you just asked, but yes, those are addressed in a variety of activities.
Robert: Thank you, Sammy. Appreciate your insight, and we look forward to reading the report, BSIMM8, which is out now from Synopsys.
Sammy: Cool, thank you very much for having me.
Chris: Thanks for joining us.
Explore the latest findings in more depth.