Season 7 Episode 8 Dec 29, 2021

How Cybersecurity Needs To Evolve and How To Get Into It

Pitch

When in doubt, just apply to the job.

Description

In this episode we talk about how cybersecurity needs to evolve and how to get into it, with Alyssa Miller, Business Information Security Officer at S&P Global Ratings, and author of the book Cyber Defenders' Career Guide.

Host

Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.

Guests

Alyssa Miller

S&P Global Ratings - Business Information Security Officer

Alyssa Miller is the Business Information Security Officer at S&P Global Ratings, and author of the book Cyber Defenders' Career Guide.

Show Notes

Audio file size

40472063

Duration

00:42:09

Transcript

[00:00:00] AM: So we can sit here as cybersecurity people and I can blame, “Oh, those developers. Oh, those silly users. Oh, all these other people,” but it’s incumbent on us in cybersecurity to be able to communicate in a way that speaks to each of those people.

 

[MUSIC BREAK]

 

[00:00:27] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem. And today, we’re about to talk about cybersecurity with Alyssa Miller, Business Information Security Officer at S&P Global Ratings, and author of the book, Cyber Defenders’ Career Guide. Thank you so much for being here.

 

[00:00:50] AM: Yeah! Thank you, Ben. It’s awesome. I really appreciate the opportunity.

 

[00:00:54] BH: All right. Let’s talk about your book, the Cyber Defenders’ Career Guide. What was your impetus for writing this?

 

[00:01:02] AM: So it’s kind of interesting. I mean, the real impetus was a publisher reached out to me in Manning and said, “Hey, do you want to write a book?” But at the end of the day, it really comes down to there’s a lot of noise in the industry about the supposed skills gap in cybersecurity. In particular, I’ve heard it called skills gap, talent shortage, whatever. There’s a lot of that noise out there. I mean, some companies were talking about there’s this million as many as four million open positions. I don’t know how real those numbers are. I look at it and I’m seeing on the flip side, there’s all these people I’m talking to are recent college grads or they’re developers or they’re SREs and they want to get into a security career. And they’re like, “I can’t find a job.” And so like, “Well, wait a minute. How does that work?” We have four million open jobs and we’ve got a ton of people that I’m talking to all the time who can’t find jobs. There’s dissonance here, right? Something is not right. And so I got into doing quite a bit of research, because initially I thought it was just the job-seekers that were messing up, right? I’ve thought, “People just aren’t looking the right way, whatever.” So I started doing some surveys, trying to understand what job-seekers were doing and what they were doing “wrong”. And what I started figuring out was that, yeah, there’s plenty of blame to go around on both sides, but the industry has created a lot of the problem, too. And so I’ve got to dig in more and dig in more and I put together a TEDx talk that I delivered. And so I had all of this information. And so when Manning reached out to me and said, “Hey, do you want to write a book on starting a career in cybersecurity?” It was like, “Yeah, I’ve got a ton of research on this. Let’s do it.”

 

[00:02:49] BH: Could you sort of define the types of initial sort of challenges someone has to overcome in order to break into a new thing in general and we can talk about cybersecurity, but when you’re thinking of observing, you’re seeing people not really putting themselves in the right position, how would you describe that state for people and how might they kind of think about it or nudge themselves towards overcoming it?

 

[00:03:16] AM: So the big one, one that I ran into more than anything else is just a lack of actually self-awareness. The number of times that I’ve had somebody reach out to me asking for help, and they’re like, “Hey, I really want to learn cybersecurity. I want to get into a career in cybersecurity. Can you help me?” “Yeah, absolutely! Let’s go! What area of cybersecurity do you want to get into?” And then either it’s crickets or the answer back as well, “I just want to learn all of it.” Which, okay, I admire the enthusiasm here, but I don’t know all of cybersecurity. I don’t know anybody out there that I can say that they know all of it. It’s a massive, massive field. And it’s the same thing with anything in tech, right? I mean, imagine somebody coming to you and saying, “I want to learn all of the programming languages and all of the programming environments and all of the CI tools and all those things.” No, that’s not going to happen. So just first trying to understand yourself and what is it in cybersecurity that interests you. I mean, within the book, actually, I dedicate a whole chapter to this with literally exercises and things that people can do to try to figure that out if they’re having trouble, really figure out what it is in cybersecurity that sparks their interest. So I think that alone is so important because I think people, either they don’t understand the complexity even, and so they don’t realize how much of a terribly insurmountable ask that is, but I think also a lot of times it might just be that it’s hard to really quantify what I want to do. And so they’re afraid if they choose wrong that they’re stuck. It’s so easy to pivot. Yeah, you’ve got to do some more learning and that’s not necessarily easy, but you can pivot from one to the other. You never stop. Once you’re in, you’re not stuck. And so I think sometimes for people even just understanding and accepting that can be a real challenge. And then from there, it’s really understanding job descriptions. Because let’s face it, I don’t care if you’re in programming, if what area of tech you’re in, cybersecurity, whatever, job descriptions are awful. They’re terrible. You go out there and you see a job description that has a requirement for 10 years of Kubernetes experience. That’s probably not going to happen for a technology that isn’t 10 years old yet. Now, as an extreme case, they’re not all that bad but there’s so much in job descriptions that are so hyper-focused on, you’ve got to know this technology, this technology, this technology, that then people will look at those job descriptions and like, “Hey, I don’t check all those boxes so I’m not going to apply.” When the reality is the person behind there, that hiring manager had been like, “Hell, if you could have checked one, I would have hired you.” And so I think there's a challenge there. I mean, there’s challenge getting organizations to fix that. And I’m working on that, too. But in the meantime, to try to connect job-seekers and hiring organizations, it’s like, all right, you’ve got to look at these and just get over those bullet points and forget about them. Just look at what the job actually is. What does the description say it is? And if you feel like you can do it or you can learn to do it, apply! The worst thing I do is tell you, no. All right, maybe the worst that I can do is just not tell you anything at all, ignore you, which unfortunately they do sometimes too, but apply! Go out there! It’s not going to hurt you to apply to a job.

 

[00:06:45] BH: I’ve had a few job interviews when I was just getting started in software development in general where I had a misconception of what the job was looking for because a recruiter reached out to me and I kind of assume that they reached out to me because they identified that I had the skill. And then not until later in the interview did I find out like, “Oh, I actually don’t have that skill.” And me, I don’t know, maybe assuming the recruiter would have a better understanding of what they were looking for. But they didn’t. And I actually was offered the job, even though I told them like, “Hey, it turns out I don’t know this programming language.” And I almost said like, “Sorry.” And they were like, “Well, that doesn’t really disqualify you. We figured you can get up and running with this.” And I was like, “Great. I kind of feel the same way.” I just legitimately have never worked in this environment.

 

[00:07:43] AM: Yeah. I mean, your story is very common, right? And that’s why I try to help people understand. It’s like, “Look, as a hiring manager long time, myself, I can tell you, sometimes you get forced to use awful job descriptions.” I’ve been in organizations where they were very standardized in their job descriptions and I didn’t have the opportunity to edit it at all. And that’s frustrating. Smart hiring managers are the type who can look at somebody and say, “Yeah, maybe you don’t have the experience with this exact technology that we’re going to use but you understand the concepts where you have other core skills that really play well into what this job needs. And I can teach you the technology side of it. I can see you’ve got some aptitude to learn, which is important, but I can teach you the rest or we can develop that in you.” And that happened to me that very first job into cybersecurity. I literally told her when she asked me if I wanted to join her pen testing team, “I don’t know how to pen test.” And her answer back to me was, “You’re smart. I know you’ll figure it out. That’s why I came to you.” And I mean granted that’s a little bit more of a flippant way to put it that she put it like that, but at the same time that kind of idea is how most good hiring managers that I know of, that’s how they’re looking for people. They’re not looking for somebody who’s going to check off a bunch of checkboxes on a list. And if they are probably not the manager you want to work for anyway because that indicates some other weaknesses and leadership style, but most of them are not. Most of them will say, “Wow! Yeah. Okay.” You’ve been programming and you’ve been working in maybe an enterprise environment, if you’re talking to a large enterprise org, you’ve been working in enterprise engineering teams for a long time, that’s a skill that I can’t teach. That’s something you only learn if you do it. And so that alone can be very valuable regardless of if you know how to program in the exact language that we’re using today. I’m sure you can pick that up. A lot of those concepts remain the same. And the stories like yours, that’s something I really love to see that shared because it helps get people over that fear of applying to a job that maybe that long list of technical requirements makes them feel like they’re not a fit for.

 

[00:10:10] BH: So on the topic of cybersecurity, how would you define cybersecurity, the field broadly? The book starts with defining it. For our audience, how would you go about that?

 

[00:10:25] AM: It’s interesting, because apparently my definition is very different than other people’s. So for a long time, there was this idea of information security, right? Which to me, information security is what organizations did. And it was exactly as the name suggested. It was defending information. And so it was very focused on technical aspects. It was the technology we were trying to protect because that’s where the information lived. Then we have this idea of cybersecurity. And to me, cybersecurity is that broader, I have to protect everything that’s now part of this digitally connected world that we live in. I mean, we’re connected in ways we never were before. It used to be when we had information security, the technology was very specific and all the aspects outside of that weren’t information security. Well, now, everything we say do and touch somehow gets digitized somewhere becomes a part of this digital realm that is to borrow a term from one of my colleagues. It is our way of life, right? I mean the internet and everything in it is just inherent to everything we do. Imagine tomorrow, if like the internet went away and we had nothing, where we would be, we’d be completely lost. And so I look at cybersecurity that way. Cybersecurity is protecting that broader spans of everything as interconnected. It’s not just technology anymore. It’s oil pipelines. It’s satellites in space. It’s people getting from A to B on a bus. All of these things now that we didn’t associate with computers before, now that digitally interconnected world is just part and parcel, too. So that’s the way I look at cybersecurity. It’s all of those domains, it’s protecting all of those different pieces. And everything that goes with that, with governance and regulations and all of that, I love all of that. In my definition of cybersecurity, which like I said, apparently flies counter to some other people’s definition.

 

[00:12:31] BH: So then, with cybersecurity obviously being more expansive than ever given the way technology has gone, how is it even possible to define jobs and roles and how much consistency is there across different types of companies within our industry startups, enterprise, non-tech companies who still run technology, entry-level positions, senior? How did these subfields and sub-disciplines break down effectively and how do we wrap our head around that?

 

[00:13:13] AM: So I mean, there were a couple of questions in there. Let me kind of unpack it. The first is just this idea of, “How do we keep defining these roles?” And that’s the reality, is I think ideally, if we could get there, there wouldn’t be separate cybersecurity roles. Cybersecurity would just be part of the domain of knowledge that you need to have to do different jobs. I think cybersecurity professionals have been kind of talking about that idea, not in the best ways necessarily to get other people to buy into it, but we’ve been talking about it. Something I’m doing right now in my organization is launching what we call security champions program, where I’ve got engineers, I’ve got architects, even my governance, risk and compliance people want to get involved in this, which is great. And they’re looking at how they can have people in those other job functions who have a very specific cybersecurity focus. Because now cybersecurity just becomes sort of this culturalistic thing that we do. It’s not this oversight function or separate control function anymore. It’s just, it’s what we do. And that’s, like I said, very idealistic way of looking at the world, probably pretty optimistic that we never totally get there. There’s probably always going to be a certain need for those people who are very specialized in some of those security concepts. But we do want that to be something that reaches into every portion of the business. And so then we look at it, I think to make those differentiations and where they come from, it’s still driven by the technology largely. And technology isn’t that it’s a function. So we’ve got people in security operations centers, they’re kind of that front line of defense. They’re watching the systems all the time and making sure things don’t break. Then you’ve got like your security help desk people who are doing their thing. You’ve got firewall engineers who are really just sometimes narrowly focused on just firewalls and how we manage that. There’s a certain necessity because every bit of it is so complex. You do want those people who spend all their time focused on one technology and building deep expertise in it so they can understand how to leverage that specific technology in the context of a much bigger strategy. And now at that strategy level is where you have your cybersecurity generalists, if you will. I mean, that’s the role that I fell as a business information security officer. So I think we’ll continue to see that melding. That idea of shared responsibility that started in DevOps where we were seeing one devs and ops to all be focused on the same goal of getting stable software deployed quickly. Well, now let’s add secure to that, right? If it’s true DevSecOps, we tried to kind of wedge ourselves in the middle there for some reason, it should be a shared responsibility where everybody is focused on software being deployed quickly and it’s got to be stable and it’s got to be secure. That means, yeah, my security folk out there listening, it means we have to be responsible for efficient pipelines. We can’t slow it down. We can’t break the pipeline. So we need to be responsible for the stability and performance of that code when it’s deployed. Just like the SREs, just like our devs are. One of the biggest mistakes in cybersecurity is I hear people take that term shared responsibility and they’re like, “Oh yeah, that means that security is everybody’s responsibility.” It’s a pretty arrogant thing to say. Because I can’t make security your responsibility as an engineer, unless I’m also going to take on a certain accountability for what your focus is, which is again, being able to innovate, being able to build quick, being able to deploy fast. All the things that we try to do in a DevOps pipeline, I have to be a part of that, too. And so I think we’re slowly seeing the tide turn on that. And I think more and more security people are seeing that now. But that’s where people coming from engineering spaces, coming from architecture spaces are going to be awesome as they move into maybe a more cybersecurity focused role because they bring that context, they bring that empathy, they bring that inherent knowledge that unfortunately a lot of security people who haven’t done development just sort of lack.

 

[MUSIC BREAK]

 

[00:18:10] BH: So let’s say I’m sort of a generalist web developer and I get the sense that I’d like to specialize and I’m more and more interested in the security components, I’ve done some OWASP top 10 kind of work within my normal job, and now I feel I’d rather work more with the security people than the product people in a sense. So I have somewhat of a tighter sense of where I want to go and security still within web development then maybe someone who just says, “Cybersecurity in general haven’t quite figured anything out yet.” If that’s where I am, what’s next if I have that feeling?

 

[00:18:52] AM: I mean, if you’re already working in a role within an org, chances are there’s probably a cybersecurity organization there that you can start getting more involved with. And that’s where I would really look to, how can you start to bring those conversations of security into the development space and establish yourself as somebody with that knowledge? I mean, you mentioned, okay, we’ve probably already done some work. Understanding and designing for OWASP top 10 style vulnerabilities and how we countermeasure against those and things like that. So being that role and being that person within your engineering space that does that is a way to start before you do anything tangible or concrete. Just establishing that presence. But then that’s when you start reaching out to those people that you’re working with from the cybersecurity space and really communicate your interests like, “Hey, this is something I want to learn more about looking to get involved in.” Obviously, there’s a lot of security conferences out there. And one thing that’s really cool about security conferences that I don’t see to the same degree in a lot of other spaces is just the volume of security conferences that are community driven and have no connection to any specific vendor. I mean, there’s a few of them, don’t get me wrong. I mean, there are a few in the software development, engineering spaces and so forth, KubeCon and others are great. But even that, okay, KubeCon is kind of pretty tied to a specific technology. So I think cybersecurity is really open. And honestly, we could use more voices from the development side. So even finding ways to involve yourself in those, but then that also might be something you can even start bringing that back to maybe some of those more developer focused conferences, whether it’s cloud native foundation or all the different ones that are out there that have these spaces, can you start bringing a security message to those? All of those are good ways to kind of establish yourself and sort of build like a brand for yourself, but at the same time, you don’t have to get through all of that or be some successful public speaker or anything. Just start applying for those jobs. You have some knowledge. Again, I’m building this security champions program and I’m looking to hire two security people. I want them to lead that program and help me build it, but I’m not looking for them to actually be the security champions. But so I’m looking for there, I would love to take an engineer who maybe doesn’t have a whole lot of security knowledge at all but has shown some interest, has done some things to kind of grow their security knowledge. I would love to take them because they’re going to help me with what I really need and that’s how do I influence my developers. How do I build credible presence in those engineering spaces that as I try to move this program forward? They see the value of it and they want to be a part of it. And so I think looking for ways that you can do that, those roles that you could fill into, whether it’s an application security role, anything like that, wherever you can have some influence but leverage the knowledge you already have coming from an engineering role, I think that those are huge opportunities for you.

 

[00:22:09] BH: There are a lot of certifications in cybersecurity, are any of them worth pursuing? And if so is it worth pursuing before landing at a title or should that be kind of pushed to later?

 

[00:22:24] AM: So that’s a seemingly simple question that has a huge answer. There are many of them that are very good, but we have to understand what they’re good for, right? So there is unfortunately within cybersecurity this problem with job descriptions and part of it is a lot of job descriptions are really focused on you should have a certification. And the issue with that is when you take a job description like that and you plug it into an applicant tracking system that’s that automated thing that you send your resume into when you apply for a job, a lot of times they’re going in there looking and saying, “Is there a certification here?” “Nope.” Well, they get bumped to the bottom of the list. Or a recruiter looks at it and says, “No certification, put them to the bottom of the list. So just having a certification in that sense can be valuable just to get you over that hurdle. Now, not every organization is that dysfunctional. A lot of them, if you can get your resume to the hiring manager, they probably don’t really care if you have a certification. Certifications are nice add-on. The other thing that can be good with certifications is, if that certification comes with a certain level of training as prep work. One that’s tremendous, if you’re looking to get into offensive security, so like pen testing, that sort of thing, the OSC, the Offensive Security Certified Professional, I believe is what that stands for, they have this whole practical lab exam that you have to pass in order to get the test. So that takes a lot of studying and a lot of practice. So the value there isn’t even so much the cert itself, it’s the process you go through to learn all that in order to pass the exam. There’s a number of certs like that that are really good. But the challenge I find with certifications in cybersecurity, aside from them being so numerous, is that a lot of them are unattainable. I mean, for just a human to go out and pay for it -- I mean, there’s an organization out there, I won’t actually say their name because I don’t want to sound like I’m blasting them, but there’s an organization out there that has a lot of really great certifications and they all come with really great training, but it’s like $7,000. Who’s going out and spending $7,000. Most organizations don’t give you that in a training budget. A lot of companies will say, “Well, we’ll pay half.” Well, okay. That’s still $3,500 you’re asking me to pay just to get a certification. So some of that’s challenging. So there are others that are more attainable. CompTIA, who I will name, because I’m not picking on them, theirs are very attainable. You can get them for usually under a thousand dollars with the training and everything. A lot of times you can get your organization to pay for that. If you don’t have the funds there, actually, I know they’re willing to work with you. If you can get the study materials from elsewhere, just the exam itself is only a couple of hundred dollars. So okay, that can work too. And that’s a good one for getting some generalists knowledge and having at least something to put on your resume to say, “Hey, I’ve got a cert and it’s a cert that gave me a lot of base foundational knowledge in cybersecurity.” So there are different ones out there that can be good. It’s just what I caution people is don’t think that that’s like the thing you have to have to go cybersecurity job because it really isn’t. And very few hiring managers are going to look at a cert and say, “Well, you have that cert, so therefore I’ve got to have you.”

 

[00:25:57] BH: So it’s sort of nice to have in constructing an overall profile as a viable candidate. 

 

[00:26:03] AM: Oh yeah. Again, it’s definitely advantageous. If I had two candidates who all other things being equal, same experience, same knowledge, everything else, which obviously would never actually happen, but if I did, that cert is probably something that would push it over the top to send me from one to the other. It shows, okay, you went through and you learned everything you had to for this so I can be a little more confident to some degree. But again, it’s not an end all be all. Most of the time when I’m looking at a situation like that, of course, the people aren’t exact clones of each other, except that one has a cert. So there’s other things that come into play and there are other things I would prioritize higher than which person has the certification necessarily.

 

[00:26:47] BH: What about pursuing mentorship as means of breaking into the industry or sort of getting one’s feet under themselves if they are getting started?

 

[00:26:59] AM: So this is a fun challenge. In the research I did, I looked at mentorship, college degrees and certifications, and I looked at how do those interact with the length of time that someone spends looking for a job. And across the board, whether it was somebody who was brand-new looking for the first job or somebody had experienced, those elements didn’t correlate at all with shrinking that timeframe of how long you’re going to look for a job. Again, doesn’t mean they’re not valuable things to have. And mentorship is no different, but mentorship we really need to understand what is the value of mentorship. To me, in my opinion, the value of mentorship is being able to a; have somebody who’s been there, done it before, who you can bounce ideas off of. If something’s occurring, you’re in a situation, you can get their opinions of things, you can understand how they see the world. The other thing is, their value that they bring if they have a network. So if you’re going to consider somebody your mentor, and I’ll be honest too, my view of mentorship is the best mentors I’ve ever had. Those relationships grew organically. It wasn’t like I just set out to find a mentor. But you do want to build mentorships those relationships with somebody who does have a solid network in the industry you’re trying to get into. Because not only does that help you get leads on finding a job, which is great, but it also gives them broader access to knowledge that if you come to them with a question that maybe they don’t know or have a good answer to, they might have somebody they can connect you with, who can then get you those answers. And so that’s the key, in my opinion, when we’re talking about mentorship. Yeah. It might help you get connected with jobs and that’s good, but again, statistically, it doesn’t seem to have a whole heck of a lot of impact. So focus on it for what it is worth and that is helping you with some of those knowledge items, and not technical knowledge necessarily or that exclusively, but also just kind of how do you function in this particular space and how do you get connected to people in that particular space.

 

[MUSIC BREAK]

 

[00:29:42] BH: So if we’re going to wind back time a few years, it might have been hard to conceive of maybe the colonial pipeline attack and just how that’s even a thing in the world that gas prices and the whole country were affected because of cybersecurity hostage situation, but certainly it’s one of only a few significant breaches that affect all of us. And in putting some of this stuff into context and extrapolating into the future, what is the importance of cybersecurity for our global society mean for the future of the industry? The expansion of the roles, the type of roles, how would you put all that in the context?

 

[00:30:34] AM: So I think that first and foremost, it means I’ve got job security for the rest of my life. I don’t think you’re ever going to get away from that. In fact, I was asked the other day in a board meeting, “What is the end state? When do we hit that point where we say we’re secure?” And I preface to them that this was going to be a snotty answer. And I said, “Well, we’ll get to that point when technology stops innovating,” which is not going to happen. It hasn’t happened in the history of mankind. It’s not going to happen now. We’ve opened the door. We’ve created this digitally connected world that we’re only going to continue to leverage that. And so we’re always going to be kind of chasing on how do we secure the next thing to come along. What I think is going to shape cybersecurity and maybe in the next decade or two is a lot of what my role is about, and that is cybersecurity becoming better communicators and better involved in the business side of the world. Because like the colonial pipeline thing, to you use that example, we knew that was a possibility. We knew for years and years and years that was a possibility, but we couldn’t effectively influence change to get the organizations to make the decisions that needed to be made in order to defend against it. And we still struggle with it. And so we can sit here as cybersecurity people and I can blame, “Oh, those developers. Oh, those silly users. Oh, all these other people,” but it’s incumbent on us in cybersecurity to be able to communicate in a way that speaks to each of those people. And that’s where I think we haven’t done a good job. I mean, I looked at the 20 years of my career, 25 years since I started as a programmer, and I looked at it and I say to myself, “God, we really haven’t changed the messaging at all.” There was a release of statement from the White House that came out about how to avoid being breached over the holidays and it was all the same mantra that cybersecurity has been proclaiming forever. Patch your stuff. Use multi-factor authentication. Have complex passwords. And I’m looking at this like, “God, we haven’t changed at all.” Nobody’s listening to this. They haven’t for 20 years. Why do we keep just saying the same things? So I think what you’re going to see is cybersecurity slowly learning that we need to take the onus on ourselves to be better about how we communicate, how we actually integrate with the various aspects of the business, be at the finance teams, the product teams, the engineering teams, you name it. And that’s what I see in the next decade is really going to be transformative for this particular industry is just yeah, we have to get better at that. And I think we’re starting to see that because here we are again, very recent past Log4j shows up in 90% of Java applications with a massive, scary vulnerability and we’re able to address it to the credit of the engineers I worked with and so many around the global who helped to address this thing. It was big and scary, which you look at the whole cybersecurity talk about it, we talked about it like it was big and scary. There weren’t as many voices who are out there just calmly saying, “All right, here’s how we addressed it. Here’s how we move forward.” And there were a lot of voices out there, unfortunately, who even were saying things like, “We told you, this would happen.” Whatever, there’s no need for the, “I told you so”. There's a need for us to look at, “Yeah. We knew that this was a possibility, especially with widely used open source software, so why weren’t we able to communicate and influence our product and engineering teams to be better prepared to handle things like this?” So that’s the storyline I see anyway, and I really hope I’m right.

 

[00:34:41] BH: Can you, just because it’s so fresh, explain what exactly went down with Log4j?

 

[00:34:48] AM: Yeah. So any Java developer out there has probably heard of Log4j first of all, It’s very, very commonly used logging library. It’s super, amazingly helpful for a lot of people. Ninety percent of Java apps was the stat I saw use this particular library. So the vulnerability, and it was that sometime, I want to say if I remember it was like 2016, there was a feature request to add lookup capability via JNDI, J, N, D, I. And so what happened was you could pass these lookup values and one of the formats allowed that host or that particular application. When it was logging in Log4j, it would go out and go to, in this case, an LDAP server and pull back a Java class that it would then fire up in the JVM and use to provide lookup information to get logged into the logs. Well, I mean, unfortunately, on the surface, I guess that didn’t really sound with alarm bells for the people you would hope it would, but imagine the idea of potentially going to a site for which you have no control and pulling a Java class from it and running it in the JVM on your box, in your container or whatever. Think about the control that that could potentially give somebody over that particular system. And that’s exactly what happened was people found ways, fairly trivially to inject a string into any field. So say Log4j was logging your user agent. I could manipulate the user agent to put this JNDI string in there, cause Log4j to go to a server that I controlled and pull through LDAP this Java class and execute it or load it up in the JVM, and now that gave me the ability to send subsequent requests to that server or to that host. So think about like Java Shell and things like that where I can actually, now, whatever I’m capable of doing via JVM, essentially is something that that attacker could do. It was just one of these things where it sounded like a really cool function. Like, “Hey, I can go and I can do these lookups and I can pull back a class that executes and does these things.” And somewhere for somebody that was probably a really cool feature. But unfortunately, what it looks like didn’t happen, was nobody thought about the threat model for that. And what does that mean? We have to defend against, should we defend against that in the library itself? Should we be informing developers that, “Hey, if you’re going to use this in your app, this is something you have to make sure that you sanitize your strings coming in.” All of these different possibilities are a part of that threat model that just unfortunately went unconsidered and it was ultimately discovered, “Hey, I can do this really horrible behavior.”

 

[00:37:48] BH: If there’s a spectrum of threat models for a similar type of attack, how does the conversation go down where the validity of the exploit itself in the community is a little bit more contentious? Is this an exploit or not?

 

[00:38:07] AM: Yeah. So generally, it’s probably isn’t an exploit. Where I think the contention comes in is how exploitable is it and what are the impacts? Within the cybersecurity industry, we call that likelihood and impact. So how likely is it that someone’s going to find and exploit this thing? And if they are able to exploit it, what are the potential impacts of that? And that’s the thing that changes from application to application, from company to company, both sides of that equation can shift based on each application. So if I’ve got, take the Log4j example, if my application wasn’t available to the outside world, it wasn’t internet accessible, it’s only accessible within my network. Well, that severely reduces the likelihood of it being exploited because all of these people scanning the web to find that vulnerability aren’t going to find that particular application. So that likelihood brings it down. Now, the impact could still be higher. In fact, it might even be higher, right? The potential impact, because if it’s an internal system, maybe it has access to more data than one of my web applications would have. And so could they do potentially even worse harm that way? Maybe, maybe not. Maybe my internal systems are simple things that are just like a knowledge based store or something like that. Who knows? Whatever it could be. It might be something that’s not very business critical to you. But this is where, back to the point, resolving that contention has to come from security and the business side talking to each other and understanding each other’s world. Not security people running around and saying, “Oh my God, there’s another vulnerability in Log4j. Oh wait. It’s the worst thing ever. We have to fix it.” And then the devs come back and they say, but wait, it requires this particular configuration, which almost nobody uses that configuration. We don’t, and it’s denial of service. So yeah, it’s bad, but it’s not nearly as bad as something that could give somebody complete control of our box. They’re just able to cause stability issues. So yeah, that’s serious. For some of us that’s very serious like in my organization, but at the same time, it is still less critical than somebody taking over my system. So that’s where we need that greater intelligence. And what I really liked, at least within my org, was I had engineers pushing back on me in that way and being willing to have those conversations. And you know what, it makes me stop and say, “Yeah, you’re right. You know what, let’s prioritize these things the right way.” And so we need those conversations where security understands just because in the ideally worst world, the likelihood and impact are high. You have to consider what is the world where you actually discovered it, what’s that real world and then adjust your likelihood and your impact, which those two together equal risk. Let’s understand what the actual risk is. And I think within security, we can probably be a lot better about that.

 

[00:41:19] BH: Thanks for coming on, Alyssa.

 

[00:41:31] AM: Yeah. Thank you for having me. I really appreciate it.

 

[MUSIC BREAK]

 

[00:41:42] BH: This show is produced and mixed by Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join us for our DevDiscuss Twitter chats every Tuesday at 9:00 PM US Eastern Time. Or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.