Interview: Kevin Peterson, Senior Manager of Risk at McKesson

For this interview, we have with us Kevin Peterson. He's a Senior Manager of Risk at McKesson's Enterprise Information Solutions line of business. Kevin's got 20 years of experience and he spans, I think, just about every role in security that you can have. He's also a globally recognized champion of what he calls "Infosec by Design."

Kevin and I discuss his thoughts on what he calls "Leading design of the human oriented information security experience." Kevin also shares his thoughts on the common struggle people have in the industry on, "do you want you application secure or usable?" and how those two ideas do not need to be mutually exclusive. His vast knowledge on this topic leads to an interesting discussion on how we can make security easier for end users and the culture of security at McKesson.

The following is a brief excerpt of our interview.

Jeff Williams: Getting back to product a little bit, I really like your focus on ease of use and usability and so on... Where do you see some more opportunities for the security industry to get better at this?

Kevin Peterson: I think some of the challenges that we've faced - kind of hands on with our development organizations - it's how do we give them the right information at the right time? One of the examples that I like to give is that we have tools and stuff that's been out there for a number of years now where you scan codes, you do security scans and everything after everything's been checked in and it spits out a score, whatever the case may be. I like generally. I think that's a step in the right direction.

The challenge that comes from me when I see those is that I don't even actually want to look at them when it's early dev work, any more than if I'm a college professor do I want to read somebody's paper before they've even run a spellchecker on it or they've done any editing. They might just be learning on their own rights. What I don't want to do is stand over them and go, "You did that wrong. You did that wrong. You did that wrong," because I'm a person. I do love the idea of tools that can stand in that place, much like Word doing spell checking, to keep it super simple, where it puts a little squiggly line underneath it and says, "You need to review this."

Jeff Williams: Yeah, absolutely.

Kevin Peterson: Because then it's right there, it's in the moment and I go, "Oh, yeah," maybe there's a little pop-up help, whatever the case may be. But as far as scoring the individual users, not really too crazy on that sort of idea.

One of the other things that are great opportunities I see is to get product management much more involved for all products in the security conversation, along with their developers, really to set the bar and set it as high as it needs to go and continue to reset it over time. The product managers, they understand what the market requirements are. They understand the needs.

They can communicate that quite effectively and they can make the trade offs. Go back, work with the developers, work with the engineers, whoever's in the mix, sales teams, whoever's out there. Broker the right discussions, have it as meaningful as possible. Then release what you can. Look, everything's not going to be perfect, certainly not in version 1.0, maybe not in version 4.0 or version 12 of any software release, but you continue to move it forward and continue to raise the bar.

We want those product managers to really be there to set that tone with them, as well as even above them, the top corporate leaders. I've been amazed, I'm sure you have as well over the years, although we haven't spoken about it yet, but Microsoft. Microsoft, 2002, Bill Gates released his infamous email about trustworthy computing. I saw it just last month that they're looking to shelf that idea or that program within Microsoft and it's all over the rumor mill. I don't think Microsoft has officially made it announced yet but the question it becomes, "All right, why would you do that?"

I actually like the idea because if you look at it, for the time that they had it, they did a wonderful job with it. I absolutely am a huge fan of what they achieved in the time that they had that. Now they've built the program, do they really need this as a marketing tool anymore? Do they really need a central body or can they decentralize it and just let every, through Agile and all their SDOC and dev ops and everything else, can they just accept that their teams on a per product basis have that instilled in their DNA now?

I would hope by now, 10 years or 12 years, after releasing that, that they would be to that level of maturity. I think Microsoft recognizes that.

Jeff Williams: I just think that's a brilliant insight and I'm totally on the same wavelength with you. I see a lot of organizations that they stand up these application security teams or software security groups and the group, it is evangelical in a way. They need to do that in order to get the word out and you get organized about the problem. What happens is then that group becomes a bottleneck. All of the sudden they're blocking projects from getting through the testing process and into production and they're slowing stuff down, they're making it difficult and they really end up harming application security programs overall.

I think you're right that the future is this very distributed application security where development groups treat security like any other business requirements. They have to deliver secure code and they have to prove it. They have to run the tools themselves and they're responsible for security.

Kevin Peterson: Absolutely. Even going back to what I was saying before about - I can't remember your exact question but you asked something about, as it relates to the future, security and how tightly it can be coupled, I did want to elaborate a little bit on that in this conversation.

Security, what we are ultimately looking for with all of our product groups, is to have it implemented in a way that it can't be removed. I actually did a slide on this. I put a glass of tea and said to our developers, "Once you have taken the tea and put it into this glass of water, you can't remove that tea."

Jeff Williams: Right. It's an unscrambling the egg problem.

Kevin Peterson: That's right. Unscrambling the egg. When you look at security, that's ultimately what we want. That's what the customers want. They don't want trade-offs to be made. "Well, our encryption wasn't quite ready yet so we went and released it without it." "You did what?" Or you can just imagine all the different types of scenarios, but once it's in the DNA of the individuals, the organization, and all the way into the product, you realize, "I couldn't remove this type of security if I tried." It becomes a thing where compromise is not even an option that you can have discussed in any meeting - not with a customer, not with anybody.

Jeff Williams: Yeah, I think that's right. I think security is very sticky. Once you actually start laying it down and doing it the right way, it just gets entrenched and you get this kind of path dependence effect. Maybe that's where Microsoft got to is the point where it's built into the whole organization and they don't need a special standalone program to coach it and nurture it.

Kevin Peterson: Right. In our organization, we don't have a trustworthy computing group. A lot of companies don't. It doesn't mean you can't build very trustworthy computing models and security patterns and cloud solutions and everything else. I think it's just where you're at at the time. I would look for more companies down the road to really latch onto that same concept as well of saying, "Look, we don't need that big, centralized program. We don't need corporate security involved in every single decision. We've got this. We can absolutely build this."

Jeff Williams: I love it. I absolutely love it. Last question. I know you're a pilot, you've very into flying. I'm wondering what do you think we can learn from the flight industry and all the safety work that goes on there? Are there any lessons there that we can take and apply to application security?

Kevin Peterson: Wow! Did not even think you would bring that up. Yes, I am a pilot. I fly Cessnas and gliders and absolutely love that stuff. You know what? I've got one - checklists. Checklists are an amazing thing to help everybody understand what's going on out there.

A lot of checklists actually exist if you just open your eyes and start looking for them. One of those I actually kind of already mentioned. You have the Cloud Security Alliance Cloud Controls Matrix. If I'm a developer or a product manager and if I'm going through the needs of a new product that we've just envisioned and we're starting to work on it, of course I can do a bunch of really great design thinking and think, "How could I build security in a way that I can minimize the exposure that I would even have to apply all these Cloud Controls Matrix too?"

Well, that's a great start, but then when you're left, when all is said and done, you really do need to go through some of these. The very first thing in the Cloud Controls Matrix is the application and interface security, I believe, is exactly how it's spelled out, the very first section and in there, some bullet points. How do you measure up against this SANS 20 top 10, all that sort of fun stuff? Great question. As a developer you go ahead and answer that. Go look it up if you don't know. That's a great start.

Great checklists. You can go through all that . . . yeah. Some companies have their own checklists they come out with, typical GA checklists. I have never seen one, personally, that really is that beneficial from a security standpoint. They're usually more, "Did you put your code up on GitHub? Did you put it in escrow?" all the other fun stuff that you need to go through. "Did you run it by your security leader?"

Jeff Williams: Yeah, I think checklists can be dangerous, actually, because they tend to oversimplify things. Where they are useful, I think, is as sort of a double check that you did everything right along the way and you're just maybe sampling or verifying it at a later stage of development. Earlier on in development I think you want to have a more sophisticated model that you build against, but I think later on, having some of these checklists just prevent the obvious mess ups that can sometimes sneak into a process, so I think they can be really useful.

Kevin Peterson: Right. Going back to flying, I won't fly without my checklists. I'll have a backup of my checklist. I've got it electronically, I've got it printed out. For the simple ones, I have it memorized.

To listen to the rest of my interview with Kevin, click here.