BankInfoSecurity.com Interviews Gary McGraw
LINDA MCGLASSON: Hi. This is Linda McGlasson with BankInfoSecurity.com, and today we’re speaking with Gary McGraw, Ph.D., Chief Technical Officer at Cigital. Dr. McGraw is a world authority on software security and is author of six best-selling books, including Software Security: Building Security In. We’ll get right to the questions. Being that you’ve been involved in InfoSecurity for I want to say more than 15 years –
GARY MCGRAW: I’d say 11.
LINDA MCGLASSON: Eleven, okay. I don’t want to make you too old.
GARY MCGRAW: It seems like 1100, but I think 11 is about right.
LINDA MCGLASSON: What are your thoughts on the state of information security in general?
GARY MCGRAW: I’m kind of optimistic about some of the progress we’ve made in the last five years, and mostly that has to do with turning away from the old reactive approach to security that involved trying to put barriers between bad guys and stuff, like firewalls or anti-virus mechanisms or intrusion detection systems, and instead beginning to pay attention to building security into our systems in the first place so that they’re not riddled full of security vulnerabilities. And I think we’ve made a lot of progress in that area, so I’m optimistic that we’re beginning to approach the problem in the right way.
LINDA MCGLASSON: On that same question, are you also optimistic on the state of InfoSecurity in the banking industry?
GARY MCGRAW: Well, sure. I guess you wouldn’t be surprised to know or your listeners wouldn’t be surprised to know that many times it’s the financial verticals, and the banking industry in particular, that is leading the adoption and application of various security technologies. And the reason for that is that, obviously, banks have something really tangible to lose: money. And they also have something even more important that they can lose, which is reputation among their customers.
And so for those reasons, you find people in the banking industry have a pretty kind of intuitive grasp of risk management and the notion of trying to figure out how to balance things out right when they’re thinking about security versus actually being a bank. And so when it comes time to talk about building software properly, the kind of thing that I like to do, banks are really open to that. And, in fact, they’ve been knocking down our door trying to get us to help them set up software security programs and integrate best practices into their software development life cycle.
I think the one thing that might surprise some of your listeners is that many banks are really very huge software shops. And if you go to, say, large investment banks in New York, you find that they have, you know, 8,000 developers in some of these banks. You know, my gosh, you know, I thought you were a bank; but it turns out you’re a software company. So software security is taking on a lot of prominence because of that.
LINDA MCGLASSON: Well, that’s with the bigger banks; but some of the smaller and mid-sized banks, they tend to use off-the-shelf software. What’s your take on their use of third-party vendors and off-the-shelf software and their dependence on them without, going into a lot of detail?
GARY MCGRAW: Yes. I know a fair amount about some of the safety software because of my involvement in a few cases as an expert witness. So I have to skirt carefully when I’m talking about this issue.
But for the most part, the vendors of banking software that’s off-the-shelf for smaller and mid-sized banks do also understand the importance of security. And they’re trying hard to do a decent job with software security. The main thing is that when somebody in a bank like that decides to buy that off-the-shelf software, they really should seek third-party validation or an assessment of what the real security posture of that software is from experts; they shouldn’t just take the vendor’s word for it. And so you can hire a consulting firm to do something like that. We do it at Cigital, but there are many other firms that will help with that as well so that you can get a real handle on the risks that come with using that off-the-shelf software.
That said, I think that there’s been improvement in that body of software, too, in the last two or three years, mostly under pressure from the law and from some of these lawsuits that I was alluding to at the beginning of this answer.
LINDA MCGLASSON: Going on to a different area – pervasive computing – can you explain it to our listeners in lay terms?
GARY MCGRAW: Sure. This is kind of a research subject, but the notion is that computers get into everything, like your clothes and your light switch and your car; and, you know, it’s not just your computer that you’re using to do compensation. And, in fact, there are lots more computers around you today than you might be aware of, and they’re sort of behind the scenes doing things like running the electrical power grid and doing things like, having your cell phone turned into the little computer or running the fuel injector in your car; modern cars have maybe 12 to 1500 computers in them now doing the automotive controls.
The notion of having computers everywhere is great because computers and software lend us lots of flexibility to build cool new products and change them on the fly and have them do really kind of mind-bogglingly great stuff. But along with that great comes a fair amount of risk, especially if you think about what I call the trinity of trouble that is connectivity: Everything is connected to the network; extensibility, and that’s a big one that I think is important to understand in terms of its ubiquitous computing; and then the third one is complexity. You know, those are the three things that make software security a real challenge and a fun thing to work on. And extensibility is probably the one that is most relevant to ubiquitous computing or pervasive computing. And I think what we’ll find is that, as these computers get around everywhere, we’re going to have to start thinking about new things like the fact that computers know where we are. Your cell phone could actually be a tracking device. And you can use that for business reasons or you could use that for attack reasons, as the bad guy. So we need to think through the implications of what it means when computers are everywhere. That will be interesting over the next ten years, watching how that unfolds.
LINDA MCGLASSON: What will be the impact, in your view, on security and user privacy of the trusted computing initiative?
GARY MCGRAW: Oh, wow. So the idea of trusted computing is really pretty simple if you think about it. You know the computer is running lots of software, so you can say how can you trust the software? Well, you sort of have to trust the hardware. And then you say, well, why should you trust the software? Why should the hardware – the software trust the hardware? And there really is no answer right now.
And so if you try to look for where does trust come from, it turns out that it kind of goes with this joke that it’s turtles all the way down. You know, there is no bottom-most trust thing. The idea behind trust in computing or trustworthy computing is to get a hardware co-processor in everybody’s PC so that you can boot trust. That would be very, very helpful for a lot of things. You know, we’d be able to validate that the software that says it’s some sort of software actually is using cryptographic methods, for example. We could do things like, you know, build real digital right to management envelopes.
But what you trade off there is that that coprocessor no longer really belongs to you, the owner of the computer. It really belongs to Intel or Microsoft or, you know, some manufacturer who has actually put that coprocessor in your system. And the idea is then that that thing watches you and watches what you do and allows things and doesn’t allow other things. And a lot of people are worried about that from a privacy perspective and from a computing freedom perspective. And, in fact, you know, the cyber punks are completely opposed to this for just that reason, and it points out this really delicate critical trade-off that has always been involved in security: How do I trade off privacy and security? I want to make sure that that website knows who I am, you know, authenticates me properly; but I also want to be anonymous. Well, those two things don’t balance out real well. Which one do you really want? And so questions like that remain to be answered as we look at these modern disciplines.
LINDA MCGLASSON: Okay. Going back to your book, Software Security: Building it In, Dan Geer wrote in his foreword that there is a new Windows virus every four hours, and about 15% of all desktops are running some sort of malware, and embedded systems outnumber desktops by one to orders of magnitude; shows the reasons for better security. So just how wide is the gap between those who have security and those who don’t?
GARY MCGRAW: Well, I think that software security is a fairly new field. And as I said before, I’m optimistic about the progress that we’ve made; but certainly there is lots and lots of room to grow. Microsoft has been spending lots and lots of effort trying to adopt software security best practices. They even have their own software security guru, Mike Howard, who’s quite a good guy, trying to lead the program over there. And so like many banks, Microsoft itself is trying to figure out how to do a better job so that they don’t have these viruses promulgating the earth all the time.
I think it’s interesting that you mention Dan’s foreword to my book because my favorite sentence in the book is actually a sentence that Dan wrote. So I’ll read that to you. On one of the early pages it says, “As Dr. McGraw reminds us, breaking something is easier than designing something that cannot be broken, so I personally prefer Sam Rayburn’s earthy formulation, which is ‘any jackass can kick down a barn, but it takes a good carpenter to build one.’â€
And so I think that sort of says it all from the perspective of, you know, it’s easy for people to break it. If you hire some hacker boys to do a PEN test, they’ll probably be successful. But really what we need to do is build better barns, you know, not run around knocking barns down just to say that we can. And so I think we have to pay more attention to things like software security and things like building security in or we’re just going to be stuck with a computer security problem that gets bigger and bigger and more and more unsettled.
LINDA MCGLASSON: In your previous answer, you mentioned Microsoft. What’s your opinion of the new operating system, Vista?
GARY MCGRAW: Vista. Well, I’d have to ask my son, Jack, actually. He’s very excited about all new operating systems, including Vista. I think that Microsoft is trying hard to build a next-generation operating system that is not a security disaster. And, in fact, given their track record, you know they did a pretty good job getting things better with XP Service Pack II than when XP first came out.
So what usually happens to Microsoft is they’ll release a gigantic thing, and then it takes some time for the kinks to get worked out. And I would not be surprised if that were the case with Vista as well. So my own personal view as a technologist would be, well, let’s wait around until the early adopters have all died off, and then let’s probably use it. That said, what I have sitting on my desk is an Apple Mac with Pro, which I use. And I run parallels when I need to have Microsoft software running. I actually run XP Service Pack II in a virtual machine on top of my Mac.
LINDA MCGLASSON: Very cool.
GARY MCGRAW: So that’s how I do compensation.
LINDA MCGLASSON: Your Podcast, the Silver Bullet, is well known for its incisive interviews. What’s coming up on it? Which one is your favorite? And where may our audience find your Podcasts?
GARY MCGRAW: Oh, boy. So I have to pick favorites. That’s going to be a toughie. It’s a lot of fun because the idea behind the Podcast is that, you know, I interview other security gurus and ask them questions that are surprising, which is a lot of fun. I never tell those to anybody, the questions, in advance. The one that’s coming up now I was just editing the interview of a Podcast that’s released with John Stewart, who’s the CSO of CISCO and a good friend of mine. And what we do is we’ll take a transcript of the Podcast and take pieces of that and publish it in IEEE’s Security and Privacy magazine. So that’s going to be released in the January-February issue of that magazine. Meanwhile, you can get that Podcast at the Silver Bullet website, which is www.Cigital.com/SilverBullet. Now, when it comes to favorites, that’s a really good question. I think one of my favorites is the one that I did with Bruce Schneier that was released in December because Bruce is quite a good spokesperson for computer security, and he has a lot of great stories and tons of experiences. And he knows how to relate security to people who may not be everyday security people. So I got a kick out of doing that one with Bruce.
LINDA MCGLASSON: He answers the ma-and-pa information security questions.
GARY MCGRAW: Yeah. And it’s very important that we have people to do that who are also incredibly knowledgeable and able to get those points across in simple enough terms that people can understand it.
LINDA MCGLASSON: Your take on Google’s code search– and how will this impact banks with poor or holy software or an inadequate patching routine?
GARY MCGRAW: There’s a new Google thing that might be worth mentioning. Just over the Christmas-New Year’s- Hanukkah break, there was a big problem discovered in the way gmail works. And it turns out that if you have your gmail session going while you go to a malicious website, they can suck all of the contact out of your Google mail pile, including your own identity and your password at gmail. And that’s a huge problem.
LINDA MCGLASSON: Everybody’s on gmail.
GARY MCGRAW: Everybody’s on gmail; and if you think about it, many of the banks might have employees who have a gmail account and they use that through their web browser at work. And so the question is what happens if they’re susceptible to these sorts of phishing attacks like that where you get a piece of malicious code that’s based on Java Script and based on calling, you know, one of these objects, and people are finding out information they shouldn’t find out. So I think that what you see with this sort of thing is a bellwether of what’s to come when we begin to adopt service-oriented architectures, or SOA, when we begin to really talk about web 2.0 and what does that mean for small or medium-sized banks because, you know, a lot of this off-the-shelf software that you were talking about before is going to be web services related. And so as we begin to adopt these new architectures, we have to think very carefully about that problem and the trinity of trouble, that extensibility problem. The notion that we’re using Java Script, that means that it’s pretty straightforward and simple and easy to extend; but it also means that it’s also easy for other people to extend it surprising ways where you may not have anticipated. So, you know, that’s kind of an interesting thing. Now, getting back to the actual question that you asked me – Google also has this code search capability, and they actually copied the idea from a little website called Buggle [phonetic] in the beginning. And the notion was to use web spiders to look around for source codes on the Net instead of just spidering up website URLs. And, of course, you can use that to find little code snippets on the Net, including bugs. So you could actually use it to search for, say, buffer overflow problems in somebody’s source code, and then find out whether or not some bank or some other target has problems in the source code that they accidentally posted on their website. So there is a real simple answer to this, and that is don’t publish your code publicly on your website. So what happens is people do that either accidentally or through silliness or poor configuration control or whatever. So that’s the number one thing you ought to do. And then there’s kind of a funny aspect of it, too, because as soon as the code searching capability came out, of course, we started searching for silly things around here. And it turns out that developers actually cursed in their source code a lot more often than you would expect in common. So you could search for bad words just like you could do in sixth grade with the dictionary, and it’s surprising what kind of hilarious comments people have in their codes. So you have to make sure that your developers are not putting comments like that in your codes.
LINDA MCGLASSON: That’s pretty funny.
GARY MCGRAW: It’s true.
LINDA MCGLASSON: This is coming from a quote or a line in your book: Who or what is the info sec boogeyman?
GARY MCGRAW: Well, let me tell you where that came from. So I hang out with software developers more than I hang out with security people, as you probably know. And many security people scare the daylights out of developers because developers work very hard to build a system; and then right before it’s supposed to ship, these security guys come along with sticks and beat them about the face and neck saying ‘your software is bad and insecure and we can’t put it up,’ which makes the developers really sad and sort of surprised, and it also makes them want to avoid the info sec people. So whenever they see the security people coming down the hall, they hide under their desks or around the corner. They just run away. You know, usually there’s this wave of developers running in front of security guys coming down the hall. And that’s the info sec’s boogeyman. So what we have to do is break down those barriers between people with good, deep security knowledge and people who are building our system, these developers. And that’s what my work is all about. In fact, software security is a book that’s better suited for developers and architects and people involved in building software than it is for your classic security guy.
LINDA MCGLASSON: Do you have any final parting advice to those info sec practitioners, risk management officers, and others who are fighting the battle at financial institutions everywhere in the US?
GARY MCGRAW: Yes I do actually. When it comes to software security in particular, make sure that whatever help you get, whatever vendors you choose to, say, do training or whatever software you buy, is built by people who are software people or is delivered by people who are software people because what I’ve found is that there are a number of very good security types who are hanging up shingles today saying, ‘we do code review’ or ‘we will give your developers security training.’ And though these guys are very knowledgeable when it comes to network security, they really don’t know that much about software, and they lose the developers right off the bat because, you know, developers are sort of arrogant and very skeptical, cynical guys. And they don’t want to listen to some “dumb security guys,†how they would put it. So the answer to that is to bow to their silliness and allow and find some software guys you can put in front of them that actually deeply understand security as well. And so part of my vision is trying to figure out how to grow people like that, how to make new software security people, and how to address those sorts of needs for training from very deeply experienced software guys that also know something about security, for example, or a code review by people who actually write codes, that sort of thing.
So I’d say, you know, watch out for security people masquerading as software security people is my last piece of advice.
LINDA MCGLASSON: Gary, thank you so much for being a part of our Podcast series, and we’ll look to hear more from you in the future.
GARY MCGRAW: Thanks a lot, Linda. It’s been fun.