January/February 2013 (Vol. 11, No. 1) pp. 8-10
1540-7993/13/$31.00 © 2013 IEEE

Published by the IEEE Computer Society
Silver Bullet Talks with Per-Olof Persson
Gary McGraw , Cigital
  Article Contents  
Download Citation
   
Download Content
 
PDFs Require Adobe Acrobat
 

Gary McGraw interviews Per-Olof Persson, currently head of global software security operations at Sony Mobile. Persson discusses the importance of working in different positions within the same company—from directing the Sony Board to running in front of Android phones. Hear the full podcast at www.computer.org/silverbullet. Show links, notes, and an online discussion can be found at www.cigital.com/silverbullet.

Per-Olof Persson, currently head of global software security operations at Sony Mobile, discusses the importance of working in different positions within the same company—from directing the Sony Board to running in front of Android phones.
You've worked in many different roles throughout your career, from marketing to engineering to sales to project management to the board itself. What possessed you to take on software security at this point?
I've always been in favor of new challenges, and I truly believe that to get a sense of a company, even if it's a large one, you need to work in different positions. I got into software security because we really weren't doing a good job of it, and management asked me to look into it. It was a perfect fit, because Sony Ericsson—that's what it was called earlier on; today, it's Sony Mobile—went all in for Android, which is open [source] software. Previously, we had a closed operating system, which is very difficult to hack and not really that fun to hack, either, but Android shifted that. We had to move fast, and we needed someone with a contact network that included legal, sales, marketing, and developers. I had that network.
A lot of people believe (incorrectly) that software security is only about technical activities, but being able to bring all the parts of a huge organization together and harmonize them in the name of product security is just as much a political job as it is a technical one.
I completely agree. In the olden days, anyone interested in software security was seen as the guy who wanted to stop or ban everything—maybe he even locked himself into a strange [antisocial] building somewhere. In my world, we work with developers daily, talk to them, help them, and encourage them to have a close relationship with legal, so they can see that our paperwork isn't sloppy. It's not easy, of course, because you don't want to be seen as a bully, paper-wise, either.
So, yes, the contact network is essential, and I would say that two-thirds of my day goes into synchronizing. If you want developers to avoid dangerous programming functionalities because they lead to open holes, or well-known vulnerabilities, it's easy—just explain to them, "This has happened before. It will happen again if we do it like this."
Let's talk about the software security initiative that you built and evolved over the past few years at Sony Mobile. Specifically, let's talk about measurement, tools, technical activities, and political concerns, which we've sort of addressed already. As an executive, for example, how do you measure progress in software and product security?
We tried to determine as much as we could about what to do, how to do it, and how to get on track as quickly as possible. We found this guy called "Gary something," and thought, "Hmm...he's writing quite a bit." So we downloaded and read your BSIMM documents [ http://bsimm.com], and we read the Microsoft document, and we thought, "This is really cool stuff!" Some of it is maybe too much, but we liked the general idea, so we worked with it. We could also see that it wasn't going to happen in an afternoon—it'll take time, but that's fine. Next, we had to figure out how to measure, so we read that companies had been evaluated, and I thought, "Yeah, if we get evaluated, they're going to evaluate me, and it's going to say that I'm doing a lousy job."
But then we had this business trip to Orsay in February one year, and I asked for a meeting with you guys. We decided at that meeting that I should ask my management to use BSIMM for our company's future in software security. I'm very proud of that decision because sometimes you turn a blind eye, you don't really want to see everything that's going on, but having a third party changes things. You can guess how nervous I was the first time you guys came around and started asking questions about my team, legal, sourcing—oh, it was a nightmare. But everyone should be concerned about software security because, as you said, in some sense, it's everybody's job.
The hard part is getting the nontechnical people to understand their impact on a product security situation, which, as we've discussed, is probably two-thirds of the battle. What did you do to think about tools and technologies that you could adopt quickly in your initiative?
We had a couple of tools in place, but we also saw that there was some opportunity in the marketplace, so first we utilized the tools we already had—the code analysis tools. We rolled everything on every line of code that we developed so that we at least got that straightened out. Next, we looked into other tools that we could try out to see if there was anything better in the outside world. Few tools worked, so that was quite easy. We also tried to look into additional types of tools, but the further away we got from the basic tools, the more difficult it became: we have a Linux kernel, and some of that code is so old that no one really knows who built it or why.
And that brings us directly to the political concerns of software security. What does Sony's board think about software security?
It is, of course, rarely a topic for the board's discussion, and if it would have been, I would have been fired because that would mean I'm not doing my job correctly. But we have a communication channel from my office to management, so when we have "incidents," as we call them, which happen more or less daily nowadays, we try to keep management informed about the incident-handling process. All the people in top management positions have personally asked me to make sure that they're on the list of internal and external communication, especially anything press related.
They obviously have some understanding of the importance of product security. Let's talk about the cultural challenges that arise in working with development teams in Sweden, Beijing, Tokyo, and beyond. Surely there must be some different aspects in the way the same developers approach their jobs in these cultures?
Oh, yes, and you can't change culture, because it's the culture of a nation, it's the culture of the individual. What we try to do instead is to understand the culture and the thinking, and adapt some of our processes and ways of working to that. We have a minimum basic thing that goes everywhere, but how we then adapt it is a bit different across these different countries.
So you adjust the scheme according to the local situation?
Yes. You shouldn't try to change the nature of a human. You can encourage them, but you can't change them. You should take the best of the way we are as humans.
I'm sure that you have more than a handful of vendors at Sony Mobile. Tell me about vendor management and software security.
This is becoming more and more important as the vendor list gets longer and longer, as we expand business from cell phones to you name it in the future. And that, of course, means that we need to have a controlled situation in all aspects of the business. The picture is extremely big, but if you look at it from another angle, it's quite clear that as with everyone else, our business is going through the same process, so the same vendor we use is a vendor to someone else as well.
What impact does the app model for Android have on vendor management?
That's not my biggest concern because it still has a control barrier in some sense. There are dangerous things in that area, too, but I'm more concerned with the developers who are building things into products. They're much more part of our system. Of course, I'd like to have better control in that area, too, but...
...that's not number one right now, the app model?
No.
I think most people in computer security misunderstand this when you're talking about mobile, so it's a good thing to emphasize.
If you ask a CEO what does he see, he sees all these apps on the Internet and says, "Oh, scary." That's understandable because he isn't into the code itself. It's not his job, but he downloads apps and thinks, "Oh, if this app says it's my bank, and it isn't actually my bank, then it's going to steal my money." And he's correct on one level—fortunately, there are control mechanisms in that area. But what if someone gets to the inside, to the code—how do you handle that?
Let's talk about speed, market, open source platforms, and agile methodologies. I bet all of these things make your job way easier, right?
Oh, yes, absolutely. We get 20 million lines of new code from Android twice a year on top of the existing ones. We add on 5, 10, 15 new products on that baseline of code and 10, 100, 1,000 new features, depending on marketplace and customer, do them in 80 languages, and sell them in more than 100 countries. Oh, and the lifetime of our product is 12 months.
Consumer products come and go in the blink of an eye, yet they also last forever. I'm sure that you get people calling up for support on some ancient device that's maybe even two years old. How do you deal with that?
We have to deal with it because that's a legal requirement, so we actually upgrade software on phones that we don't sell anymore. You can guess how many motions we try to upgrade with incident handling a year. This is the normal demand.
I can only imagine. The other thing about the speed of the market is that things can go south very quickly, especially with a security incident. Does that make software security even more important? Is that a factor that you even think about?
Yes because it means we have to be more precise in what we do. We have to be very clear about the consequences of what we allow and what we don't allow, without being that guy who says "no" to everything. We're increasing the workforce and the number of people on my team gradually, so the company is very aware that this is important—it could save us from a horrendous story in the media.
What's the biggest thing that worries you now about software security and keeping the initiative momentum that you've built so far going?
I think the biggest challenge is getting everything integrated, so that your phone book is integrated with your GPS, which is integrated with some video streaming that you want to do, which is also integrated with some of your friend finders, and so on. All of this is communicating within the product, with other products, and possibly with a cloud-based server and a couple of different providers. There are a lot of security concerns as well as privacy concerns. Extra integration is fun for the user and becomes something you can't live without after a while, but making sure that it's good enough from every angle or a little bit better than good enough is my biggest concern right now.
If you think about the development model, the way that you communicate between processes and even sections of the operating system, it differs between Android and Apple's iOS models, and Android allows for more cool things to happen, but it also gives you a little bit less control as a developer.
Exactly, and we want to be seen as the best company in software security for Android. That's what my management constantly tells me, "Always be number one, Peo, and if not, why aren't you fixing it?"
The Silver Bullet Podcast with Gary McGraw is cosponsored by Cigital and this magazine and is syndicated by SearchSecurity.
Gary McGraw is Cigital's chief technology officer. He's the author of Software Security: Building Security In (Addison-Wesley, 2006) and eight other books. McGraw has a BA in philosophy from the University of Virginia and a dual PhD in computer science and cognitive science from Indiana University. Contact him at gem@cigital.com.