---
title: "Chris Romeo — The State of Security and the Importance of Empathy"
url: https://appsecpodcast.com/chris-romeo-the-state-of-security-and-the-importance-of-empathy/
date: 2020-08-27
duration_seconds: 2633
guests: ["Chris Romeo"]
topics: ["Threat Modeling", "Security Culture"]
audio: https://www.buzzsprout.com/1730684/episodes/8122594-chris-romeo-the-state-of-security-and-the-importance-of-empathy.mp3
transcript: true
---

# Chris Romeo — The State of Security and the Importance of Empathy

*August 27, 2020 · 44 min*

with [Chris Romeo](https://appsecpodcast.com/guests/chris-romeo/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [Security Culture](https://appsecpodcast.com/topics/security-culture/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122594-chris-romeo-the-state-of-security-and-the-importance-of-empathy.mp3)

## Show notes

Network engineers and application security teams depend on each other, yet often struggle to understand each other’s responsibilities. In this rebroadcast from The Hedge, Chris Romeo joins hosts Russ White and Tom Ammon to explore that divide. They discuss encrypted traffic, denial-of-service attacks, DNS, and the limits of relying on network controls to protect applications. Chris explains threat modeling as a repeatable way to question assumptions, including assumptions about cloud services and insider access. The conversation then turns to infrastructure automation, changing engineering roles, and the frustration created when security policies arrive without technical understanding. Their practical message is to learn one another’s language and build empathy through real experience with the systems other teams operate.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Chris Romeo:  
→ [Chris Romeo on LinkedIn](https://www.linkedin.com/in/chrisromeo-appsec/)

Mentioned in this episode:  
→ [The Hedge episode 48](https://rule11.tech/hedge-048/)  
→ [National Vulnerability Database](https://nvd.nist.gov/)

Chapters:  
00:00 Chris joins The Hedge to discuss security  
02:01 Where network and application security meet  
04:29 Encrypted traffic and network responsibilities  
06:04 Certificates, DNS, and interception threats  
07:51 Threat modeling as a way of questioning assumptions  
09:23 How denial-of-service defenses evolved  
12:23 Revisiting models as threats change  
17:45 Where network engineers can improve security  
22:21 Helping developers and application teams  
24:46 Routing, segmentation, and control-plane risks  
28:18 Insider threats and shared control  
31:11 Infrastructure as code and changing engineering roles  
34:51 Empathy between network and security teams  
39:39 Learning paths for network engineers

## Transcript

*8,391 words · assemblyai*

**0:00 Chris Romeo:** Hey folks, this is Chris Romeo, and I wanted to let you know this week on the Application Security Podcast, we're broadcasting an interview I did with a different podcast called The Hedge. The Hedge is run by a friend of mine named Russ White, who is a very well-renowned network architect and has written dozens and dozens of different books and is really someone that's seen as an expert in the world of network architecture. He asked me to come on and talk about the state of security, the state of application security, and then try to draw some connections between what network engineers need to know about security from an application security perspective. So, we hope you enjoy this conversation with, I guess, me. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo.

**1:24 Robert Hurlbut:** And today we're being joined by Chris Romeo, who's a good friend of mine, lives down here in the Raleigh area, and runs a company called Security Journey, which I'm actually a Security Journey white belt because I've been too lazy to get any of the other security journeys.

**1:50 Chris Romeo:** We're waiting for you to come and move on to the next level. So Russ, it's great to be here. Tom, great to be here. Thanks for having me. And yeah, let's talk about application security and networks.

**2:01 Robert Hurlbut:** Yeah. So what do you think is going on here, Chris? I mean, I know that we tend to, as network and security people, we tend to just throw the security problem over the cubicle wall.

**2:13 Chris Romeo:** That's true. Yeah, it's kind of, when you think about it though, it's kind of a bit of a struggle in that we don't have as much cohesion between the 2 focuses of security and network. And I think part of the challenge that happens there is I see, when I think about network these days, as somebody who focuses on the application layer, focuses on application security, I think of the network into this grouping called infrastructure. I think of infrastructure as almost like this magical thing that happens that gets the packets to where they need to go. I know how it works, but I don't really have to worry about it a whole lot. I think that's some of the struggle that we have here as network and IT professionals. application, and even security people is that we have this idea that the network is in an almost secure state because we've been dealing with the pieces that make up network security for so long.

**3:09 Robert Hurlbut:** Yeah, so the entire network is basically just a big abstraction. Then we have to remember the rule of leaky abstractions that all non-trivial abstractions leak and all those types of things that you run into with this that we don't tend to think about, right? We just don't tend to think about those things. So, so you see the network as largely secure. What do you think, Tom? Ah, okay, you can laugh. It's okay. I, I don't, I don't see the network as necessarily providing any security services, any meaningful security services to the application layer. I think there have been lots of valiant attempts to do that, but I don't— I, I think that ship sailed a while ago. And at least from my perspective and every place that I have been, the attitude is always, at least in technical leadership, application people are responsible to secure their own world and the network people secure their own world. And that's kind of, you know, where it stops, you know. But more and more network people are maintaining their own systems. They're maintaining their own controllers and their own compute for their own purposes and their own control planes. And so, you know, you could say that networking is starting to take a bigger role in application security because their own applications are becoming more complex.

**4:21 Chris Romeo:** Yeah.

**4:22 Robert Hurlbut:** So explain maybe a little bit, Chris, about what you think when you say that the network is secure. Like, what do you expect the network to do when you say, well—

**4:29 Chris Romeo:** When I think about how we use the network today from an application perspective, if you think about the level of TLS encryption that we have in all the communications that are happening right now, I mean, try to think of a service that you're using that's not encrypted right now. Maybe DNS. Okay. Yeah. Okay. DNS maybe, but there's things we can do to fix that. But think about, like, do you have an unencrypted mail client that's doing some type of communication from your PC today? I hope not. I hope there's no POP or some weird service you're using to read mail that's not over an encrypted channel. And so, when I think about kind of what the network provides, sure, the network is not providing security services to Layer 7-style applications, but when I think about how TLS and how encryption has become such a such a normal thing in how we do applications that there are certainly conditions that the network can bring upon us as an application. Distributed denial of service is the one that we all struggle with regardless of where we sit in the stack. Distributed denial of service is kind of a different problem from somebody being able to read the contents of your email, Russ, as it goes from an email server somewhere in the cloud to your local machine. I think TLS, and I think crypto have really done a lot to help us not need as much and not have as much reliance on the network for security. It's more of a utility that helps me ensure I get packets where they need to go.

**6:04 Robert Hurlbut:** How does that play into things like man-in-the-middle attacks and knowing for certain that the certificate you're using is the real certificate, like DNS security? You talked about DoH or securing DNS. Which I have my very concern, my big concerns about DOH for many reasons. But, you know, how does that, or even DOT, DOT might be better than DOH, by the way, but how do man-in-the-middle and stuff like that come into play? I mean, do you think about that kind of thing?

**6:37 Chris Romeo:** Yeah, I mean, of course. I mean, that is a class of threat that we've been thinking about, you know, since we started connecting devices together on networks. It still continues to be something that we have to think about. You mentioned a couple of things about certificates and proving that you're talking to who you think you're talking to. In the world of certificates and certificate authorities, we have root of trust. We have the ability, through cryptographic operations, to trace back to a root-level certificate to prove that we're actually talking to who we think we're talking to. Those types of attacks, kind of the Someone's in between point A and point B, and they're able to either redirect traffic or being able to access traffic. I mean, I think in the modern world that we live in right now, sure, you could do that type of attack to redirect traffic and maybe cause a problem from a redirection perspective, but being able to trick somebody into believing that they're actually talking to some popular website.com has gotten a lot more difficult. than it used to be before we had TLS everywhere and we had certificates and everything in full play.

**7:45 Robert Hurlbut:** Interesting. Again, does DNS play a part of that, do you think? I guess you probably do think that DNS plays a part.

**7:51 Chris Romeo:** Yeah. No, I think DNS is something that we have to continue to try to make more secure. I mean, I think that's still one of the weak points in the overall approach that we have. Yeah, we've got to be looking for better ways to to secure the DNS layer. But, when I think about what are the other types of threats? And so, for me, as someone who's been in the world of security for 20+ years, I've been around the network, but I'm nowhere— I'm not even in the same room with you guys when it comes to thinking about how networks work and configuring things. But, I know enough to be dangerous, which is true for a lot of different things that I have studied. But, when it comes to security and the way that we approach this, what we always have to be thinking about is, this thing called threat modeling. Let's think about what are the threats that we have to consider for any architecture. The beautiful thing about threat modeling is it applies to anything. You can threat model walking your kid to school. It's not technology-specific. What we have to do is we have to think about, okay, what are the potential things that could go wrong? Then what are the mitigations that we can do to apply that? We talked about DNS being a potential issue. I mean, we've got some protocol-related things that we can do to enhance and try and protect the DNS. transactions. That's going to be true, though, for any type of threats, any types of challenges that we encounter. There's always a mitigation that just comes down to, what's the cost? What's the level of effort to make that problem go away?

**9:19 Robert Hurlbut:** What's the tradeoff, essentially? What am I paying for to get there?

**9:23 Chris Romeo:** Yeah. Think about DDoS, for example, distributed denial of service. I worked for a company that you guys might remember called Exodus Communications back in the late '90s. I was on the security team. We had a whole giant network operations and network deployment. challenges we had at that point was distributed denial of service because, while we had content delivery networks, they were in their infancy at that point. I got the, I guess you'd say, the unlucky straw, drew the unlucky straw of being the interim director of incident response for about 6 months. In that period of time, I was yelled at by more CEOs of large companies than in any other time in the rest of my career, which I don't get yelled at by a lot of CEOs, but I had a couple of people on the phone with me that were just yelling at me because of this distributed denial of service problem. At that point, there was really not a lot we could do. Our answer was, we'll filter at the backbone level. That was the solution for DDoS. People were coming up with all kinds of new style DDoS attacks, and we were always chasing. It was always after they'd been down for 8 hours before we'd ever get filters at the backbone level to try to slow it down. But when you think about DDoS today, you've got to generate a lot of traffic to disrupt somebody. Good luck trying to disrupt a major e-commerce company. You can't generate enough traffic. I don't want anyone on the internet to think that's a challenge. That's not a challenge I'm throwing out to you, right? But think about the amount of traffic you have to generate to disrupt one of the networks that you build right now. What is it? For someone to disrupt one of your networks, what does it have to be? Is it gigabits? Is it hundreds of gigabits? I think it's more than hundreds of gigabits.

**11:03 Robert Hurlbut:** Well, there was this news story just the other day that I saw that Amazon absorbed, or was it AWS? I think it was. It absorbed the largest DDoS attack ever known. And it was like multi-gigabits. And it was like, well, whatever. I mean, yeah, it was there, but—

**11:19 Chris Romeo:** Yeah, I mean, GitHub saw one, I believe it was a year or two ago, 600 gigabits per second. It was a memcached bug. So Linux servers had this memcached service exposed all over the internet and some crafty attackers figured out a reflection style attack where they could send a little bit of traffic into a Memcached server and cause it to regurgitate a 100x amount of traffic, and they could spoof the source addresses to be able to do that. It was somewhere around 600 gigabits, but it didn't knock GitHub offline. It didn't shut down their business. They're still thriving and doing well. The point is, as the threats change, even something like DDoS, You can say that that's a network play, that's a caching play, that's a security play altogether. But, once again, that's an example of a threat that we've identified with all these focuses, all these teams working together. DDoS is not that big of a challenge like it used to be when I got started in security, I mean, where it would literally take you offline and there was no hope. We hope the attackers go away because we can't get the site back up.

**12:23 Robert Hurlbut:** Chris, I'm wondering, what do you think is the future of threat modeling then? I've gone through some of these exercises myself. How do you sort of look forward? Nobody can read the future, but is there a way? Yeah, what's your approach for looking forward to the next threat?

**12:42 Chris Romeo:** Well, I mean, part of it— so one way to think about threat modeling is this exercise is an iterative approach. New threats are always happening. I talk about this often when I teach classes and when I train people online through our platform, this idea of the threat landscape. The threat landscape is almost like a universe. We know the universe is constantly expanding. Well, the threat landscape is constantly expanding. Every day, people wake up, get out of bed, and decide, hmm, this normal job thing, it's not working for me. I'm going to become a cybercriminal. Right? There are folks that are waking up and coming to that idea. There are new attacks, new vulnerabilities found in services. The point is, This threat, the possible threats are ever-expanding, and threat modeling itself is really just a process. It's a way of thinking to be able to deal with whatever the threats are. And so, when I think about threat modeling, it's really the end goal, the next steps of this is, how do we get to the point where network people, security people, application people, everybody starts to think in this way? Because it's a different approach to thinking. If you think about how attackers are going to come after a network that you're building, you're going to be asking different questions of that network than if you're thinking about, how are we going to serve 100 customers coming inbound to the network per second or millisecond or whatever it is? When I think about where are the threats going and when I try to think about what are the challenges that we're going to face, I mean, I can't even attempt to predict what attackers are going to be coming up with in the next number of years, but when I think about historically, things haven't changed a lot since I started in the world of security as far as the classes of attacks. Buffer overflows still exist, even though the first one, or one of the early ones, was the Morris worm back in the late '60s that was kind of the first real security incident that has any amount of fame or any amount of publicity. We're still dealing with that problem here in our current year. Like, we haven't eradicated it. Another one that I always laugh about, and so in the world of application security, I don't know if you guys are familiar, there's an organization called OWASP, the Open Web Application Security Project.

**15:00 Robert Hurlbut:** Yeah.

**15:00 Chris Romeo:** It's a not-for-profit. It's volunteers all over the earth coming together and saying, hey, let's try and put information out to help people. The document they're most famous for is the OWASP Top 10. This is the top 10 application security risks that you have to be considering about from a web application perspective. And so they've done like 4 revs of this list. The first one I think was in the early 2000s, and then the latest one is 2017. The funny thing is the number one thing on the list, injection, hasn't moved. It's still there. It was there in 2004. It's still in the number one seat in 2017. And my guess is that when they put out the next one in 2021, it's still going to be in the number one seat. And so the, the point here is that we're not fixing the things, we're not moving things farther along fast enough for my liking. And so I don't even have to worry about the things of the future. I have to— I'm still worried about the problems from the early 2000s and trying to catch everybody up and all applications up from that perspective.

**16:02 Robert Hurlbut:** That's— I really like that idea. So one of the tools we use in networking for kind of keeping ourselves up to speed is this idea that once you figure out how the protocols work at a base level, the new things are just like the old things. They're just sort of repackaged. And that's something that helps network people kind of accelerate and learn things that are really fast-paced. I'm really glad to hear you say that, that the threats are still in the same classes because the same leverage can then be applied to the security world and you don't have to constantly relearn everything from ground zero. It seems like a true principle to me.

**16:35 Chris Romeo:** Yeah, and I totally agree with that kind of perspective. I mean, there's There are the attacks, the vulnerabilities, the classes of vulnerabilities. Sure, there have been some new things that have come up, but they can still be fed back into another category that other things fit into. The same is true for kind of the other side. I mean, as an industry, we spend so much time talking about the attack side. It's all about the breaking, the red teaming, the pen testing. I'm somebody that is here to say, we've spent way too much time focused on the attack side of this equation. We need to spend a whole lot more time on the defense and defender side of this. We don't need more people in our industry that can hack into any application on the planet. We need more people that can write code that takes away the vulnerabilities that that group can use. That's another, I guess, another of my hot-button issues, though, is like, you can't hack yourself secure. I've been trying to get someone on the Internet to argue with me on that point. I can't get anyone to argue the other side of the equation. Because nobody can tell me that they can hack themselves into a more secure state. They can break their applications and then, at the end of the day, they're more secure. It has to come back to that defender side.

**17:45 Robert Hurlbut:** That's interesting. Given that the network is kind of assumed to be secure from an application perspective, I mean, because things just are where they are at this point, how can a network engineer go about building it? Where are the holes still? Where do people see holes? What's going on? Where can network engineers look at it and say, hey, you know what? There still is a hole here, X, wherever X is. What does that hole look like?

**18:12 Chris Romeo:** I think the best source of figuring out where those holes are today come from the vendors who are providing the hardware and software solutions that you're using to build your network. There is a function that exists in some of these big companies called PSIRT, which is a Product Security Incident Response Team. I'm guessing a lot of the folks that are listening to this have probably seen at least something from one of those organizations because they're the ones that are putting out the notices that say, hey, we found this vulnerability and you need to patch your routers, your switches, whatever, to the latest version to eliminate this vulnerability that exists. When I think about the world of network engineers and the advice I would offer to them is, I would ensure that you are dialed in with the providers of your infrastructure and that, if there is a vulnerability that exists in one of those things, you are taking advantage of the information feeds that those companies provide. There are also public information feeds. The best one out there, it just happens to be a U.S.-centric— the Department of Homeland Security has what's called the National Vulnerability Database. It's referred to as NVD, is what people will call it. If you go to the NVD site, you can search all of the vulnerabilities that have ever been reported in history, and that is also where information about new vulnerabilities that exist in specific products gets dropped when those things come out. If you're a network engineer who's sitting there thinking, like, wait, this guy just described a scenario where somebody could announce a vulnerability and I wouldn't know about it, and I could be vulnerable in my network infrastructure for some period of time. The good news is the industry has adopted this thing that we call responsible disclosure. And so, responsible disclosure is an agreement between the security researcher who finds a security problem in a particular company's router, switch, whatever it is, and the company itself. And with responsible disclosure, both the researcher and the company are agreeing and saying, we're going to work together so that we don't drop what we call in the industry a zero-day or an O-day, which means a—

**20:18 Robert Hurlbut:** Yeah.

**20:19 Chris Romeo:** a vulnerability that gets announced and nobody knew about it and nobody had any fixes for it. And so then, attackers around the world are able to compromise everything that is running that version of software because nobody knew about the fix. So, responsible disclosure is where the researcher and the company, they agree to work together and they come up with a timeline that says, hey, we're going to get the patch out. The company can say, we're going to get the patch out to our customers. Then, we'll announce to the world and we'll point to you and say, hey, security researcher, great job! You found this issue. So that's kind of my thoughts, I guess, on the network engineer and what I would do if I was in their shoes.

**20:52 Robert Hurlbut:** So it sounds like you're saying, secure your own stuff, your own attack surface on your own boxes that you're responsible for. What about in behalf of applications? Is there anything there that you think ought to be done?

**21:06 Chris Romeo:** Specifically from the network perspective, I mean, there's really not. not a lot of things that I think about that the network actually needs to provide from a security perspective. The applications tend to do their own thing from an encryption and TLS perspective, from higher-level functions like authentication, authorization, things like that. I mean, I would think that one of the things that's just kind of coming to mind is kind of the, I guess, the virtualization, the separation. that the network can provide is something that I would like to maybe know more about and see how that goes. But I can tell you that the average developer is never going to get to that level of understanding of the network. The average developer is looking at the network as a, like I said at the beginning, a utility. This is a pipe that provides me access to the internet. Yeah, I mean, I think that's just the modern application developer. I know, I realize I'm stereotyping here, and so if you're out there and you're like, wait, I'm a developer and I can tell you the OSI 7 layers and I can tell you every bit that exists in each one, rock on. I'm not trying to be stereotypical. I'm just saying, based on my experience, the things I've seen in my travels.

**22:21 Robert Hurlbut:** Interesting. Yeah, so basically, I don't want to say just mind your own business, but on the other side, just try to— maybe is it just work with the— backing up a little bit, can you work more with developers in some way as a network engineer? Is there something you can do that would be helpful? I don't know. Is there? Or is it, like you said, pretty much just— We're just going to do what we're going to do anyway. Yeah.

**22:45 Chris Romeo:** I mean, I think some of it, some of it comes down to whether you're a network engineer who's responsible for kind of that infrastructure category that I talked about at the beginning. So like when I think network in this modern day and age, I think everything that's, that's not my application. So there are other pieces that are traditionally kind of in some organizations, network folks are going to be responsible for security appliances and web application firewalls and proxies and all those types of things. Then I know, in other big organizations, network folks are going to be just network because they have 5,000 routers and a giant backbone infrastructure. All the network do is think about kind of network. When I'm thinking about kind of that smaller, medium network engineer who might have responsibility for other pieces that exist in the infrastructure, like a proxy, which can have ramifications for the application, it can have some good things. It can also cause some problems.

**23:42 Robert Hurlbut:** Right.

**23:43 Chris Romeo:** When I think about even firewalls, web application firewalls, if that's something that the network is responsible for, dare I say network router access controls? I can't imagine anybody uses router access controls on individual routers anymore. You guys can correct me. I've been away from your world for a long time.

**24:00 Robert Hurlbut:** You might be surprised.

**24:02 Chris Romeo:** I probably would be. I have this dream. I have this view that the network has reached this point where You know, it's just inherently secure, and you guys are making me kind of rethink my, uh, my happy place here that I was in.

**24:17 Robert Hurlbut:** Sorry. Yeah, your happy place is not as happy as you think it is.

**24:20 Chris Romeo:** You know, I kind of— I, I got to tell you that the security person in me, I, I am always pessimistic. I'm always looking for the thing that's broken and the, the place where the hole is. And so, you know, I can tell you that I kind of knew that you were going to tell me this, that the network wasn't as good, because I just That's the security person. Like, we're always looking for the problem and we never believe something is working the way it's supposed to. So I had a hunch, but now you guys confirmed it for me.

**24:46 Robert Hurlbut:** Yeah. I mean, unfortunately, I don't think that in the networking world we tend to spend a lot of time or effort just building security in from day one. We just— it's just not there. We just don't. Like, I'll give you a very, very simple example. When I'm building a data center fabric, one of the things that I'll do is a lot of people today will use BGP for the data center fabric. I'm not a fan of BGP in data center fabrics. I think it's a horrendous idea, but it is what it is. It's what people are using. So I try not to get too freaked out about it when I run across it a lot. But what I was going to say is that when using BGP, how do you secure BGP in a data center fabric, particularly if you're running it on the host? This is something we just don't think about. We just toss BGP at the host and say, we'll just run routing all the way to the host. Yeah, and if your host is owned, then your overlay is owned or your underlay is owned. And all of that segmentation you were just talking about being something that the network can do to help you, it's gone.

**25:46 Chris Romeo:** So what does that mean? Yeah, yeah, I mean, that's, that's something that, you know, we were pushing for as security back in, back in when I was in my web hosting days, the idea of control networks and things that are truly physically isolated from things like BGP updates on an internal network. There's no reason anybody on the public Internet should ever be able to interact with the pieces you were just talking about. But, my sneaking suspicion is they can, that there are certain paths that allow them to at least try to modify and implement them.

**26:19 Robert Hurlbut:** Well, from within the network. I mean, I should be a little bit— I mean, for instance, if you are running a hyperscaler, like you're at LinkedIn or Facebook or something like that, their customized application does not allow you to get beyond, in theory, to get beyond where they want you to be.

**26:37 Chris Romeo:** Mm-hmm.

**26:37 Robert Hurlbut:** Right? But if you're running in a public cloud, I don't think you have the— I just don't think you're gonna have the security you think you do in these things. I just don't think the security's there the way people think it is. Part of that's just because the controls are very focused on whatever they're working on. They're not focused on the— I don't know how to explain it exactly, but I just don't think that those controls are the way people think they are.

**27:05 Chris Romeo:** Yeah, I think I would agree with that. A lot of times there's a false sense of security, especially with things that are that complicated. I have different kinds of data center experience, but I've One of the things that was always funny to me in talking about a kind of data center class product, I had some engineers tell me, well, we don't really need to worry about security because this device sits in the data center. That was their answer to me. They said, oh, it sits behind— it's far away from the public internet. I was like, that is not an assumption we can make. What I tried to teach them is the thing I still try to live by this. When you're building a product, you have to assume 5% of the people are going to plug the interface into the public Internet. Maybe they won't, but if you plan for 5% of them to do that, you're going to build your security architecture in that product a whole lot different if you have to worry about the public Internet being part of the threats that you have to consider. Yeah. Yeah.

**28:10 Robert Hurlbut:** Well, and that's true for insider attacks as well. We just don't think about insider attacks very much. We just think, you know, how bad can this be, right? But it can be bad. Trust me.

**28:18 Chris Romeo:** Yeah. No, I mean, insider attacks are the— that is the part of this whole security world that we all know the risks, we know the challenges, but we hardly ever think about. We still, as an industry, hyperfocus on the outside coming in. We don't even think about, from a controls perspective, how are we protecting our network infrastructure, for example, from our network engineers? It seems kind of like a crazy thing to do, but should you require 2 people to do some high-level function that could potentially take out your entire network, shut your entire network down? I think the answer is yes. I think no one person should have the keys to be able to turn off the backbone, just using a really generic example. But I think a lot of times that is what happens, though. I think we don't have controls built in such a way to prevent that type of a threat from happening.

**29:13 Robert Hurlbut:** The funny thing about that is we have the tools, right? I mean, you can run a network infrastructure. I know this is possible. You can run an infrastructure as code, and you can use all the tools that have kept a single person from knocking the whole thing over. that can be used for networking. It's not common, I would say, in the industry today, especially looking at enterprise networks, but you absolutely can do everything with 2 approvals and use Git, use GitFlow, use whatever, but the tools are there. The thing that I think is missing is the incentive to use them. The other thing that I think is just going back to the insider threat, I mean, if you walk into the lobby of of the Fortune 500 and plug a cable, plug an Ethernet cable into a wall port that you see there, I bet you the percentage is a lot higher than where you're comfortable admitting that you can get access to a significant amount of things. So if it's like, oh, we'll focus on the perimeter, well, you know, it's not quite that simple, I don't think.

**30:13 Chris Romeo:** Yeah, and that's always been one of the biggest challenges for any company and any, you know, any infrastructure that they're trying to protect. is you have these buildings where you let all kinds of people come in and out every day. Some of them work for you, some of them have badges, some of them don't because they need to be there to fix things. That's always been one of the kind of juicy attack surface pieces. There are lots of stories about different testers and the escapades, the hijinks that ensue when they try to get into a building. But, you hardly ever get to the end of one of those stories and they say, you know what? We just couldn't get in. They always get in somehow. I've heard some where they're cloning badges, for example. If you have really cheap RFID-style badges, if you get within 5 feet of somebody that has a cloner, it'll make a copy of your badge, and then they can create their own version of it and then just show up and scan in as you at 2 o'clock in the morning.

**31:11 Robert Hurlbut:** Yeah.

**31:11 Chris Romeo:** That's the threat. I'm curious about, Tom, you mentioned about the infrastructure as code. Do you think one of the reasons that hasn't taken off as much is that we have a large percentage of engineers, network engineers who are out there? We have a lot of people, and I feel like infrastructure as code, just like we've seen in the world of DevOps— I don't know how familiar you guys are with DevOps, but there used to be a lot of people called testers in the world, and they don't exist a whole lot anymore.

**31:36 Robert Hurlbut:** Right.

**31:36 Chris Romeo:** You're either a developer or you're someone who runs infrastructure, but we've seen that kind of test grouping of people kind of almost evaporate. I hate to use that word, but like that role has just kind of disappeared. I'm wondering, if we go infrastructure as code, does that same thing happen to the network engineer who's used to booting routers, loading software, and making config changes?

**31:58 Robert Hurlbut:** That's the million-dollar question in the industry right now, right? What happens when the industry decides that this new tooling and this new way of operating, whenever that happens, what happens to the old guard? I don't think it's as catastrophic as that. I don't think it's an evaporation necessarily. I think it will follow other patterns. Like if you look at the way traditional telephony, kind of the course that it ran, you know, a lot of people started out using butt sets and doing stuff on telephone wires. And then as Voice over IP came along, some of them said, I need to get with that. And some of them said, you know what, I'm just gonna retire. I'm retiring in a couple years. Like, I'm just gonna get along until then. And then some people came the other way. Like a lot of network engineers went and said, you know what, this voice stuff is pretty cool. And so they stepped into the new world. I think we might see a similar evolution. I think you might see some people who are like, look, I got 5 years left. I am not gonna go learn how to do Git and Python and all this stuff. And then you have other people coming from other disciplines, I think, to fill in and say, you know, this networking stuff's pretty cool and there's this vacuum now. So maybe I can go do that. I don't know, it's just my thought on it.

**33:06 Chris Romeo:** Let me make an advertisement for security people. So if we got network engineers who feel like you need a new role, There's this thing called cybersecurity that's— there's a few openings in the industry, literally. It doesn't matter who— like, some people, some pundits say that there's not such a big divide of people that are not there to fill jobs or whatever. I'm here to tell you, there's a lot of open jobs, and I play specifically in the world of application security. I'll tell you this, I don't have any friends that are out of work right now, and if one of my friends does end up out of work, They go to the next job on Monday. They leave on Friday and they go to the next one on Monday. So, there's a lot of demand for cybersecurity in general, application security in general, and especially for folks that are coming from a network perspective. That's a crucial piece, and I just want to touch on that for a second because I keep saying a lot of developers, they kind of think of the network as utility and they don't really understand how it works. As a good security person, you have to understand the network, you have to understand the operating system, you have to understand the application. It doesn't mean you have to be an expert at all of those things, but the best security people I know can talk on all 3 of those kinds of tiers. They understand enough about the network to ask the right questions. They understand enough about operating systems to ask the right questions there. Maybe they specialize on the application and that's kind of the piece they know, but I think there's a lot of opportunity for for people to enter the world of security. I think people with a network mindset could add some operating system, and they may even already have some knowledge of that, and then study and add some security pieces. I think that network foundation is an interesting place for somebody becoming a cybersecurity engineer in the future.

**34:51 Robert Hurlbut:** For me, who plans to stay a network engineer, I would actually love it if the security people that I interface with regularly could speak a little bit more of my language. I feel like there's a lot of sometimes even interpersonal challenges that are created because of the chasm there a little bit. I've seen some network engineers get super frustrated with security engineers because the security engineers don't know what they're talking about, yet the security person has this policy hammer in their hand. So the network person's like, you don't understand and you're going to hit me with this policy hammer. and you're not listening to me. And the security person's like, what you're saying makes no sense. So here's the policy, follow it. And, you know, if the security people could understand a little more of our world, if we could understand a little more, you know, I think a lot of, maybe even a lot of the breaches that we've experienced could, I don't know, maybe be avoided. I don't know. What do you think about that?

**35:44 Chris Romeo:** It's only gonna get better. And so you've touched on something here that I've started to call developer empathy. In the world that I live in, there are a lot of security people that think they have the policy hammer that I can swing at the developers and say, no, this is how we're doing it because I'm from security. I don't think you understand. I'm from security. I have this giant 200-page document that I'll drop on your desk if you don't do what I say. All that does is breed developers who don't want to talk to security people. I'm trying to get this term developer empathy, but I think it applies to— I think you could say network empathy as well. I want to see security people who say, I'm going to walk a day in the shoes of the developer so that I can understand the challenges they have. I'd love to see the same thing from a network perspective. I would love to see security people saying, hey, Tom, I want to shadow you for a week because I want to understand the challenges that you have. I want to understand the challenges that I'm creating for you as a security person. I'll give you an example of this. On the developer side, one of the things we do at Security Journey, we have our own cloud-based platform. It's a web-based app. I've been involved in building it with a number of other developers. I had an interesting situation happen. We had a vulnerable piece of third-party software. We had a tool that detected it while we were building it. I was sitting there going, hmm, I can't push my new version of code to production because of this third-party vulnerability. Now, I have to either go deal with it or I have to filter it out of the tool. I'm thinking, I have told people in this exact situation, there is no way that you can push to production at this moment. You have got to go fix it. All of a sudden, my eyes open because I'm like, I'm walking in their shoes and I'm seeing— I am now on the other side of the table. I'm realizing I still need to push this version to production. I need to get that vulnerability fixed as quickly as possible. But, I can't stop developing, moving code out into production as a result of that. That really opened my eyes and really made me start thinking about developer empathy. I'm going to extend it. I'm going to say, let's call it network empathy as well, and maybe even security empathy. Maybe that's when network people are saying, I want to understand security people, because, like Tom, you said, when we all get together and talk and start to actually work through things, you can't tell me that doesn't make a better workplace, a more secure environment, a more performant network.

**38:06 Robert Hurlbut:** Yeah.

**38:07 Chris Romeo:** You can make a long list of the benefits that come out of that.

**38:09 Robert Hurlbut:** Right. And on the flip side, I have also worked with some really excellent security people who already have figured out— and my guess is the common thread is the ones that I've worked with that are really good have been in incident response for a long time, have seen things happen in the real world, know what happens when there's actually a security event. My sort of anecdotal take on that is they seem to be the ones who have the most natural empathy already. Whereas, you know, people who necessarily don't— haven't necessarily lived through big things like that, maybe, I don't know, maybe that's an ingredient that helps them, you know, to live through some big events.

**38:51 Chris Romeo:** Yeah, incident response gets you a lot of exposure to a lot of different areas that you have to get up to speed in quickly. Like, You don't have any choice. Like when I was talking about the CEO yelling at me on the phone, I mean, that was in the midst of a DDoS incident, and the CEO was yelling because their website was offline.

**39:07 Robert Hurlbut:** Hmm.

**39:08 Chris Romeo:** But yeah, so you're totally right on there in that being in incident response, and I've done a fair bit of that in my career, you really do have to understand enough about all those pieces I was talking about: network, operating system, application layer, and you have to be able to coordinate with people in a very high-stress environment where people are screaming at you on the phone, but yet we've still got to solve what the problem is. Even though the executives are screaming. And so, yeah, that's, that's incident response is a great breeding ground for, for people that truly respect and understand the other areas of the business.

**39:39 Robert Hurlbut:** Yeah. Yeah. Working in TAC for a network engineer. It's a great place to start your career, by the way. If you want a place to start. In vendor, you're talking about vendor TAC, right? Yeah. Start in a vendor TAC someplace or in a NOC. Start there. It gives you a bigger, much bigger view of what's going on. So from a certification perspective, any certification thoughts or any education thoughts you might have, Chris, on how network engineers can come up to speed? I know you have Security Journey, which again, I need to go do something beyond the white belt, but—

**40:10 Chris Romeo:** Yeah, we would welcome to have you back training in the dojo with us again. Yeah, I mean, when I think about security certifications specifically from a network perspective, there's not really a certification that has a direct tie-in. to the network side other than maybe things that are happening like CCIE Security or something, but that tends to focus on more of Cisco security products as the foundation of it. What I really want to see is, I really want to see a world where network folks understand enough about security to, like we were talking about before, understand the world of the security people. That's one of the things we tried to do at Security Journey is really just provide kind of a a lower level, what we call our white belt, which applies to everybody because it just makes you aware of what are the issues. It doesn't even get into the technology, and we have things at higher levels to get into the technology. But I'd love to see that world where network engineers understand the foundations of security because I've got news for you. This security thing isn't going away. It's only getting more stringent every year as more breaches like Equifax and things happen.

**41:21 Robert Hurlbut:** Yeah.

**41:22 Chris Romeo:** It's just going to tighten more and more and more until everybody has responsibility for security, whether that's network, whether that's application, whether that's security in general. We're all going to be in that same place. Yeah.

**41:35 Robert Hurlbut:** I think that's it for me. Just go to Security Journey and check it out, guys, if you're listening to this. It actually is really good. I do have my white belt there. I should get on with other parts of it. I've just been working on dissertations. Other things that I probably should try to get done. So, Tom, any other questions? No, I'm good. It's been great talking to you, Chris.

**41:54 Chris Romeo:** Yeah, thanks for having me.

**41:55 Robert Hurlbut:** All right, Chris, where can people get in touch with you? SecurityJourney, is it .com? Is that what it is?

**41:59 Chris Romeo:** Yeah, yeah, www.securityjourney.com. You can also find me on Twitter @edgeroute and @securityjourney. I'm an avid Twitter user and will respond in no less than one week.

**42:10 Robert Hurlbut:** And I assume they can find you on LinkedIn as well?

**42:15 Chris Romeo:** Yeah, find me on LinkedIn as well. Love to connect and share thoughts and things Okay.

**42:20 Robert Hurlbut:** Tom, you're still— by the way, does Security Journey have a blog as well? Is that right?

**42:24 Chris Romeo:** Do you blog there? We do. We have a blog that you'll find at blog.securityjourney.com. Then we also have the Application Security Podcast. I know, not a great marketing name, but it does describe exactly what we talk about. Yeah, we do that weekly as well.

**42:37 Robert Hurlbut:** Okay, cool. Tom, I guess you're still just on Twitter. You've been talking to me about these blog posts that you've never finished. I'm going to make a commitment here on the show. Are you ready, Russ? This week, so in the past by the time this by the timeless publishes, I will have a blog post up on rule eleven dot tech. You you've got like you you have like two months. Sweet because we're so far behind, but it's good. All right, well thanks Chris for coming on the hedge, and we'll get you back on if you see anything specific about you know DDoS or what's going on in the world security that we need to talk about would be really cool to. We'll have to get you back on to talk about those things in the future. Thanks a lot.

**43:17 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @Edgeroute and Robert @RobertHurlbut. Security is a journey, not a destination.

---

Source: https://appsecpodcast.com/chris-romeo-the-state-of-security-and-the-importance-of-empathy/