Gary McGraw: This is a Silver Bullet Security Podcast with Gary McGraw. I am your host, Gary McGraw, CTO of Cigital and author of Software Security. This podcast series is co-sponsored by Cigital and IEEE Security and Privacy Magazine, where a portion of this interview will appear in print. This is the 122nd in a monthly series of interviews with security gurus and I am pleased to have with me today, David Nathans. Hi, David.
David Nathans: Hey, Gary. How are you doing?
McGraw: David Nathans is a security professional with Siemens Healthcare focused on medical device security. Mr. Nathans has a long history in security operations and SOCs. Having written the book Designing and Building a Security Operations Center in 2014. Past work includes defense manufacturing with what is now Leonardo (once Finmeccanica), retail at TJX, helping to clean up their mess, and security operations at Verisign.
Mr. Nathans is a sought-after speaker at security conferences. In fact, we met at an Italian military conference in Pescara some years ago. He draws on his experiences as a Cyber Operations Officer for the U.S. Air Force and NATO, and as an original member of the first cyber squadron of the Air National Guard. He lives in New Jersey with his wife and his three kids. So they’re outnumbered by kids. Thanks for joining us today, David.
Nathans: Well, thanks for having me, Gary. This is exciting to be talking to you today.
McGraw: Let’s start with security operations. What are the top five things to think about when you’re designing and building a SOC?
Nathans: Oh, boy. Well, first and foremost, you have to think about what is the objective of the business. Obviously, if you’re building a SOC for an enterprise, what are the protection goals that the organization is looking to achieve? Then you kind of figure out how to build your SOC around achieving those goals. That’s certainly first and foremost.
Then certainly looking at the technology that you have to bring in to make those goals a reality. Then you need to think about the training and the staffing requirements that you’re going to need in order to be successful in meeting those goals. Pretty much everything else is going to be secondary; looking for efficiency gains and certainly key performance indicators after that. But ultimately, you need to focus on what the goals are and make sure you’re doing those.
McGraw: So is the standard approach to know about the business, and don’t forget the business part, while you’re building security around that?
Nathans: Yeah, I mean, I wouldn’t say it was standard. I think a lot of times when we think about security, it’s batten down the hatches, close the internet off as much as you can, and you know, pray. I think a lot of people forget about the business, right? I’m a business guy that learned security, and you have to think about what does the business need to be successful? And unless you’re in the security business, it’s not security. There are other functions that the business needs to focus on in order to be successful and make their money. You can’t get in their way.
McGraw: Yeah. Sometimes people overdo it from a tech perspective, or they overdo it from a (not really managing risks, but just piling up gear) perspective, I suppose. You’re caution is to do that the other way around.
Nathans: Right. Or you want to stagnate the company because you’re not sure of the security implication of something that you’re going to be implementing. Like when people were moving from “secure Blackberry” and they wanted to bring in these new funny, smart iPhones thingys. What does that mean from a security perspective? Let’s stop and let’s think about how to do that, instead of charging forward and figuring out what’s going to enable the business, and then building security around that enablement.
McGraw: You think the latter is the way to go?
Nathans: Yeah, absolutely. I mean, you want to be part of the success of a business, not the thing that’s going to bring it to its knees and cause it to stagnate.
McGraw: One of the major challenges in the SOC world is monitoring and protecting lots of broken stuff. So, a couple questions. Why is all the stuff broken? And is there a better way?
Nathans: I think so. I’m not sure that everything is broken. I think there are lots of starts and stops with implementing technology. I think there are lots of great tools out there and SOCs are implementing great technology. But you don’t necessarily get more than 10% of the product deployed, so it’s not really able to see its full potential.
Sometimes we’re racing around, trying to complete tons of projects, as opposed to just focusing on one or two a year and being really successful with that one goal. So I think it’s more of a broken process or broken promises really in what can be delivered with the technology. Certainly there is broken technology. I’m not going to say that there isn’t. But if you’re going to make a commitment as a business to buy technology, you have to make a commitment to then implement it to its fullest potential.
McGraw: That makes sense. I wasn’t really thinking about the gear that makes up the SOC, as much as I was thinking of all the stuff that the business relies on that was probably not designed with security in mind or was built in an arbitrarily terrible fashion. You still have to make that stuff operate inside the business and keep track of what’s going on, even though that stuff inside your perimeter may be busted.
Nathans: Yeah. You’re absolutely right. You’re playing whack-a-mole when you’re looking at operational security from an enterprise perspective. There’s all this stuff, and nobody buys products because they think it’s a secure way to do something. They’re buying a product because they think it’s going to help their business or it’s going to make their lives better. Security is probably not even a second or third thought in their mind.
So the operation centers are running around crazy, trying to figure out how to secure all this crazy stuff. That’s one of the reasons why I’m more focused on the product side now, because I’m thinking, you know, if I was just buying stuff that was inherently secure, then I wouldn’t necessarily be playing whack-a-mole.
McGraw: That’s an important realization and I was going to come around to that. Let’s talk a little bit more about operations at the intersection of security and continuous integration, Agile methodologies and Internet speed. There’s this thing called DevOps now. What are you opinions about DevOps approaches to building and evolving systems?
Nathans: Well, you know, I think it comes down to that we’re never ever going to be able to hire enough security professionals to secure all the stuff that we’re buying. What we need to do is evolve and make everyone a security practitioner in one way or another. Whether you’re an accountant, you’re R&D, or whatever your role is, technical or not, you still need to think about the protection of a company and all the things that you do and how it affects, positively or negatively, the security of that company. I think that what we’re seeing in DevOps or DevSecOps is really just sort of a maturity of that, where we’re really starting to think about security in everything that we do. It makes sense. If we’re not all working together, we’re going to just tear each other apart when it comes to security.
McGraw: I guess it sort of makes sense, but should Dev be capable of re-configuring firewall rules? What do you think?
Nathans: I think it depends on whether or not it makes sense for them and their role and what it is that they need in order to be successful. Whenever I ran security operation centers, I never wanted to own a firewall. You know, the firewalls are a business conduit. I just wanted to be in the approval chain for the rules that were going in there. I wanted the results of the logs, so I can do some analytics.
I don’t need to own the firewall from a security perspective. So if there are firewalls that are important to the Dev team that they need to be successful, then have at it. Just include your operations guys or maybe some audit capabilities that may be a little bit smarter than you to make sure you’re not doing something royally stupid.
McGraw: What do you think is the state of relations between Dev and security when it comes to medical devices?
Nathans: I think it’s contentious. I’m not sure that that’s necessarily specific to medical devices. I think there’s a contentious relationship there in a lot of different industries, only because the development teams have been developing for many, many years, and now you’ve got these security wizards that are coming in and trying to tell them how to do their job better. That’s a terrible approach, and I think it needs to be a little bit more collaborative and a little more of a culture change on probably both ends to make the teams figure out how to work better and skip down the hallway arm in arm together.
McGraw: That doesn’t sound very German, the skipping down the hallways thing.
Nathans: You’d be surprised.
McGraw: Nice silence there. That was good. So do you think we’ve made progress in the last decade with software security from your perspective—you know, sitting in a SOC, and designing, and building, and running SOCs. Have the software guys been giving you better stuff than before? Or is it about the same?
Nathans: I think from the SOC perspective it’s really hard to have that visibility, only because you’re chasing the latest zero-day or the latest variant of ransomware. So if you’re looking at the development techniques of the bad guys that are out there, then absolutely. There has been tremendous progress. They’re doing a great job.
You know, it’s difficult because, again, from the SOC perspective, it’s whack-a-mole. When you’re talking about the products that are out there and the evolution of products that are a little bit more focused like medical devices, yeah, I think there has been a tremendous amount of progress. But that doesn’t say very much, going from one to two is twice as much, but you’re still at two. So there is still a really long way to go. We’re still dealing with tons of legacy devices that are out in the market place.
McGraw: Yeah. Let’s talk about medical device security for a few minutes. So what do you think about the state of the field now? And what are your thoughts about Archimedes, the conference that we just attended that Kevin Fu runs at the University of Michigan, and what that told you about the state of the field?
Nathans: We’re doing a lot of preaching to the choir, unfortunately. The people that go to those conferences are probably the people that get it and would like to try and do something about it, but it’s the people who aren’t at those conferences that we really need to reach. So I think we’re talking to the wrong people. It’s something that I mentioned at the conference. We need a much bigger outreach. It’s a good question and it’s a good problem that I don’t know if anyone has really figured out how to solve. But certainly the evening news helps when you’ve got large medical related organizations that are getting hit with cyber issues and then now we kind of go back into our little worlds and say, “Hey, is that going to happen to us? What can we do to prevent it?” So those are good conversations to have.
McGraw: So awareness is moving, but we’ve still got a long way to go with regard to building security into those things.
Nathans: Yeah. Anything that rolls off the production line today as a medical device is going to be in play for five, seven, ten years. So if we put our best foot forward today and we have all the widgets and the great and wonderful things we think should be there and we put it out into a hospital environment today. Is it going to stand the test of time?
McGraw: Yeah. That’s a really, really interesting question. I remember working on the EMV stuff, the chip card stuff that everybody has in their pockets now (finally) in 1997. And we did a pretty good job with security in 1997. But I can assure you that we were not anticipating the kinds of threats that we see today in the design of that system. How do you design for security when the device lifetime is about a decade or seven years? Should there be some sort of retirement for devices over some period of time or designs? Should there be a half-life?
Nathans: Sure. I think with medical devices, there’s a little bit of a luxury that the community needs to take advantage of. We’ve got clinical functionality that makes it a medical device. That functionality does not necessarily need to be tied to IT. If we can decouple those two things—if we can have a robot that moves test tubes, if we can have a meter that checks glucose, and it’s not tied specifically to the IT, but it’s tied to clinical functionality and we can make that IT component modular, then I think we’re really going to be on to something. We can just replace that IT component. Or we can deploy that IT component at the risk level of the organization that’s deploying it.
That’s a hard situation. From a medical device manufacturer, who do we create a device for? Is it for the big organizations of the world that really get security and have tons of controls? Or do we make it for a Third World country provider that has zero internal controls?
McGraw: Right. The world is moving in different directions at the same time. That is, you know, all the clinics in the world don’t want to have 20 separate devices alarming at them and beeping incessantly. I don’t know if you’ve ever been to a critical care facility where there’s just beeping, just incessant beeping. Part of the idea is to have these things talk to each other and collaborate in terms of alarming. But that means they’re talking to each other. So that runs counter to the idea of let’s secure them off. Let’s make a lab facility that’s its own thing, or maybe not. But it’s a challenge, for sure.
Nathans: Yeah. And there’s no such thing as a private network. I think that’s what a lot of the medical organizations out there have deceived themselves to think—that I can have a protected off-the-grid network, and it’s just not true. Especially with electronic medical records these days. They have to be able to communicate. It’s mandated. It’s government mandated at this point. How do we do that, but maintain the organization’s risk profile that they feel comfortable with? The only way that I think that we can do that is, again, decouple the clinical functionality, especially in my company. I mean, that’s what we’re known for. We have stellar clinical functionality, but we’re not an IT company. We’re a medical device company. So how do we separate the two? And let the purchasing organization handle the IT in a way that they know how to handle. Let their SOC monitor it.
McGraw: So do you think that security can be a market differentiator when it comes to hospitals and those service providers, trying to pick which devices to use? Are you aware of it ever having been a differentiator, a deciding factor in the choice between devices?
Nathans: Yes, of course. I mean, it’s all about the total cost of ownership. So if we go in with a device that is clearly cheaper and provides the results that an organization is looking for—but it’s going to be twice as expensive to install into their infrastructure because of security concerns—then we’re not going to make the top of the list.
McGraw: Right. So you have to balance that out. But you can also say, I was looking for the other sort of question here. Our device is more secure, therefore you should buy it because security is important to you. Have you ever seen that?
Nathans: No. I don’t think so. I think we’re not even getting, or in some cases, we’re not getting a seat at the table if the devices are not up to a specific standard, or a specific level, or if it’s known to be insecure. For example, if we are bringing a medical device to a customer and it’s running outdated Windows XP, it’s just off the table. And that’s the way it should be, right? Customers should be making those types of decisions when they’re purchasing, because it forces the medical device manufacturers or any manufacturers to go back and think about how they’re developing these products, and how they’re laying their software down onto the operating systems, and then taking it to market.
McGraw: And also how they assure security claims, because frankly, just between you and me and all the 30,000 people who are going to listen to this episode, the idea of just doing a pen test to determine whether or not a medical device is secure is pretty darn silly. Sure, pen testing has a place, and pen testing has a place in the final environment as well. But there are other things that need to be evident from proper design, to proper coding techniques, to turning off the debugging stuff on chips, and using cryptography properly. All those things are things that can’t be simply tested with a pen test at the end of the life cycle.
Nathans: Right. Oh, by the way, uninstall all of your tools that you needed to make the device in the first place before it goes to production.
McGraw: Yeah. Remember that one guy who was giving a talk about looking around at the security of a medical facility and most of the problems were caused by the security tools that they had installed in the first place to look around.
Nathans: Right. Or, let’s not make things easy for ourselves and just make everything run as root. Then we don’t have any problems.
We’ll be right back after this message.
If you like what you’re hearing on Silver Bullet, make sure to check out my other projects on GaryMcGraw.com. There you can find writings, videos, and even original music.
McGraw: So I want to do another gear shift on you and talk about some military stuff for a minute. What are your thoughts about cyber warfare—offense and defense—and the notion of using information systems in war?
Nathans: I think we’ve been doing it for centuries. It’s nothing new. It’s just now we have zeros and ones, opposed to people looking through a pair of binoculars and stealing enemy positions and then relaying that back. It’s nothing new. It’s just a different medium, and it’s going to happen. It’s just a way of life. The problem that I see, from a military perspective, is that the attacks are happening inside of the military supply chain. So it’s not military to military. It’s the commercial sector that’s really being victimized by a lot of what’s going on in the cyber warfare.
McGraw: Right. And you think that’s just preparation stuff? You know, rooting boxes and getting prepared for war in the future?
Nathans: I don’t know if it’s preparation. I think the fighting is, in a lot of cases, it’s already over. The victims just don’t realize it or they haven’t seen their products come to market in different countries. There are lots of people that are already seeing that. They suffer a breach and then all of a sudden they lose their competitive advantage because some other country has reproduced their product. That happens. It’s a reality today.
McGraw: Right. In terms of IP protection, you’re talking about.
Nathans: Yeah. Or that companies don’t have to do R&D, they just steal it and away you go. So it’s a lot more cost effective to steal it. When it comes to the military, we’re already seeing some of that. We’re not the only country in the world that has an aircraft carrier or a stealth plane and how does that happen?
McGraw: Yeah. I guess, thinking about the security of the things that we’re building to carry out war is another aspect of it. It strikes me that one of the perspectives that could probably use some adjustment in the military is this over-emphasis of security operations, and having a SOC, and watching the network, and looking for attacks, and thinking about things like intrusion detection, extrusion monitoring, and all that stuff. And not thinking enough about building systems that just can’t be attacked with a simple software vulnerability. Do you agree with that assessment?
Nathans: Yeah, absolutely. But again, that’s pushing those requirements down onto the commercial supply chain because the government doesn’t really make anything these days. There is no more GOTS (government off-the-shelf). They buy commercial. So they have to push those requirements. And they have pushed a lot of those requirements in some places, but it’s industry specific, too.
The government buys medical devices. They buy command and control systems. They buy weapons. And they have to meet those requirements through all the different supply chain mechanisms that they have in place to make sure they’re secure. And it’s not just the prime contractor. It’s the 30 odd subcontractors that that prime is using. So it’s a massive supply chain issue.
McGraw: Yeah. I think we can bring that back around to medical devices, too. I think vendor control and even open source software control play a really important role in medical device security these days, and it’s something that we’re just now beginning to think about.
Nathans: In the government, specifically the military, there have always been different industries that were kind of hands-off from a security perspective. Medical was definitely one of them. Who would ever want to hit a hospital with a cyber attack? That’s just silly.
Again, it’s a lot of the military concept of “Can I click a button here today which causes death half a world away?” That’s sort of the holy grail. But really, what it is is that we’re getting killed financially and economically because we’re losing our R&D to a lot of these cyber attacks, and we’re losing money hand over fist. You know, we can start talking about a lot of conspiracy theories, but there’s a lot of foreign entities out there that are buying real estate and where are they getting that money from?
McGraw: No conspiracy theories on Silver Bullet, buddy!
Nathans: You know, the other issue about government and military is that the focus is very different. It’s very, very different. They want to know who’s attacking them. There’s a huge effort for attribution, and I don’t really think that has a place in an enterprise environment. You know, when I look at securing an enterprise, I really don’t care who’s attacking me. I mean, certainly I want to know about tactics, techniques, and procedures so I can have some predictive analysis. But at the end of the day, it really doesn’t matter to me who’s on the other end of the keyboard, as long as I can stop them. But in the military perspective, it’s different. They want to know who that person is at the keyboard and they want to go after them.
McGraw: Right. Yeah. And attribution is a problem that we haven’t really solved. I mean, short of having human intelligence, I think that attribution on the net is extremely difficult and some of the claims about attribution that have been made, even in the last five years, are a bit overblown in terms of “Oh well, we saw that code snippet before once over there, so it’s definitely those guys.” Where everybody knows about that code snippet. Even our enemies know about that code snippet, for example.
Nathans: Yeah. And a lot of times the enemies are obfuscating themselves by reusing code, for that point. I think it has its place, just probably not in an enterprise environment. There’s probably a lot of other better things that we can do with our time and our money by, like you said, building a secure product from the beginning.
McGraw: I totally agree with that, as you know. I also think that related to that notion, the idea of active defense (or attacking back your attacker), is something that the enterprise should avoid at all costs. I don’t like to see even the concept that, say, Oracle could go attack some foreign country because they were being attacked. That’s just a super bad idea.
Nathans: Yeah. I mean, I like to go walking in the woods every now and then. I see a snake. I’m not going to pick up a stick and poke it. I don’t want to know if it’s breathing or not. I really don’t care. I’m going to walk away. Same thing in cyber.
McGraw: Fair enough. All right. Last crazy question. We’re both scuba divers, though I’m a total newb and you’re a certified instructor. So what’s your favorite dive? And what’s your most embarrassing diving story?
Nathans: Oh, geez. My favorite dive has got to be State Pennekamp in Florida. It’s a vast reef. They take very good care of it. You can dive it forever. It’s just a lot of fun.
McGraw: Where is that off the coast of Florida?
Nathans: It’s Key Largo, Islamorada area.
Nathans: Most embarrassing story has got to be: I decided to do a tank dive, a one tank dive on the dock in Martha’s Vineyard. I was told it’s a pretty decent dive, but I’ve got to get out before the ferry, and I didn’t. I was still there.
McGraw: So your dive flag was still up?
Nathans: Yeah. My dive flag was still up and there’s the 300 foot rule, and the ferry had to call the Coast Guard to say, “Hey, get this guy out of the water.” It was about half an hour and I’ll be honest with you, if I didn’t have to really use the bathroom, I probably would have never surfaced until later.
McGraw: Did you get a standing ovation by the 1,000 people on the ferry?
Nathans: I got some really, really mean looks.
McGraw: Well, that’s a good one. Thanks for sharing. It’s nice that it’s out on the internet now.
Nathans: Yeah. Don’t dive the Martha’s Vineyard Ferry.
McGraw: Well, thanks David. It’s been an interesting conversation.
Nathans: Yeah. Thanks a lot Gary. I really appreciate the time.
McGraw: This has been a Silver Bullet Security Podcast with Gary McGraw. Silver Bullet is co-sponsored by Cigital and IEEE Security and Privacy Magazine, and syndicated by Search Security. The March/April issue of IEEE S&P focuses on the IEEE symposium on security and privacy, otherwise known as the Oakland Conference. The issue also includes our interview with Root Kit expert, James Butler, aka Jamie Butler.
Make sure to watch Silver Bullet episode 120 which features me interviewed by Marcus Ranum—a celebration of a decade of these podcasts.