Jon Udell: Hi, this is Jon Udell and today's podcast is an interview with Gary McGraw, Chief Technology Officer with Cigital and author of a number of software security books. His newest book is called "Software Security, Building Security." In the preface, Gary relates it to two of his previous books. "Building Secure Software," the white hat book, seems to have touched off a revolution. Security people who once relied solely on firewalls, intrusion detection, and anti-virus mechanisms came to understand and embrace the necessity of better software. It provides a coherent and sensible philosophical foundation for the blossoming field of software security. "Exploiting Software," the black hat book, provides a much-needed balance, teaching how to break software and how malicious hackers write exploits. It's meant as a reality check for software security, ensuring that the good guys address real attacks and invent and peddle solutions that actually work. The two books are in some sense mirror images. Software security unifies the two sides of software security - attack and defense, exploiting and designing, breaking and building into a coherent whole. Like the Yin and the Yang, software security requires a careful balance." Well Gary, gosh it's been a long time since we've spoken, I think.
Gary McGraw: Yeah. It was maybe ten years ago.
Jon: Yeah, and actually before we get into the subject of your book, if you don't mind, I'd like to take you all the way back there.
Gary: That sounds good.
Jon: I have here in front of me [laughter] a copy of what I think still is one of my favorite books, which is called "Fluid Concept and Creative Analogies."
Gary: There you go, I wrote Chapter 10 of that.
Jon: Yeah, you did.
Gary: With Doug Hofstadter.
Jon: And I don't know if we ever have discussed that, but I found the whole book to be truly inspiring and it's really something that I still come back to from time to time.
Gary: Well it was really a blast working on that stuff with Doug and everybody else at FARG.
Jon: So for people who haven't read the book or don't know about that, I'll just kind of recap what I took away from that chapter. The whole book is about the way in which our mental ability to think by analogy is really the fundamental aspect of human intelligence.
Gary: And perception, too.
Jon: Yeah, and so in this chapter the challenge is, given a letter of the alphabet in a given style, how would you extend that style to a complete font. The question being, I guess, from an implementation point of view, what is mechanizable about the process of making analogies from one instance of a class to other members of the class?
Gary: And don't forget the first part of that is figuring out what class you're looking at, so if you have this crazy letter, you have to determine whether it's an A or a G or an E or what.
Jon: Yeah.
Gary: And then given that you can figure out what stylistic aspects it has and create the other letters by analogy.
Jon: So talk a little bit about the process there. What was the software that actually got built?
Gary: So I wrote this about 5,000 line program in Scheme to do this and used a graphics package called "Scheme X Motif" back when the Motif was big ten years ago. The idea was to have a very sub-symbolic computation model. The idea was little tiny codelets would run around in a global space and create and destroy structures.
Jon: There's kind of a blackboard thing going on, you'd say.
Gary: Yeah, it's pretty much a blackboard model.
Gary: But it's sort of driven by the tiny activities of all the little codelets and they get probabilistically picked to run, and the way I implemented it was they were actually thunks, if you know what that is. It's a little piece of code that if you just stick it the interpreter, it would run without any variables needing to be bound. Then structures begin to emerge from the soup that is the blackboard, and eventually it settles into a view of a letter.
Jon: And this architecture was pretty central to several of the projects in the book, not just that one, right?
Gary: That's right, yeah, the notion of sub-symbolic computation.
Jon: So this is something that Hofstadter and, I assume, a number of his students were exploring at the time.
Gary: Yeah, Doug thought it up when he was writing GEB actually, and I guess the first person to really push it pretty far was a woman named Marsha Meredith, who wrote a program called Seek-Whence that was trying to figure out rules of sequences of numbers.
Jon: Right.
Gary: And then Melanie Mitchell really pushed it a lot farther in a program called Copycat, and that was an excellent program. In fact, when I saw that run, Doug came to the University of Virginia where I was a philosophy student and gave a talk, and I thought, "Wow, that is so right! That's got to be the way this works!" So, I actually went to study with Doug after that.
Jon: So, given that that is, to this day, something that a lot of us would look at and say is fundamentally right...
Gary: Right, yeah.
Jon: ...what's happened in the ten years since that work was done?
Gary: Well, you known what really happened is kind of sad. Doug's wife died of brain cancer in 1993.
Jon: Yeah, I know that.
Gary: And Doug was really fundamentally wounded by that, but he's still doing some work in analogy and perception and creativity and concentrating a lot on translation and the language, and why you think the way you think in certain languages.
Jon: Right.
Gary: He's written some interesting stuff along these lines.
Jon: But there were a whole bunch of people, a number of whom you just mentioned.
Gary: Yeah, and they're still working on this kind of stuff.
Gary: So Melanie Mitchell went down to the Santa Fe Institute and ran the, I think it was called the Emergent Computation Group down there, and she segued into genetic algorithms research. But it's all very closely related if you think about connectionism, neural networks, genetic algorithms, the sub-symbolic computation model of Doug. They all share this notion that intelligence isn't about manipulating symbols but is instead this emergent property of all of these sub-symbolic sort of sub-cognitive activities going on in massive parallel, and it's great stuff. I think there's still people working on it, but I do believe that the heyday of cognitive science was the mid-'90s, and I was super-pleased to be right smack dab in the middle of it.
Jon: I recently listened to an interview that you gave about your book. I forget who it was exactly. In fact, I forget where I heard this podcast. Was it from IT Conversations?
Gary: There was one there, so maybe that one, yeah.
Jon: Which one was that?
Gary: Oh, that was with Sondra Schneider.
Jon: Yeah, that was the one.
Jon: So I listened to that and therefore I resolved to not have the exact same discussion with you, because I figure we can point people there for that one.
Gary: Absolutely.
Jon: So I thought about getting your views on what are the issues other than software with regard to security so that we can put the software aspects of the security problem in some context.
Gary: Yeah, so I guess the biggest problem is one that's sociological in nature, and so it goes like this. Most people, for no apparent reason, expect security, and they get really surprised when it turns out that their expectations were wrong. Even though nobody explicitly said, "Hey, you know this cell phone is secure," or even implied that, they sort of assume that when you talk on a cell phone or use your car or whatever [laughter] that these systems were designed with some security in them.
Jon: Do you think people think that?
Gary: I think they do. I think they get really kind of shocked and appalled when they find out they're not. You know, people had this sense of security before 9/11 with regard to terrorism and buildings and airplanes and this stuff. And it came as a very large and awful surprise to most people that, you know, these guys would fly an airplane full of jet fuel into a building. And the problem was that there was this implicit thought about security that was just wrong, and I think that today that's the biggest problem in computer security is that human beings by and large think they're more secure than maybe they really are.
Jon: Well, there's an aspect of being fundamentally unwilling or unable to contemplate the kinds of threats that can actually exist. One of the conundrums of being in security, as you know, is that you have to go to a very dark place.
Gary: Yep.
Jon: And you have to think a lot of dark thoughts....
Gary: Yep.
Jon: And that's psychologically uncomfortable. But I wanted to back up and say that my observation is that, first of all, in general people are terrible at evaluating risks.
Gary: They sure are [laughter].
Jon: But it gets especially weird when computers and networks are involved so, as you know, there are people who will say that they won't do internet commerce because they're concerned about the security of their credit card numbers....
Gary: Right.
Jon: And you walk them down this path of saying, "Well, you know, have you ordered pizza from the local delivery service?" "Yes." "Did you do it on your cordless phone?" "Yes." "Does your next-door neighbor have a baby monitor?" "Well gee, I guess they might."
Gary: [laughter].
Jon: "Did the waiter in the restaurant at any time leave your presence with a slip with your credit card number on it?" "Yes, he did." So there's that dimension to it. One thing is now beginning to get a lot of traction in the world of computer security is the idea of threat modeling.
Gary: Right.
Jon: And the notion of reduction of attack surface area, which as you know is a big Michael Howard mantra? Which I think is spot on, so if we go back to the credit card analogy, what I think most people should know but don't is that there's essentially military grade security over the wire in terms of the transmission of their credit card number. But what they also don't know is that the real vulnerability is the fact that that number is then stored in somebody's database.
Gary: Yeah the database somewhere, yep.
Jon: And from an attack surface area reduction point of view I have wondered for a long time why we haven't been able to get to the place where we limit or remove the need to store that number in the first place? Why don't we just use one-time numbers instead of....
Gary: The real answer is it doesn't matter because your number is a throwaway number and it doesn't really matter if your credit card number gets stolen because Visa and MasterCard have decided that the risk to them, there's real fraud. But if they keep it below nine basis points, which is nine tenths of a percent, they can account for that fraud as part of their business model, which they happily do.
Jon: Which they do and pass the cost along to all of us.
Gary: Yeah. So if your credit card gets stolen, you just get a new one and it costs you zero.
Jon: But that's not how people perceive that risk, right?
Gary: That's because people are confusing, I think, the credit card thing with all of the rest of identity theft. And they sort of think of your credit card as your ultimate identity number, which is very silly because, actually, your social security number is way worse. So I think it's sort of a confusion on the part of a lot of people. There's another thing that I think is worth mentioning when you talk about the physical world of the waiter carrying your card around and a piece of paper with your number on it. The fact of the matter is, on the net you can write automatic programs that look for information going by, since everything is usually sent in the clear unless you're using SSL, which a lot of web applications are using these days. But that automation is the scary part, the tricky part. That's what makes it a little easier to carry out crime on the internet than it might be to be a waiter and steal peoples' credit card numbers because one day you're going to get caught with those numbers walking around in the physical world. But if you just set up a little monkey program out there on somebody else's box that you knocked over, your chances of getting caught are a lot slimmer. In fact, that's something that we talked about explicitly in "Exploiting Software," which is a book I wrote with Greg Hoglund in 2004.
Gary: So my work, over the years, has tried to expand from, you know, first I started out with code security back when I met you in 1996 and then I thought, "Gee, why did the Java guys screw this up? If you wanted to do software right, from a security perspective, where would you go?" and that's why I wrote "Building Secure Software". Then these vendors started popping up trying to protect us against extremely ridiculous attacks. Like there was one vendor who had a black box testing suite, and I won't name them here, but one of the tests was "send 50 As to a variable and see if it causes a buffer overflow," which is just a laughable, silly, silly test. So that's why I wanted to write "Exploiting Software" and say, "Hey guys, it's not about sending 50 As over port 80. It's more like this. This is how trampolining works. Did you know they could even burn attacks into your EPROM and root your box into its hardware?" That's what "Exploiting Software" was about and it was a little scary. Okay, so now it's time to do software security. If you want to do things, what do you do? How do you do threat modeling? How do you do architecture risk analysis? If you're looking at the code, what do you look for? How do you do that?
Jon: Let me come back, just for a minute, to the attack surface area reduction thing.
Gary: Oh, Mike's thing, yeah. I don't really believe that, by the way.
Jon: You don't?
Gary: No, because I don't think that, often when people use that analogy, they don't understand that the surface area should also include things like the system clock, and the processor, and the processor clock speed, and the electric line, and all sorts of other things.
Jon: And your employees and physical security and on and on and on.
Gary: And your employees. They think about it as, "Well, our front door is port 80, so we're going to watch the hell out of that."
Jon: That's exactly my point as a matter of fact. So, number one, it seems to me that we have not yet really begun to inculcate in the minds of software developers the notion that storing data is a liability. Whereas now, it's really a reflex -- well, of course, I'm going to collect that, of course, I'm going to store that in the database. The ideas that transient databases that are opaque even to the operators of the database, or figuring out protocols that don't require the kind of collecting and storing of data for which you're then liable in ways that you don't want to be. I don't think we're really thinking much along those lines and we're also not thinking at all holistically.
Gary: I'm totally with you.
Jon: I agree with your point about the liability limit in terms of credit cards. Just recently here in New Hampshire, it was discovered that there were monitors that had been covertly installed on boxes in at least several of the state liquor stores and they had been there for a long time.
Gary: And they were doing the swipe stuff.
Jon: Yeah, you know, outside entirely of any issues of software security. I walk into places and I see machines logged in as the Windows NT administrator. Do you know what I mean? There's a whole host of social issues here.
Gary: I was at a thing at Morgan Stanley about the security industry and they had a bunch of security people that were talking about the future of our industry, of our little subsection of the industry, which was kind of fun. Dan Farmer was there, he's the guy who wrote Satan, and Dan, of course, went over to the little kiosk where they had information about what was happening at the conference that day, and immediately proceeded to screw around with that thing. And I just went, "Good Lord, here we go again."
Jon: I'll tell you a funny story about Dan Farmer. When I was at Byte, I set up our very first web server and I happened to use an NT box. Just for kicks, one day I took down all of the file share protections because it was a development box at that point and it wasn't doing anything. So it's a Windows NT box wide open to the C drive from a SMB perspective, a SMB NetBios perspective. Then I took Satan and I pointed it at the box and Satan said "Cool, I don't see any problems at all". And it was all about how we are in these particular cultures.
Gary: Well, Satan was set up for Unix, actually.
Jon: Exactly. Satan did not even contemplate the notion that a NetBios share would be sitting wide open on the Internet, right? So it's like, thumbs up, looks good to me.
Gary: That's too dumb for words. That's a really good point. I think one of the big problems in computer security, and something that I've become known for jumping up and down and screaming about, is that people have paid way too much attention to network security, and packet filtering, and firewalls, and antivirus stuff, and not near enough attention to the real problem, which is crappy software. So I've made it sort of my life's work, at least for the last ten years, to get people to think about software security. I think it's making a difference. I think we're finally making some progress in the field, which is great.
Jon: Well, it certainly is the case that the once sleepy realm of static software analysis has gotten extremely interesting.
Gary: Oh, yeah, absolutely.
Jon: I spoke to a bunch of folks in that area for an article that we did a couple of years ago and that stuff is really coming along.
Gary: It's really changed. You should do another article on it. We worked on technology for the Advanced Technology Program, ATP, of the Department of Commerce. I guess it started in '97 and '98, and we developed some static analysis technology that we then licensed to Kleiner Perkins. So I've been deeply in the middle of that. I think it's a great thing that we're using compiler technology properly to look for dumb bugs. I also don't think that that's going to solve the whole problem. I think it's going to solve half of it, if we're lucky.
Jon: Yeah, but it's a thing that always should have been applied much more aggressively.
Gary: Absolutely. When you compile code, you should put the wall on, right? Well, most guys don't because they don't want to see all these stupid error messages. You know, you might have a problem here.
Jon: Now I think there's another shoe still to drop in that area as we start to move into this world where increasingly some kind of garbage collected virtual machine is powering the software.
Gary: Well, definitely if it's type safe machine like the Java VM or.NET.
Jon: So I think that the introspection capabilities of those environments is going to get us to even more interesting places.
Gary: I think so too and we've been working on Java security issues for ten years, as you can imagine, and also .NET security, which is very similar. In fact, we did an analysis of the .NET security for Microsoft. It's going to happen. I'm afraid it's not going to happen as fast as we would like or as fast as would be helpful for the world. In fact, I was talking to Les Lamport, and he works for Microsoft now, and we were at USENIX Security this summer, and I said, "Hey Les, what's the deal with .NET? How come Microsoft didn't build the new operating system on top of .NET? What's going on? You guys built this great thing and then you ignored it." And he said, "You know, we made a huge fundamental mistake, which was the people who built .NET weren't thinking about building an operating system on top of it. So there are all sorts of things missing, like libraries that you would need, signal handlers, interrupt things, paging tables, all sorts of stuff that you need to build an operating system out of." He said, "This is the fourth time this has happened in my career, where we had a chance to adopt type safe languages and really move forward in languages and computation stuff, but we whiffed it again." And he said these usually come around every ten years so we've got to wait another ten years before we really move into the type safe languages.
Jon: For what it's worth, things in a variety of ways are schizophrenic at Microsoft, but I was at the PDC last fall and I was frankly blown away at the level of cross-divisional support for .NET. From session to session to session -- in the area of identity management, in the area of workflow -- all of these initiatives that are rolling out are exclusively being implemented as extensions to the .NET framework.
Gary: Which is great, but the problem is they forgot that the foundation itself needs to be implemented.
Jon: Wait, they didn't forget that. There are issues of legacy, compatibility, and performance, and other things, but that's a generational thing. I agree with you but I also think there's more consistent and widespread uptake of the .NET framework within Microsoft than is widely acknowledged, probably because a lot of that hasn't shipped yet.
Gary: I'm glad that that's your perception. My perception, speaking to the guys that built it, was that they were a little frustrated with the uptake as of a year ago or so. Maybe they've made some progress since then.
Jon: Well, again, a lot of the stuff that I saw is in the pipeline. It hasn't shipped yet. And certainly, looking at where Vista is apparently going to be, there's been substantial retrenchment from....
Gary: Yeah, and there are also some very silly things like apparently you can just declare yourself, you know, safe enough for rock-n-roll and then avoid having to run through the verifier. Just by, you know, flipping one flag. So, Microsoft always uses that challenge to try to do a good thing but also make it easy enough for people who don't want to, and I think they have a hard time negotiating that tradeoff.
Jon: So beyond the notion of type safety, does the phrase "capability-based security" mean anything tangible to you?
Gary: Absolutely. There's a whole literature that goes back into security work, you know all the way back to the '70s, and there are these capability models. There's a guy at John's Hopkins who actually has written a whole operating system called Eros that runs as a capability model.
Jon: I got introduced to it in the context of this, I guess you would call it experimental language called E.
Gary: Yeah.
Jon: But, you know, for people who haven't heard the term, why don't you give a brief rundown on what that's about and....
Gary: Well, I don't think I'll do it justice because it's certainly not my area, but I'll try to do it anyway. Yeah, so the notion is that there's certain things that actors should be able to do, and these things are capabilities. And if you think about the Java security model, some of the things that you can delegate or that you can give permission to do are capabilities. An example of a capability model might be you want to do video conferencing for a certain group of programs, so you make up a set of permissions required to do that. You know, must use camera, that connection must use this scripto engine, blah, blah, blah.
Jon: And then you negotiate for the rights to do those things.
Gary: That's right, yeah, and there's some other models that are very, very interesting based on this. There's something called Proof-Carrying Code, which really should be a capability model, too, but the Darpa people wanted to have a cooler name for it, and the notion is that it's very difficult to compute a proof, but it's real easy to check one. So what you should do is compute the proof at compile time. And then when you arrive somewhere, let's say it's mobile code, then the proof comes along with the code. Then you can do some verification to check that proof up against the code and determine, according to your capability model, what you are going to allow it to do or not.
Jon: Yeah, that sounds similar to the distributed credentials validation stuff that the CoreStreet people have been doing. I don't know if you're familiar with that.
Gary: I don't know that stuff.
Jon: Yeah, it's actually a similar notion. It is possible to pre-compute and distribute proofs which are relatively concise.
Gary: Yeah, so the guy who thought this up were Necula and Lee. If you Google them up, Peter Lee is the professor at Carnegie Mellon, and George Necula is a Professor at Berkeley, and they're both very good. The problem is, of course, that it's going to be about a million years before we're all ready to adopt that sort of technology.
Jon: Right.
Gary: [laughter]. That's the kind of stuff I work on with my research hat on and, in fact, one of the things that makes my books a little bit different than the standard issue books from Sam's or whatever. In the back of the new one, there's a huge bibliography with about 300 or so entries. Each entry has a tag and it has what I think is good about it. So it helps people that want to do science and learn to connect these ideas in the way that you're doing, to be able to do that better.
Jon: Yeah, I'm looking at that right now.
Gary: Oh, cool.
Jon: Well I'm probably an outlying data point, so I have to say you know I went through this book and thought, "Yep, yep." It's all good.
Gary: Yeah [laughter]. It's common sense, hoah!
Jon: Now it sounds no surprises.
Gary: [laughter].
Jon: But of course,...
Gary: Did you read Geer's foreward by the way?
Jon: Yeah.
Gary: Yeah, I love that. He's great.
Jon: Yeah, well since you mentioned him, that reminds me of something else. I mean in this area of this whole security problem and the things outside the realm of code that trip us up. He said one of the most, I think, profound things I've ever heard about access control. I'm sure you've heard this rant from him, which is that it doesn't scale. That so much of our security infrastructure is about ultimately presenting human beings with these vast matrixes of objects in formations, right, with people expected to navigate through and check off a bunch of things and mentally compute over time the necessary transformations through that matrix as resources come and go and people come and go That it's just, for a class of security problem, it's just never going to be practical.
Gary: I think he's right, so....
Jon: I think he's right.
Gary: So there's a sort of a draconian way to approach it, which is just disallow it and wait until somebody whines, and then let them do that [laughter].
Jon: Yeah, well his point was that for some class of access control, a post facto analysis...in other words, what does scale or will scale better over time because we have the storage and we have the processing power is our ability to scan logs.
Gary: Yeah, well I don't think that's right.
Jon: Oh, you don't think that's right?
Gary: No, well unless you think of logs as history. I think that the way people build up trust and I'm talking about people, not computers, is by interacting with other people over time. And you build up this trust in the way another person is going to behave towards you, and there's a good social construct that comes from that. If we did the same thing in computers where, you know, you just watch behavior and you keep an eye on it, then over time you can build up trust and tear down trust as necessary.
Jon: You're really talking about reputation here and....
Gary: Yeah, reputation and social constructs as applied to computer security, and in the future because there'll be so much information. There already is so much information. You're right, we can't have the big grid. That's very silly. And in fact the role-based access control models that I've seen have always evolved into, you know, well this is Jim [laughter]....
Jon: Right.
Gary: And that's Bob. And, well, that's not really a role, yeah, but Bob has to do special things, so instead of trying to take the omniscient view, if we take a peer-to-peer view of security, that might help.
Jon: How would you relate that to software security then? I mean, on one hand there's the reputation of a person that's relevant in this kind of....
Gary: There could be reputations of modules....
Jon: There absolutely are as a matter of fact. Arguably Microsoft's Internet Information Server has pretty significantly rehabilitated what was a terrible reputation, deservedly, a few years ago.
Gary: NASA guys, too. You stop bouncing stuff off Mars and your reputation improves.
Jon: [laughter].
Gary: So that's the way the world works, and there's no reason why we shouldn't think about those kind of sociological models as applied to computer security. That's not what I'm working on by the way, but it would be fun [laughter].
Jon: Right, right.
Gary: Right now I think that basically the number one issue is just one of sheer awareness. And if you tell guys that build software, "Hey, by the way you should think about security," after they get done looking at you with squinty eyes, saying, "What in the heck is that guy talking about?" they start thinking about it and they go, "Huh, oh yeah, hum..." and the they need to figure out what to do. And that's what I'm trying to accomplish with this book.
Jon: Why don't we kind of run through...because it's been a while since I've hung out in a university environment, and so I really don't have a sense of what's taught, but I keep hearing people....
Gary: I was just at Stanford last week [laughter].
Jon: I keep hearing people say, you know, that there's this huge disconnect about....
Gary: I think it depends entirely on the school....
Jon: Okay.
Gary: And that some schools are doing a better job than others. In fact, if you'll look up "academic" for security in the index, you'll find that there's a chart of some universities that I think are doing a great job. So I want to give them kudos for doing that.
Jon: Okay, and so who would you call out?
Gary: Oh, I would call out...well I was just at Stanford so I'd call them out.
Jon: Okay.
Gary: The University of Virginia is doing a good job, John Hopkins, University of Maryland's doing a great job. Princeton. You're going to see some good stuff at Columbia because a very good guy went there recent. Penn State is coming along. Purdue is, of course, still doing great stuff because the staff is there. North Carolina State has some very good people.
Jon: So define good. I mean what are the kinds of things that they're doing concretely?
Gary: Well, what they're doing is trying to teach builders how to think about security during the engineering phase, and so that's what I define as good. So, if you approach security as an engineering problem a la say Ross Anderson's excellent book, Security Engineering, which isn't a software book, it's just a systems book. Then it's a lot better than approaching it as the fire department or, even worse, cops and robbers. So, if you want to see what a major corporation is doing in terms of security, find out what background their chief security executive has. And if that person is a cop from the "cops and robbers" days, then they probably won't have the right understanding of security as a constructive exercise. Those universities that are doing the right thing, in my opinion, are teaching people who build stuff that they need to think about badness while they're building stuff.
Jon: And they're also going to be getting hands-on practical experience with the use of static analysis tools. They're going to be....
Gary: Sure.
Jon: Getting a concrete introduction into threat modeling and maybe some tools....
Gary: Sure, I would call it risk analysis. I think the term threat modeling is a term from the U.K. The term "threat" really in the U.S. word literature going back 150 years means an act or an agent who is going to carry out an attack, not a risk. And so really risk analysis and threat modeling, if you use them interchangeably, that's fine with me. I just found out where that came from because it comes from the UK. If you look at their word literature, the UK and, of course, Australia.
Jon: Which is obviously where Michael Howard comes from.
Gary: Then you find that those guys just use that term differently.
Jon: Right.
Gary: I only found that out the other day.
Jon: But risk has it's own interesting connotations and....
Gary: Yep.
Jon: ...makes me think about the Bruce Schneier argument about how, in general, businesses mitigate risks with insurance.
Gary: [laughter].
Jon: Yeah.
Jon: And actually what do you think about that?
Gary: I think that's a great idea.
Jon: Yeah.
Gary: And we've actually talked to some insurance companies about the problem that they're facing now because, you know, like these guys, DNV, Det Norske Veritas, as the biggest insurer of ships on the planet earth, they have great data going back for 200 or 300 years about every ship crossing the Atlantic ever, and what caused what. They have great actuarial tables. They even understand things like tensile strength of metal, and hull architecture and all this other great stuff, and then somebody came along, and stuck a little computer in the ship, and it started doing stupid things like driving itself into an iceberg. And so they said, "Geez, how do you control that little thing? We're all good except for that part." And I think that's a problem they're still trying to solve. But I think that's a problem that's going to become increasingly common all over the place now that we're relying on software as the lifeblood of everything, to get stuff done on this planet, we need to just build software that doesn't fail in really dumb ways.
Jon: Well we talked about earlier, measuring the reputation of software, and in fact, in a way, that's exactly what Bruce was suggesting in his proposal, is that that's what the insurance industry does...
Gary: Yeah. He tried that doing that with the Lloyd's guys, he didn't get very far.
Jon: So you think that's, I don't know, an idea that's ahead of the curve?
Gary: I think it's ahead of the curve, and that their first attempt was incorrect. That was, they were trying to insure people against hackers, which is a silly damned thing. Whereas, they should have been talking about how well people had constructed their stuff, not how well they'd protected against bad guys on the outside; deal with the old perimeter security notion.
Jon: Now how would they measure the goodness of construction?
Gary: That's a great question. Who knows? [laughs]
Jon: I guess how they would measure it absent any other metric would be the incidences of vulnerability and failure.
Gary: Yeah, Actually, there's a real answer to that, a less glib, silly one like the one I just had. And that is, if you build what's called an assurance case while you're building a system, you can keep track of evidence about why you're doing a good job. And that evidence can be then used to think about insurance, and other sort of risk transfer models.
Jon: So define assurance case.
Gary: An assurance case defined in the classic sense, if you look at say, the orange book, or the common criteria model today, is just a set of evidence that certain testing has been carried out, that certain things have been done, say in the software development process. So for example, the Touchpoints I've got in the book, you could prove, or you could show, what the results were of say, a static analysis. And that's just some evidence. Doesn't mean you're home free, but it means you probably did a better job than half of the other guys out there.
Jon: What other kinds of things could you show evidence of?
Gary: You could show evidence of good risk analysis, you could show evidence of abuse cases, that you built early in the life cycle. Thinking not just about use cases but abuse cases, you could show evidence that security was factored into the requirements phase, you could show evidence that penetration testing had been carried out to probe the ultimate environment where the software lives. So, building up that case evidence is what the Touchpoints really are about.
Jon: So, the tangible outcome of this, in many cases, is going to be documentation.
McGraw: Yeah. Documentation based on actually having done something. I really am not much of a bureaucrat. I would call myself an anti-process guy but, nevertheless, when you do things like static analysis on source codes looking for security bugs, once you've done that, you can say, "Hey, I did this. Here's what I did."
Jon: Right. So since we're obviously both on the anti-bureaucratic side of things, the conclusion there is that you want this stuff to be well integrated into the tools that you're going using anyway, so it'll just be a natural outcome of what you're doing.
Gary: Yeah, absolutely.
Jon: And where do you think we are in terms of that?
Gary: Oh, boy, we're just at the very beginning. I don't think that any compilers are building it in now, and I know that in Visual Studio, whenever the next one is, they're supposed to put a minor version of a watered down version of PREfast in there, which is basically like that thing we released in 1999. It's S4, which stands for "software stupid security scanner."
Jon: I guess they've got another....
Gary: FXCop.
Jon: No, there's another....
Gary: Oh, Prefix.
Jon: Yeah, that's the one they use internally, right?
Gary: Well, Prefix they're not going to be releasing. Yeah, that's a heavy duty static analysis tool, written by John Pincus, who's an absolutely fantastic guy, who's now Microsoft research, and he had a company called Intrinsa, which got bought by Microsoft, and they took his technology and used it themselves.
Jon: So that thing is, it's my understanding, very deeply integrated into their build process.
Gary: Yep, and helps with bugs. In fact, Microsoft was so riddled with bugs that their static analysis push has really helped a ton. And you know, Mike and the guys that do the Trustworthy Computing Initiative, spend a lot of time worrying about bugs, and probably not quite enough time, worrying about architectural level problems. So that's what's coming next.
Jon: So if somebody reads this book, and says, yeah, I've got the religion, I want to make this happen in my company, and they are either a .NET shop or a Java shop, what would you point them to in terms of stuff that you could actually add in those environments in a clean way?
Gary: Yeah, so, tooling up obviously, with static analysis tools is the first thing you need to get. But in fact, before that, I think the number one thing you can do, which is what Microsoft did, is some awareness training for your development staff. You don't want to just throw tools at them because they're not going to know what to do with then. Kind of like, okay, here's a screwdriver. Here's a screwdriver on your desk. And they won't know how that helps them build better software.
Jon: So what's a good way to get people's attention? My sense is that if they haven't already seen this, the kind of lecture that the extreme hacking guys give, is a definite attention getter.
[laughter]
Gary: Sort of the wrong kind of attention.
Jon: Oh yeah? Too scary?
Gary: Too much flash in the pan and bullshit. And I think that most people who build software, if you're a real software guy and you stand up in front of them and you tell them about security in terms of software, they get it immediately. You know, I've personally trained probably four, five thousand people, and our biggest customers were still in the process of training thousands and thousands of developers. So we've done this kind of adoption of Touchpoints and awareness training stuff at Qualcomm, and the Coca-Cola company, and some other places that won't let us mention their names.
Jon: And what's your sense of the kinds of reactions you get, as to what's resonating with folks and why it is that the message is being received but hadn't been heard before.
McGraw: Well, there are two things that it takes. One of the reasons is that CEOs of these companies have gone out and said, hey we've got to do this. When a CEO says that, it starts to happen. Because, you know, this isn't like an academic exercise, or science land, it's just what your boss's boss's boss's boss says is going to have to happen. And if you get a good grassroots movement toward software security hooked up with something like the Gates memo from Microsoft, which I have in the book with their permission, you see a result. It begins to happen. Now, it's not something that you're going to snap your fingers, software security's going to start occurring overnight, but with a good concerted effort, you can make a huge difference.
Jon: The grassroots point that you raise is an interesting one. In the area of testing, my observation is that it's been very much a grassroots kind of thing. People are, on their own, individually, or in small teams, kind of stepping up to the plate with unit testing and writing their own tests and things like that.
Gary: I think you're right. But I don't think software security is in quite such dire straits, because security is easier to grasp at the boardroom level than testing. [laughter] And you know, at Cigital, we do tons and tons of testing work. So I'm allowed to say that, and the fact of matter is, security's just sexy, and security appeals to executives in a way that software testing just doesn't. But I will say this. I've seen software security initiatives fail for two reasons. At one end of the spectrum, the executive suite says, "We're going to do security," and everybody sort of looks up from their keyboard for five seconds, and said, "There go the pointy haired dopes again," and they just went go back to what they were doing. Or in another place, which a huge Silicon Valley company, I saw this very strong, well thought out grassroots effort just totally hit the wall because they got no executive suite support at all, and no budget. So when it came time for them to want to train people, it was sort of, "You get training if you want it, but there's no reward or punishment in your job for getting it." In a capitalist society, that doesn't work. So you have to have a combination of both to really make it work, and that's what we help our customers to do. What I wanted to do was to make it really, really simple. So the reason that there are seven Touchpoints is a purely psychological reason.
Jon: That's what people can remember.
Gary: That's what people can remember. And I mean it's very silly, but it actually is effective.
Jon: That's not silly at all.
Gary: Yeah, so that's why there are seven of those. And it's also important to understand that people who build software have religion about their own process. They don't want to change their process. It's like asking them to change their religion, or lack of religion as the case may be, and nobody wants to do that. "So first change your religion and then add these 400 steps." No. But instead I wanted to say, something simpler. "Keep your religion however you want. You already produce software. And as a side effect to producing that software, you probably produce some artifacts, like code, and architecture documents, and here's what you should do given those artifacts."
Jon: Sounds reasonable to me.
Gary: It's pretty reasonable. I think you know, like you said, a lot of people will read and go, "Yeah, this is common sense." And if that's their reaction, great! [laughter] I hope they use it. It's supposed to be common sense. It's unfortunately not common enough.
Jon: Okay. I think I have no further questions. Was there anything else you wanted to impart?
Gary: Not really. It's been really entertaining, actually.
Jon: We probably shouldn't wait ten years to have our next conversation. [laughter].