OWASP Podcast/Transcripts/010

OWASP Podcast #10: Interview with Ken van Wyk

Participants

Ken van Wyk

is a CERT® Certified Computer Security Incident Handler, as well as an internationally recognized information security expert and author of the popular O'Reilly and Associates books, Incident Response and Secure Coding: Principles and Practices, as well as a monthly columnist for eSecurityPlanet. Among his numerous professional roles, Ken is a Visiting Scientist at the Software Engineering Institute at Carnegie Mellon University, where he is a course instructor and consultant to the CERT® Coordination Center.

Personal Site

Linkedin Profile

Transcript

Jim Manico

We have with us today Ken van Wyk. Ken is a CERT-certified computer security incident handler, as well as an internationally recognized information security expert and author of the popular O'Reilly books, Incident Response and Secure Coding: Principles and Practices. Hey Ken, thank you very much for being here.

Ken van Wyk

Hey Jim, it is good to be here. Thanks for having me.

Jim Manico

Ken, can you start by telling us how you got involved in IT and what eventually got you into the world of web application security?

Ken van Wyk

Well for starters, I do have some software background many years back. Along the way doing IT security, pin testing, and things like that, I recognized that I just could not answer the questions that my customers had, namely are we secure? I can put firewalls around it, we can put in intrusion detection systems, but fundamentally, I just knew that we could not answer the question that they were asking unless we could see inside the software that they were running, so it just to me seemed like an obvious and natural thing to want to focus more attention into the software itself.

Jim Manico

What are some of the challenges you faced as your career shifted more into application security?

Ken van Wyk

Well, I have to say that just convincing people that there are no quick fixes. You can't just put a firewall in front of something and expect it to be secure, because along came things like web app firewalls. They say, well, we can just put this web app firewall in front of this software. My answer to that is well, it's useful, it does some neat stuff, but it's not going to make you secure. I understand that is a controversial thing, but that has been the biggest challenge is just convincing people to pay serious attention to the software.

Jim Manico

Has that task gotten easier over time as there has been more industry awareness about application security in general?

Ken van Wyk

I think it has a little bit. I think that nowadays, I don't have to struggle quite as much, I suppose, to convince a decision maker that the solution has to be in the software as well. I think that is partially because of all the bad news that we hear about. I do think it's gotten a little bit easier, but not a lot.

Jim Manico

Ken, you have been a very vocal opponent of pin testing, yet you yourself are a pin tester to some degree, so what do you think is wrong with pin testing based assessment?

Ken van Wyk

Well, fundamentally, I don't think that it is wrong. I think it is an important thing to do. I think that we have to do pin testing and application pin testing in particular. Where I disagree with it is where people do that as their only thing in terms of security testing. It is a very outside-in driven sort of a process, poking at some software from across a network and seeing if we can get it to break is good and useful for a lot of things, but unless we are looking inside the software, we are going to miss a lot of stuff. We can test inputs against known attack patterns and things like that and hopefully, that will bear some low hanging fruit. When you really want to focus on things like PCI compliance and such and how secure the software is inside, we have got to be doing a lot more in security testing other than application pin testing from the outside in.

Jim Manico

Ken, would you like to give us your thoughts on OWASP and possibly tell us what your favorite OWASP project is?

Ken van Wyk

You know, there are so many things. I am a huge fan of OWASP. I have been a believer in what OWASP is doing for several years now, since I first ran into them. There are several things that are really useful, but I think just kind of strategically thinking a little bit, I have to say my pet project is WebGoat. I think that it has been responsible for opening up more application developers' eyes and giving them a tool that they can really internalize what a problem is. I think that is, in the long run, educating those application developers with tools like WebGoat. That's going to help solve a lot of issues over time. The stories I use are things that have come from my own experiences. I use them based on who I am talking to, so if I think that a particular story is really going to work well with this audience because they will get it and it will in turn help them internalize an issue, that's the one I pull out. I try to make them as topical as I can based on the sort of people and the sort of backgrounds that I am talking to. I did an application review of a credit card paying system for a big hotel chain not that long ago. That is one I use a lot because Java people can really internalize it, and we look at some of the mistakes people make with things like incorrect use of cryptography. The cryptography problem in that case study or that project turned out to be a huge issue. There is no great solution to the problems that they faced, so we look at the architecture and discuss it. Then, we talk about the real world problems that these guys face with regard to encrypting credit cards. That tends to work very well for a lot of Java people because they realize that there is no perfect solution to things. You just have to make the best business decision that you can.

Jim Manico

Ken, if you had the attention of all the Fortune 100 CIOs, what would you want to tell them with regard to application security?

Ken van Wyk

There is just no quick fix. We want to be able to take like a top ten list and check off all ten boxes on our audit checklist and say we are done with this. That is not solving the problem. That solves ten little issues, but not the problem. Software security is a lot like quality. You can't just take a checklist and all of a sudden now you are developing quality stuff, so it's a lifestyle change, and you have to pay attention to that at a big picture level, as well as paying attention to those checklist sort of approaches. I say that not to throw stones at projects like the OWASP top ten, because that's useful and valuable stuff. To the CIOs of the world, guys and gals, there is no quick fix. Let us pay attention to the bigger problems.

Jim Manico

Ken, web application security can be a rather daunting topic for the beginner. Do you have a recommendation for a software engineer who is first approaching the topic of application security?

Ken van Wyk

One thing that I tell all of my customers is that a cheap and quick and wonderful learning tool that I have mentioned in here already is to get all of your developers a copy of WebGoat and make them work through all of those exercises. Directly to the developers, I would say learn, soak up all of the information, read and understand that people are going to break things in ways that you have not anticipated, so open your mind up and look at the way that people break things. That is why I like WebGoat so much, because it makes you understand how things break. A lot of times as a software engineer, you are thinking functional specification. You are thinking functionality. When you see how people break things, it really makes you kind of scratch your head and go boy, I had not really considered looking at it that way. Opening your mind up that way is extremely useful.

Jim Manico

Ken, do you have any advice for the information security professional who is trying to get through to software engineers to really care about this topic?

Ken van Wyk

So, that is an excellent question. I find that a lot of people that do information security, pin testing, and things like that, that get in front of software developers…A mistake that is commonly made is that we infosec people think of the world from a network security standpoint. It is not just about the seven layers, right? We have to understand the software. If you are going to stand in front of a room of software developers and presume to tell them a little bit about software security or application security, you have got to meet them halfway at least and understand their technologies. It does not mean that you have to be able to write Java code or C Sharp code, but you better understand the technologies that they deal with. It's not just an issue of hey, SQL injection is really bad, but you've got to be able to tell them the reason SQL injection works is because many times the SQL calls you are making are mutable, and you have to use an API that produces an immutable SQL call, such as prepared statement. They're going to understand it that way, they will understand it, they do understand it, but you've got to put it in terms that are meaningful to the developers. That means if you are going to go out there and try to train those developers, you better understand their software.

Jim Manico

Ken, what would you recommend to the small business that is writing a lot of custom software, in a situation where they may not necessarily be able to afford a static analysis tool, but they still want to do some kind of code review process? What would you recommend?

Ken van Wyk

I would have to start by saying that I am a big believer in doing source code analysis, and I find that it is very frustrating that we don't have great solutions yet in the open source world for doing source code analysis. You have some of the early research projects like ITS4 that Gary McGraw talked about a few days ago on the podcast, but those are not business tools. They are research projects, so my first statement is take a look at some of those source code analysis tools. I understand that a lot of them are pretty expensive, however, they are good stuff. If you still just cannot do that, there are a couple of things that are useful to do. One is, I'm a big believer in not just looking for problems in code, but enforcing positive practices. Like, the ESAPI essentially is providing code patterns for doing secure things like output encoding and authentication and access control. If it is not ESAPI, provide your developers with methods and tools and software they can use that do those security related functions. Make sure that they are complying with those coding guidelines. Your coding guidelines have to be specific, and they have to be actual code. Secondly, it is not that difficult when you're doing design level review to prioritize where the high risk areas of the code are, things like authentication and things like encrypting sensitive data. Those surface pretty quickly if you are doing things like threat modeling or if you are doing something like the Cigital Architectural Risk Analysis. Take those highest risk portions of your code and do manual code review on those looking for compliance to those positive practices. You can accomplish code review then without a tool. I am not going to say that it is easy, and I still prefer to use a tool, but you can do pretty darnn good source code analysis manually. I just finished a Java project about a month ago where we did exactly that. We took a look at this Java business code and prioritized down to about ten percent of the highest risk portions of the code, and we did code review on those without tools. It worked very effectively. Then, we went and tested the scenarios that we came up with in the source code review. We went and tested those and verified that the problems we found were in fact problems.

Jim Manico

Ken, your book Secure Coding: Principles and Practices, it was actually one of the first books that I read in my pursuit of application security. Would you care to tell us what prompted you to write the book, how difficult the process was, and what came out of that process?

Ken van Wyk

Well, the secure coding book that Mark Graff and I did was published, first of all, in 2003 by O’Reilly. We are very grateful to them for the support that we got on that. It really came out of a project that Mark had done with us when I worked together with him at Para-Protect years ago where he did a review of the software security space. This was circa 2000 or 1999 even. It was several years back. From that, Mark had put together a white paper that we had made available to several of our customers. We decided to turn that into a book. Mark got that project started, and then he asked me a little bit later if I was willing to help coauthor it, so very pragmatically, that is how I got into it. In fact, I was on vacation in Hawaii when it happened. He called me one day and said can you help out with this project? I said I would be happy to. Now to answer your question of what came out of that…Even though, as I said earlier, I have software in my background many years back academically, and while I was working in the first few years of my career, I did quite a bit of software development, I am not a software guy, so when Mark first asked if I was willing to take on this project, it was quite intimidating to me to be very honest. I wanted to do it and felt that it was important for all of those reasons that I said earlier on the podcast, so I said alright, let’s do it. It took me a tremendous amount of effort to dive into trying to understand the problem space better before I felt that I could speak to it in an intelligent sort of way. I would say that since then, that was 2003 and now it is 2009, the ball has moved down the field significantly. A lot of things that I am very aware of now, like Microsoft’s SDL and the Cigital Touchpoints stuff in my mind, or at least from what we could find, those things did not exist when we were working on our book project, even though they might have been in their formation cycles at that point. I think that when I look at that problem space now, the solutions are a whole lot different from what we wrote about back then. I am grateful that I had that opportunity. It was a lot of fun to work on the project.

Jim Manico

So, I hear you are working on a new book now. What problem space are you planning on addressing?

Ken van Wyk

First of all, I should plug my publisher here. We are working with Addison-Wesley on this one. It is Mark Graff and I that are teaming up on it again. Mark and I love the collaborative work that we have been able to do together over the years. One of the big problems I have seen in trying to get into this space in the last several years is that I often see software development environments where we have the software developers and we have the security team. It is very much of an adversarial sort of relationship in a lot of shops. Now there are some companies that are really leading the charge in making those two groups work better together. Those are the exception and not the rule, so the book that we are currently working on, the project name for it is Confluence. We are really trying to encourage infosec people and software people to collaborate more effectively together, so we are looking at things like the Microsoft SDL and the Cigital ARA. We are stepping through in a very practical way. Here are the things that you can do, and more importantly, here is how you can work with the security team and security guys, here is how you can work with the software developers to make this work better. A lot of times I see software developers, as I said earlier, tend to focus on functional specification where security people tend to look at things and think of how things can break, but do not really understand how the software works necessarily. To me, there is a complimentary relationship between those two. It is just a matter of trying to figure out how to get them together and play nicely rather than just throw stones at each other all day. That is one of the main outcomes that we are shooting for in the book, is to help software and security people work nicely together.

Jim Manico

Ken, what would you recommend in a situation where a company is depending on a third party product and they need to reduce risk, but they do not have a copy of the source code?

Ken van Wyk

Well, you can start by reading the OWASP project that was done last year on the summer of code. Stephen Craig Evans I think was the author who did this on securing WebGoat using ModSecurity in Apache. That is probably an extreme example of something like a web app firewall. One of the underlying things that he tried to tackle in that project was to take this thing that is inherently insecure, WebGoat is intended to be insecure, and see if he could secure it with ModSecurity without hanging a single line of code in WebGoat. Essentially, he emulated that he had no access to the source code. By gosh, if you can secure something as insecure as WebGoat without access to the source code, you ought to be able to secure pretty darnn much anything, so I thought that was a really fascinating project from that standpoint. More to your question, I think if you have software that you absolutely rely on and depend on and do not have access to the source code…Let’s face it, that happens all of the time. What can you do about it? The traditional IT security mentality would tell you to put firewalls all around it and put web app firewalls all around it. There is value to some of that. I am not a huge believer in web app firewalls as I said earlier. However, in a circumstance where you do not have access to the source code, that is one of the cases where web app firewalls can provide some real value. If you are willing to spend the time to define for the web app firewall all the interfaces of that software and allow that web app firewall to essentially do positive input validation for all of the IO of that application, that means that you cannot just deploy the web app firewall and watch out for the OWASP top ten mode. It just cannot sit there and look for a list of bad things, because then it is fundamentally an antivirus type methodology, which is doomed to failure, so I think that part of that problem can be solved with things like web app firewalls if you deploy them carefully. Part of it can be solved by really carefully compartmentalizing the environment where you are placing this stuff. If you have third party code, let us look at things right down to the Java security manager. If it is a J2EE module, let us put some sandboxing around it using the security manager. It is not a perfect solution at all and such, so we want to combine several things together. I would look at ways of defining and then securing the boundary layers where we have connections to and from other software. Let us make sure that we are properly doing input validation across them. A web app firewall can certainly be a piece of that.

Jim Manico

Ken, would you care to look into the future for us? What do you think is going to be on the OWASP top ten in 2018?

Ken van Wyk

Well, I listened to Andrew van der Stock’s answer to that, and I tend to at least partially agree with his somewhat pessimistic outlook. I think that we are going to be seeing things like cross-site scripting for a long time. Before I dive into an answer on that, let me just take you back in history a little bit, because I think that if we explore our history a little bit, we will have a better understanding of what the future will look like. In 1988, the Morris internet worm…I was working at Lehigh University up in Pennsylvania when that hit the Internet. Shortly after that, I went to work at CERT at Carnegie Mellon. When that hit the Internet, it was a really big deal. I went out and I studied everything I could learn about this. A few months after the attack, there was an issue of the communications of the ACM Journal where they analyzed the worm code and really described how this thing worked. That was the first time I learned about buffer overflows. That particular journal was published in May of 1989. I looked at that and studied it, and I read about buffer overflows. I found it to be fascinating how Morris was able to use a hole in the Berkley finger daemon to get some code to run on another machine across the Internet. I looked at that and read the articles, and I thought great, we are done with buffer overflows because this is published. We all understand it now. We can move on and come up with new problems, right? Obviously, that did not turn out to be the case. We saw buffer overflows for many years, and in fact, if you go out to CVE, you will find that buffer overflows are still being written today, 20 plus years later, so that is why I tend to agree with Andrew’s statement that I think we are going to be seeing the likes of cross-site scripting for a long time. I think that things like cross-site request forgery are a little bit less understood. I would like to think that SQL injection will die away, because that is a pretty simple change to make in most code, to use an API like prepared statement, so I would like to think that the number two on the list right now is going to die away, so now I am trying to extrapolate out into the future a little bit. As I said, I think that cross-site scripting is going to be with us for a long time. I think that some of the unexplored space in the vulnerability world has to do with timing. We see if you look even at some of the WebGoat exercises on concurrency, there is a lot of subtlety in what happens in concurrency and scoping of variables and things like that in Java code, where unexpected things can happen in a Java Servlet let’s say, just because you are being hit by two instantiations of the same Servlet simultaneously…We do not yet have our heads around that problem enough to really understand the ramifications of timing problems and concurrency problems in massively parallel micro processing environments. I think that we are going to start to see problems come up in timing of code that people have just barely explored. You can look back to Matt Bishop and Mike Dilger’s work on time of check, time of use problems years ago. We have race conditions like that and UNIX for many years. I think in terms of micro or multithreaded environments like on massively parallel Java and C Sharp for that matter deployments, I think that there are timing issues there that we don't yet understand and people have not really began to poke at very much, so if I were to kind of look into that crystal ball and think what is going to happen down the road, it would not surprise me at all to see timing related problems start to pop up in a much bigger way than what we have seen so far, that and some of the problems that we currently see. I think that cross-site scripting is probably the biggest one that we have in front of us right now to deal with. We do not seem to be doing a very effective job at getting rid of that just yet.

Jim Manico

Ken, there is definitely a trend in the application security world where new exploits or new attack techniques will get a lot more press and attention than new defensive techniques or defensive information in general. Do you have any thoughts on the whole builder versus breaker debate?

Ken van Wyk

Yeah, I think that first of all that breaking stuff is certainly more sexy, if you will, so the media tends to gravitate to that and you get more readership when you say, hey, I have figured out how to break something or other, a lot more interest than I have figured out how to build things securely. There is that natural symbiotic relationship also, I suppose, between the builders and the breakers. Having spent a lot of time on both sides of that issue, I would have to say that we need to continue talking about how to build things securely. I like what Gary said also. His philosophy is stick to your message and keep repeating yourself. It is important. We have got to be telling people how to build things securely. At the same time, I find that people really internalize a problem when you show them how it breaks, so when I get in front of developers, for example, and I try to help them figure out the problem space. I will use tools like WebGoat to help them internalize the problem and then turn that around and say okay, we have just seen something like forced browsing, which is fundamentally an access control problem. You have seen how it breaks. Now let us talk about how we can fix that. You can get that messaging in there even using a tool that teaches you how to break things, so I think it is really a question of how we properly position those messages so that people can internalize the problem and still get the message out about what the solution is.

Jim Manico

Ken, I see that you have a timeshare here on my island here on Kauai, so may I ask what your favorite place to eat and drink on the island is because next time you are here I am buying.

Ken van Wyk

Well, first of all, I kind of object to you calling it your island. I have always thought of it as my island ever since my wife and I honeymooned there in 1989. Seriously, there are several places that I like on the island. If you like Italian food, Dondero’s over at the Hyatt at Poipu is fantastically good. It is not cheap, but it is fantastically good. My favorite casual place on the island I would have to say is the Waimea Brewing Company. They make some really nice ales. The quality kind of goes up and down over time that I have been going there, but you just can't beat it for the ambiance. Go there in the late afternoon and have some of their mango barbeque ribs and a nice glass of ale and sit back and enjoy the breezes. That is why we enjoy going back to Kauai so much.

Jim Manico

Well, I look forward to meeting you next time you are on the island, Ken.

Ken van Wyk

I look forward to it too, Jim.

Jim Manico

I am sure you do, sir.

Ken van Wyk

I only go back there every two years. Man, I wish I could go there every year. I land at Lihue Airport, and you can feel the blood pressure go down and everything seems right in the world.

Jim Manico

Well, Ken, next time you are flying into Kauai, let me know, and I will be there at the airport ready to start an application security conversation with you the moment you hit ground.

Ken van Wyk

Yeah, right. That will help the stress level go down.

Jim Manico

Well, Ken I really appreciate you taking the time to interview with us today. Do you have any final thoughts before we finish up?

Ken van Wyk

Yeah, I would say that in the software or application security space we have a lot of challenges. We have got a lot of work to do. I love what OWASP is doing. It is some valuable stuff that you guys are putting out to the community and for free. I applaud that. We have a lot more work to do. Gary was talking about a maturity model. When people first mentioned that to me a few months ago, I immediately pushed back and said wait, wait, wait, we are nowhere near ready for a maturity model yet in my view. I think that this community has to mature a lot more. When I think of a maturity model, I think of engineering and I think of decades or centuries old practices like designing bridges and things like that. We are nowhere near that in software engineering. We still need to learn from our mistakes for a lot longer. I think that initiatives like that are forward thinking and very useful. I also recognize, like I said, that we have a long way to go, so kind of my parting words are that we all have to keep slogging at this stuff guys. It is a lot of work. We do not understand all of the problem space yet. We should not fool ourselves into thinking that we do, so let us keep pounding at the problem and trying to convince the decision makers to pay attention to it. It is not just as simple as putting firewalls in front of our stuff to make it secure. It is a much bigger problem than that. Hope that we do not see a lot of real nasty disasters in the press, because even though that gets us the attention, it is the wrong kind of attention. The responses we see to big problems and big intrusions are not necessarily good. They are knee jerk reactions and not the sort of long term responses that we need strategically for this community to grow in a positive way.