Why no one has gotten to the bottom of the Log4j cybersecurity hole

Best listening experience is on Chrome, Firefox or Safari. Subscribe to Federal Drive’s daily audio interviews on Apple Podcasts or PodcastOne.

Log4j, the most visible cybersecurity threat since Solar Winds, has organizations scrambling to find and fix instances of certain software. My next guest says that the two incidents are totally different technically, buy they produce the same lessons learned. Gordon Bitko, former FBI chief information officer, now the senior vice president of policy at the Information Technology Industry Council, joined the Federal Drive with Tom Temin with details.

Interview transcript:

Tom Temin: Gordon, good to have you back.

Gordon Bitko: Hi, Tom, great to be with you, as always.

Tom Temin: Log4j, I think, is less understood technically, even though everyone is banding about the term. But it’s fairly simple. Maybe let’s start with an explanation of precisely what it is.

Gordon Bitko: Sure, I think that’s a good place to start, so people understand, Tom, why it’s important and why it’s so ubiquitous. Log4j is a component of Apache software. Apache is open source project. That means that there’s lots of people who’ve contributed to it over the years. And it’s very widespread — a lot of different programs, a lot of different systems have used it, it’s foundational for web servers, and all sorts of other applications out there. Within it, as with many programs, you have the desire in many systems to log the activities that are going on so that developers can track what’s happening if there’s a problem, so that users if something goes wrong can send error reports back, all sorts of reasons why you want to collect log data. And security is another important reason why you want to collect log data as well. So Log4j is one of those components that exist within Apache. If you build an open source system using the Apache, you get Log4j as just a part of the process.

Tom Temin: So then Log4j normally contains code that is not executable, but in this vulnerability that’s going around, the bad guys have discovered a way to put executables into your logs, and therefore they can launch some attack from a place you never expected.

Gordon Bitko: That’s exactly right, Tom. What they are able to do, a log file shouldn’t just be by and large a static record. Here’s what happens when somebody after the fact can go back and analyze what went wrong, or what data was collected, and use it for legitimate purposes. But in the case of this particular set of bugs that exist within Log4j, people have figured out that it allows code to be executed, just like you said. And that really opens the door to virtually anything. People have discovered all sorts of log files using Log4j, and you can send the right strings of data and it will allow you to execute code,

Tom Temin: And has the rise of first, I guess, generation of post-server software called virtualization. Now we have containerization, so that instances of logs and all sorts of software get replicated all over the place. Has that multiplied the problem relative to when organizations had a single version of, say, a web server running on a single physical server?

Gordon Bitko: There’s no doubt, Tom, that there’s been a proliferation. It’s super easy, as you noted, to create in the cloud, in a virtual environment, to create a system and to have a version of Apache running, and within that to have Log4j. And honestly, in many cases, people won’t even know that that’s what’s running their system. They’ll have done something at a level or two abstracted up above from Apache, and it’s just that Apache happens to be the underlying product that the containerization is built on.

        Read more: Cybersecurity

Tom Temin: All right, well then, really, we could sit here and talk about codes to write, to execute, to root it out and so forth. There’s probably a lot of technical roots. But at the heart, I think, of your thesis is that in many ways, it’s a management issue. And we have a law that is currently under consideration for revision — the Federal Information Security Management Act, FISMA, under which this whole thing has been operated by the government. And so maybe bridge the challenge of Log4j to the need for FISMA. Reform. Am I making a bridge too far here?

Gordon Bitko: No, I don’t think so, Tom. There is a logical connection in my mind. What we learned both from SolarWinds, and now again from Log4j, is that the government’s focus has been in FISMA, in the information security programs, the upfront processes. Those are important. There’s no doubt it’s necessary for agencies to understand what are all their assets, who are all their users, to make sure that there’s an annual report. Those things are necessary for an effective compliance program within the world of security, but they’re not sufficient for a truly risk-based program. When you have a truly risk-based program, you need to understand what are the consequences if something happens, and you need to have accountability at a high level in the organization. And I think that that’s a lot of what’s missing in the current version of FISMA. And what we, in yesterday’s hearing and in the proposed bill language, are looking at is reforms to try to get to those outcomes — to be looking at real risk and real accountability within agencies.

Tom Temin: We’re speaking with Gordon Bitko, senior vice president of policy at the Information Technology Industry Council. When looking at something like Log4j, you have to have top management interest in what’s going on, and you have to have the so called C suite, including the Chief Information Security Officer. But how does that translate into making sure that there is somebody that goes and roots out Log4j instances, which can be a pretty time consuming task to find out everywhere it’s running and make sure that every instance is patched.

Gordon Bitko: I think that’s exactly why you do need, Tom, the senior leadership in an organization all the way down to take responsibility. It’s not enough on the day of the incident to just have an awareness and to know that there’s somebody working on it. But the agency leadership — the CIO, the CSO, and down into the working security organizations — all need to be in sync to understand there is a vulnerability. Oh, hey, we’ve identified a mission critical system that’s exposed to this vulnerability; we might need to make a decision to take that offline to fix it. There’s super sensitive data in there, and if it’s compromised, the cost to the agency for that is unacceptable. Citizens, PII might be exposed, all sorts of things like that could happen. And that needs to be a decision that gets made at the senior-most levels of the organization, and it needs to get made quickly. Agency leaders can’t take their time. They have to be prepared to know what the risks are, and to quickly make those decisions.

Tom Temin: And one of the questions that came to my mind in listening to the hearing and looking at some of the reforms they’re talking about — it does give CISA, the Cybersecurity and Infrastructure Security Agency at DHS, a bigger role, and that’s kind of an evolution of what’s been happening for probably 20 years, since there has been a DHS. But does it, in some way, absolve agencies from visibility directly to Congress and what they’re doing, if there’s an overlay of central command by the government, through CISA, over agency cybersecurity activities?

Gordon Bitko: I sure hope not, Tom. What I hope we get to as a model is the right balance between —and this is something I talked about a little bit in the hearing in a slightly different context — but the right balance between a really prescriptive view that says that, in this case, only CISA should be responsible, and an understanding that what we really need is a federated approach. CISA should be a resource that should be providing guidance. They should be verifying that agencies are doing the right things. There are numerous agencies out there that have quite sophisticated, complex capabilities when it comes to their own information security. And really, CISA’s role there shouldn’t be anything other than ensuring that what they do integrates into the overall federal landscape. There are other agencies that are a lot less mature when it comes to cybersecurity and may need the help. And CISA really should, in that case, have the role of working much more closely with them to ensure that they up their game. The whole of the federal government is only as strong as the weakest links, right?

Tom Temin: Sure. And the policy of continuous diagnostics and mitigation and also of continuous monitoring for patches, specifically, and for un-updated software — that goes back, again, about 20 years now. But really, it’s probably fair to say not every agency is really up to speed on that basic hygiene approach, are they?

        Want to stay up to date with the latest federal news and information from all your devices? Download the revamped Federal News Network app

Gordon Bitko: There’s no doubt every agency has a long list of open POAMs — plans of action and milestones — goals to fix those vulnerabilities that you just mentioned. And they prioritize them based on which ones are critical, and high and medium and so on. And the critical ones gets fixed pretty quickly in most agencies now. As you go down the list of impacts, they probably don’t get fixed as quickly. And of course, the reality is what was maybe a lower priority vulnerability, it turns out it could become more significant over time. And agencies, many agencies, have a lot of technical debt when it comes to mitigating those vulnerabilities.

Tom Temin: And that gets us back to the Log4j question, because most agencies are going to look at their application software, whether they own it and run it on their own servers, or whether it’s offered as a service or whether it’s their own but hosted in a cloud. Historically, the vulnerabilities have come from application software. And probably before Lo4j, nobody thought to check log files as something you would have to continuously monitor or look for patches for. So in some sense, the whole idea of monitoring has widened a great deal, thanks to some basic utility being found to be a vulnerability launch point.

Gordon Bitko: I think what we’re realizing out of both SolarWinds and Log4j, to go back to the original premise here that there is a management connection between them, is that the risk, because these things are ubiquitous, is very high. And agencies need to be aware and to understand that they might have components that might be in something like a log file that, like you said, Tom, you don’t think of it in of itself as high risk because you’re focused on rightly so where are your critical data, what are your critical information assets. But if what’s underlying those is something like Log4j for logging purposes or SolarWinds Orion for network management configuration purposes, the risk is obviously unacceptably high, and agencies need to start having an understanding of those types of risks as well. Not just what’s your sensitive data, but it’s a what are all the things that are in the ecosystem around that most sensitive data.

Tom Temin: And is your sense from the hearing that Congress really means to get around to FISMA reform?

Gordon Bitko: My sense is that there is, Tom, momentum that Congress understands that cybersecurity is a priority, and that there is a need to do work. There is a need to clarify roles and responsibilities of all the different stakeholders. You mentioned CISA. They know the National Cyber Director, that needs some clarity. They would like to formalize the role of the federal CISO in the Office of Management and Budget, and what the responsibilities are there. So I think that there is a desire to do that. And the way that the proposed legislation was discussed yesterday, it was as a bipartisan effort.

Tom Temin: Well, that’s always a good sign that could give something a chance of getting through. And just a final question, again, getting back to Log4j, is there any evidence that there have been actually attacks launched against the government through that mechanism?

Gordon Bitko: I have no doubt that there are people looking to find ways to exploit it. My understanding so far is that there’s no evidence of anybody successfully doing that. And that’s not that surprising. The federal government is, although there are many shortcomings when it when it comes to cybersecurity and many things they need to do better, in terms of direct connections to the internet, there’s pretty decent defense in depth. You have the trusted Internet connection that people have to connect through and, and ways that the government will be able to mitigate the risk. That doesn’t mean that they don’t still need to patch all these systems and applications that are out there. They absolutely do. But I do also think that this is a case, Tom, where there’s a difference from SolarWinds. Log4j wasn’t a coordinated — as far as we know — attack by an adversary. It was a vulnerability that was identified, and so the people who are exploiting it now seem more like cybercriminals who were using it as a way to implant ransomware, things of that nature.

Tom Temin: Alright, so you can never rest on your laurels.

Gordon Bitko: That is 100% the case. It is important for everybody doing cybersecurity and their management to understand it’s a race on a treadmill. You can never stop.

Tom Temin: Gordon Bitko is senior vice president of policy at the Information Technology Industry Council. As always, thanks so much.

Gordon Bitko: Thank you, Tom. Always a pleasure to be with you.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.