Application Security and DevOps: Q&A with Author Kenneth Van Wyk
Application security is one of the most important topics in information security, and few know the subject better than Kenneth Van Wyk. He has been a career IT security expert for more than 30 years and specializes in both incident response and software security. Van Wyk has authored two popular O’Reilly books on application security and incident response, and a third on enterprise software security published by Addison-Wesley in December 2014. He also has considerable experience in delivering security training and as a public speaker.
Below is an edited version of our recent conversation.
George Hulme: Thanks for taking the time today, Ken. Can you tell us a little about your experience and what you are currently working on in these areas?
Kenneth Van Wyk: I remain very active in two specific niche worlds. One is incident response operations. I do a lot of work there with tabletop exercises and planning.
I’ll come in and look at their planning. I’ll test it, and I’ll suggest ways that they can improve their incident response planning. And then we come back and verify that you’re actually implementing those improvements.
I do a lot of operationally focused things like that, but the other area where I do a heck of a lot of work is in application security. I do a considerable amount of enterprise application security and security application development training.
Hulme: That’s excellent. It strikes me that despite how important application security is, not enough organizations take their application security very seriously.
Van Wyk: Yes. It’s always an add-on. And that’s why companies, like my clients, will have their own internal secure development training. They realize that what the universities have done is inadequate. So companies have created programs where their developers learn how to code securely. I think that’s awesome, but I also think that it would be nice if we could take that a little bit farther with our undergraduate curricula. The flip side of this argument is that in a four-year curriculum there’s only so much that you can be taught, and if they’re taught to teach security then something else has to be cut. And so it should just be part of how students learn Java, or C, or whatever language they’re learning.
Hulme: Still, I hear from enterprise development teams and CISOs that companies would appreciate students who had better handle of security coming to the marketplace.
Van Wyk: Yes, I agree. Maybe they’re just not making their needs known well enough to universities. Maybe universities aren’t reaching out enough to their customers. I don’t know the answer. But most of my clients tend to be in the financial sector, and they’re much more security aware, of course, than most industry sectors. So, maybe they realize they need security and they’re willing to take what comes out of the university program and shape them to their needs. That’s a great attitude, and I like that attitude, but one way or the other you gotta go farther than what the universities provide.
Hulme: How do you think DevOps changes application security? In my discussions with DevOps teams, it seems that organizations can bring a lot of bad processes and bad habits, or they can do things right and create a pipeline with a lot of good automated testing and create improvements.
Van Wyk: I agree. I’ve seen good examples and bad examples. The bad examples happen when we use DevOps/Agile, whatever you want to name it, as an excuse to just move forward without doing things like documenting their design because “the design is the code” and such nonsense.
When I hear things like that, I just hear an excuse to be sloppy. But, I’ve also seen some shops where the people really understand security, and they’re using DevOps, and they’re able to rapidly move their coding along. And I love that.
But my opinion is that one can write secure code with waterfall, and one can write secure code with DevOps. Likewise, code can be written very poorly in both worlds. It comes down to the people. And when you have a team that understands the issues, they’re going to turn out secure code. And it’s a matter of getting the right people and inculcating the right attitudes.
Hulme: Do you think it’s harder with waterfall for large organizations to write secure software?
Van Wyk: No, I don’t. In many ways, waterfall appeals to me because that’s the classic software engineering that I was taught at Carnegie Mellon in the Software Engineering Institute. And what I saw back then, we would have called it like rapid prototype sprint sort of a model. That’s what evolved into DevOps/Agile. And I think either way works fine, and there’s applications where both make a lot of sense. And not simultaneously, mind you. That’s anarchy, but I can see times when conducting a waterfall process can make a lot of sense. Similarly, I see times when DevOps makes a world of sense. Especially very customer facing, user interface sorts of things, where DevOps appeals because developers are able to add value quickly. If you do it right, and you’re paying attention to the big picture, you can produce really good stuff.
But I think more than the process, it’s the people and the attitude. I’ve seen waterfall environments where creeping featurism kills them over time. I’ve seen DevOps where creeping featurism kills them over time. And so, you know, you can screw up in either process, or anywhere in between. And you can do well in either process or anywhere in between.
Hulme: I agree. What do you think needs to be done to broadly improve software quality?
Van Wyk: It has to be a priority. It can’t be something that we’re willing to decide is a priority and make it a priority in their work. They can’t decide to push version one of something forward with a promise that they’ll add security in version 1.1. And it requires a top-down commitment. If they aren’t committed to making sure the application is secure then they are just going to screw security up irrespective of what process they use.
