CISA provides an account of progress toward Log4shell remediation. Other issues are reported in open-source libraries. Undersea cable security. FIN7’s BadUSB campaign. Security and Yealink.

Dave Bittner: CISA describes progress toward remediating Log4Shell. Other open-source libraries are found to have similar issues - in one case, problems deliberately introduced by the developer. Concerns are expressed over undersea cable security. FIN7's bad USB campaign. Security questions about another Chinese-made phone. Our guest is Bob Maley from Black Kite on their report, "The Government Called, Are You Ready to Answer?" Chris Novak from Verizon on PCI 4.0 and Russo-American talks open in Geneva.

Dave Bittner: From the CyberWire studios at DataTribe, I'm Dave Bittner with your CyberWire summary for Monday, January 10, 2022. 

Dave Bittner: CISA describes the response to Log4Shell, and while it sees a long tail of remediation remaining, the agency has a good news story to report. Like others interested in security, the U.S. Cybersecurity and Infrastructure Security Agency found out about Log4Shell on December 10 when the vulnerability was first disclosed. This morning, CISA held a media call to outline one month into the Log4Shell affair how the community it serves has responded to this widespread open-source software vulnerability. 

Dave Bittner: CISA Director Jen Easterly and executive assistant director for cybersecurity Eric Goldstein both spoke during the call. While Director Easterly emphasized that while Log4Shell was easily the most serious vulnerability she'd seen in her career - being widespread, easily exploitable and high in potential impact - the news she brought to this update was, on balance, a good news story. CISA has seen an unprecedented level of collaboration among its partners and that so far the agency has observed no serious consequences of Log4Shell exploitation. Such exploitation as they have been observed so far have been commonplace of a fairly low-grade criminal nature. They've seen mostly cryptojacking and bot herding, the latter presumably a preparation for subsequent opportunistic use. CISA hasn't been able to confirm that Log4Shell had been used to deploy any ransomware. 

Dave Bittner: The agency, Goldstein said, was aware of the risk of ransomware and was particularly alert to threats to hospitals but that so far ransomware seems not to have made extensive use of Log4Shell. CISA has also not been able to independently confirm reports of nation-state attacks, and the U.S. government seems to have escaped disruptive attack. Goldstein said that CISA has observed scanning of U.S. government agencies but no successful attempts to compromise them. That said, he cautioned against complacency. Log4Shell is too attractive a target for potential exploitation. 

Dave Bittner: CISA's role in the Log4j response exemplifies how the agency sees itself discharging its mission. CISA has sought to serve as a single authoritative source for information and remediation guidance. It's provided crowdsourced scanning tools and its aggregated advice from its partners, again, in a single, accessible location. 

Dave Bittner: Goldstein drew attention to the importance of the binding operational directives CISA has issued to the 101 federal civilian agencies of the executive branch that it supports. While such directives are binding on these agencies, they're also made publicly available and can serve as a useful source of practical guidance to others. He paid tribute to what he called the incredible power of crowdsourcing and made particular mention of CISA's use of Bugcrowd in the preparation of its response to the incident. 

Dave Bittner: The CISA executives confined their discussions specifically to Log4Shell and not the other ancillary vulnerabilities the Apache Foundation has recently found and mitigated. But they did offer some thoughts for the future of regulation and for the open-source software community as a whole. 

Dave Bittner: Easterly expressed disappointment that mandatory incident reporting legislation had stalled in Congress. But she also noted that incident disclosure is different from vulnerability disclosure and that mandatory incident disclosure wouldn't necessarily have brought Log4Shell to light and hoped that the legislation would pass in some form soon. 

Dave Bittner: Goldstein said that the Log4Shell incident showed the need for widespread adoption of software bills of materials. These would contribute greatly to organizations' ability to determine their exposure to any particular vulnerability. He also said that CISA believed the incident showed the extreme importance of open-source software and said that the agency was looking into ways of working to ensure that it was working with partners to invest appropriately in the open-source community. 

Dave Bittner: Easterly added that CISA was working to catalog vulnerabilities and would continue to work closely with its partners in the public and private sectors. She alluded briefly to a forthcoming effort that would prioritize primary important system entities, thereby focusing attention and resources on areas an adversary would consider high-value targets. 

Dave Bittner: Not Log4j, but Log4j-like, as it's being called, the Java SQL database H2 has been found to have vulnerabilities similar to those that afflict Log4j. JFrog, whose researchers identified the vulnerability, describe H2 and its use as follows. 

Dave Bittner: Quote, "H2 is a very popular open-source Java SQL database offering a lightweight in-memory solution that doesn't require data to be stored on disk. This makes it a popular data storage solution for various projects from web platforms like Spring Boot to IoT platforms like ThingWorks. The com.h2database:h2 package is part of the top 50 most popular Maven packages, with almost 7,000 artifact dependencies," end quote. 

Dave Bittner: Naked Security writes that the most probable avenues through which an attacker might exploit the H2 vulnerability are either through an active H2 web-based console or an H2 console listening on an external network interface. Some attacks could open targets to unauthenticated remote code execution. Users of the H2 database should update their instances to version 2.0.206 as soon as possible. 

Dave Bittner: Some open-source developer dissident activities surfaced over the weekend. BleepingComputer reports that Marak Squires, developer of the widely used open-source libraries colors and faker, introduced an infinite loop into the libraries so that applications that use them would be bricked with gibberish. Mr. Squires is apparently disgruntled by his sense of being ill-used and uncompensated by the companies who use open-source software. Sonatype warns that, quote, "developers using colors and faker NPM projects should ensure they are not using an unsafe version," end quote. 

Dave Bittner: Some developers, while not exactly approving of what Mr. Squires is said to have done, nonetheless have expressed some understanding of his feelings of ill-use. Sonatype's blog suggests that the incident, along with the labor involved in fixing problems with Log4j, quote, "draws attention to the issue of the open-source sustainability problem," end quote, something GitHub has drawn attention to and, for that matter, something CISA alluded to in their call this morning. 

Dave Bittner: According to the Barents Reporter, the Svalbard undersea fiber optic cable between the island of that name in the Barents Sea and the Norwegian mainland suffered an unspecified disruption on Friday. The system has two cables, one of which was affected. Coincidentally, Admiral Sir Tony Radakin, newly appointed chief of the U.K.'s Defence Staff, said Friday in an interview with the Times that the Russian undersea forces had taken a particular interest in undersea cables and that, under certain circumstances, disrupting undersea cables - which nowadays carry a great deal of internet traffic - could constitute an act of war. 

Dave Bittner: Cutting or tapping undersea cables goes back, of course, more than 100 years. The Royal Navy, for one, fished up cables serving Imperial Germany at the outset of World War I, cutting or placing taps on them. 

Dave Bittner: The Record reports that the FBI has warned that FIN7, the criminal gang well-known for operating DarkSide and BlackMatter ransomware, has undertaken a BadUSB campaign against U.S. organizations in the transportation, insurance and defense sectors. The physical USBs, which carry malware, are being sent by the U.S. Postal Service or by the United Parcel Service, and what could be more innocent-looking than those two organizations? Some represent themselves as packages arriving from the U.S. Department of Health and Human Services that carry important COVID-19 information. Others pose as holiday packages from Amazon, complete with festive wrapping, a thank-you note, a bogus gift card and, of course, the malicious USB drive. The payloads observed include Metasploit, Cobalt Strike, PowerShell scripts, Carbanak, GRIFFON, DICELOADER and TIRION, as well as BlackMatter and REvil ransomware. 

Dave Bittner: Defense One writes that there's U.S. senatorial concern about the risk Chinese-made Yealink phones might present users. Senator Chris Van Hollen, Democrat of Maryland, wrote the Department of Commerce back in September asking for an explanation of the Yealink software that could, at least in principle, monitor and report users' calls and online activity. 

Dave Bittner: Russo-American talks prompted by but not confined to the Russian threat to Ukraine open today in Geneva, Military Times reports. We'll be learning more about their progress over the course of the week. Stay tuned. 

Dave Bittner: Black Kite, a provider of a third-party risk monitoring platform, recently released research titled "The Government Called, Are You Ready to Answer?" evaluating the state of third-party risk affecting the U.S. federal government. Bob Maley is chief security officer at Black Kite, and he joins us with highlights from the report. 

Bob Maley: We saw across the board that they all have issues with patch management of operating system versions. That's one of the No. 1 things that we saw. They just had a poor rating on that. We also saw that there was quite a few of the companies that were susceptible to ransomware. 

Dave Bittner: And why is that? Why specifically do the defense contractors find themselves vulnerable to these specific things? 

Bob Maley: So it's not just the defense contractors. Obviously, ransomware is the current criminal activity de jure for bad actors. It's an easy way to exfiltrate cash. And they're taking a second tact on it now. They're exfiltrating and reselling data. So yeah, it's what is going on out on the internet with bad actors. 

Bob Maley: And they look for specific things. So there are a lot of types of, in the information security world, what we call controls or things that are put in place to prevent bad things from happening. And the bad actors are really good at finding out, well, which of these controls are typically not configured correctly or are easy to exploit that we can get inside and then execute our ransomware attack? 

Bob Maley: And, you know, we see that - that's how we've produced our ransomware susceptibility index. We kind of think just like the bad actors. We know what they look for. We know how they try to get in. We know the things that make it easy to do, and we do a quantitative assessment of that and produce the RSI. And that's a probability that a company is going to become a victim to ransomware in the near future. And we saw - I think it was about 20% of the DIB was susceptible. 

Dave Bittner: Now, based on the information that you've gathered here, what would your recommendations be for these organizations to better protect themselves? 

Bob Maley: Well, I would say they should follow the advice of the CISA. There is a great website called the - it's stopransomware.org - that they produced. And there are clear directions on what companies - whether it's in the DIB or anywhere else - should be doing to stop ransomware. 

Bob Maley: Now, to be very clear, the information that they're giving is not brand new. It's not something that they just came up with. These are guidance and instructional documents that they have been producing over the last decade. It's just that companies don't seem to want to follow the advice and do the needful things to protect themselves. 

Dave Bittner: How does the defense industrial base do compared to other verticals? Where do they rate? 

Bob Maley: Well, we've done a number of verticals. And not surprising, they're about the same as everybody else, all the other different verticals. I think we have a system-wide problem - not just defense companies, but companies in general - with these issues that have - just for years that have been ignored simply because, well, nothing's happened. So we really don't need to do anything. But obviously now things are happening and it's becoming more high-profile. 

Dave Bittner: It strikes me that that is really an overall dilemma that a lot of folks face in cybersecurity, which is, you know, there's always money for cleaning up the mess, but it's hard sometimes, I imagine, to report back to the board and say, hey, we spent all this money and, hey, guess what. Nothing happened. 

Bob Maley: Exactly. That's why there's a process. It's called FAIR - factor analysis of information risk. It is an open-source product that's been developed by the FAIR Institute that allows you to look at cyber controls and analyze them to see how much they can reduce that financial impact. So essentially, it gives you a return on investment. 

Bob Maley: You know, back in the day - I've been doing cybersecurity a long time, where there really wasn't - there wasn't a clear and easy way to show, here's the ROI for giving me this budget money to do these things. It was thought more of as an insurance policy, that if you could show, well, here's what the worst-case scenario - this might happen - and I kind of call it FUD - fear, uncertainty and doubt - and you could get the money. But there's then no real way to show, was that money spent effectively because you don't know, did it stop something, or did you just not get hit yet? 

Bob Maley: So FAIR is a quantitative process that cybersecurity professionals can actually use to produce, well, here's the probable financial impact of this particular threat if it happens in the next 12 months. And here, if we spend X amount of dollars to add this additional control or do something different, here's the difference. So it turns it from a technical conversation into a business conversation. And a lot of Fortune 1000 companies are using FAIR now. It's a real important tool for the cyber community to embrace. 

Dave Bittner: That's Bob Maley from Black Kite. 

Dave Bittner: And I'm pleased to be joined once again by Chris Novak. He is the global director of the Threat Research Advisory Center with Verizon. Chris, it's always great to have you back. You know, I've been seeing folks talking about PCI 4.0 on the horizon here. Want to touch base with you about it. How's this coming on your radar? 

Chris Novak: Yeah. Thanks, Dave. Always a pleasure to be here. You know, it's coming on our radar pretty big and bright. You know, the new standard that'll be coming out here, it's probably the most significant departure from, you know, what organizations have been used to in the past. You know, I think it's an important topic to discuss just as, you know, everyone kind of needs to get prepared for, you know, those changes ahead. You know, what does the new standard mean for them, and how do you not get surprised by it, right? Nobody wants to be faced with a deadline looming and then not being ready with, you know, appropriate changes and controls and such. 

Dave Bittner: Well, before we jump into some of the specifics of this latest version here, can you give us a little overview of what exactly we're talking about here, who this affects? 

Chris Novak: Sure, yeah. Great point. So PCI - Payment Card Industry - DSS - Data Security Standard - pretty much if you think about it as the standard globally for securing payment card information. So if you're in an industry that deals with credit cards, debit cards and the like pretty much anywhere in the world, the standard probably touches your business. And for now going on, you know, well over a decade, this has been the standard that, you know, the MasterCards, the Visas, the American Expresses of the world and so on have required organizations to comply with in order to, you know, achieve security of kind of the system or the community that deals with payment card transactions, you know, ensuring that there is confidence in the system so that people will be comfortable using and relying on their payment cards. 

Dave Bittner: And so where do we stand right now? 

Chris Novak: So right now, we're - PCI 4.0 will be the 10th addition of the PCI standard. Over the course of years now, this has kind of evolved already. So I mentioned this is 4.0. There's been a lot of, you know, minor releases as well as some major releases during that time. But the first iteration of the report - actually the first iteration of the standard actually came out in 2004, which is pretty wild. That was the 1.0. 

Chris Novak: And so, you know, now, ultimately what the PCI counseling aims to do by evolving their standard is keeping up with the changes in the way both threat actors operate, but also changes in the way business operates. There are new technologies and ways of doing business. And, I mean, the pandemic has changed lots of things for lots of organizations. You hear so many organizations talking about their digital transformations, a large shift towards things like e-commerce, which also changes the way in which payment cards may be transacted. So it's important that things like cloud technologies and other changes in the payment security industry are considered in new versions of the standard. 

Dave Bittner: So what are some of the specific things that we're going to see with version 4? 

Chris Novak: Sure. I'd say that probably some of the biggest things organizations will see as being different is that, you know, it doesn't necessarily alter the fundamental structure of the standard. So if you're used to the 12 kind of key macro requirements, that still exists. But the new version now enacts multiple changes to reflect things like moving from very prescriptive controls to actually now giving organizations a bit more flexibility in actually how they implement the controls. So kind of think of it as moving from, thou shall do A, B and C, to now moving towards a model where organizations can follow a, you must achieve a certain level of security, or your control must meet a certain intent. But the actual way you go about it may differ from organization to organization. 

Chris Novak: And I think, you know, this is an important kind of shift in the landscape. I think the earlier versions of PCI were prescriptive because, honestly, industry maturity was not really there yet. A lot of organizations really were not doing something unless they were required to do it. Now, I think we've seen a big sea change in organizations actually wanting to be secure and now actually wanting to take more ownership and control over how they actually get there. 

Chris Novak: And so this change actually, I think, allows, you know, if you have a hundred different organizations, the way they may actually get to achieving their compliance may all vary differently. But the goal is, at the end of the day, they still meet that same bar or level that PCI requires. 

Dave Bittner: Are there any specific security enhancements that are part of the latest standard? 

Chris Novak: Yeah, so I'd say some of the biggest things that people will probably notice are going to be targeted around things like cloud and kind of as-a-service-type offerings because so many organizations have migrated towards those types of technologies or have moved things like their payment processing and transaction handling into, say, third parties. And so there's going to be an enhancement in the controls around some of those areas that will probably be some of the newer and maybe more different areas that organizations will be needing to be mindful of. 

Dave Bittner: And what kind of timeline are we on here? 

Chris Novak: It's a great question. So this is actually expected to be released in March. So March 2022, we expect this to be released. Typically, the PCI Council gives a transition period, so it's typically looking at about a two-year period after the transition before it is now the new mandated, required standard of compliance. 

Chris Novak: And some folks may be hearing that and go, oh, two years - well, that's great. I will start looking at it in a year, a year and a half from now. My strong recommendation is, like anything, use this time to maximize the opportunity, especially if you're, you know, an organization that may have a long planning procurement strategy lifecycle. Start planning now so that when you reach that two-year point, this is more of a BAU type of thing that you've already included in your strategy, in your plan and your workflows, versus waiting until you get closer to that deadline, and now, all the sudden, you may have to make a lot more knee-jerk changes to what it is that you're trying to accomplish in order to maintain your compliance. 

Dave Bittner: All right. Well, good information, as always. Chris Novak, thanks for joining us. 

Dave Bittner: And that's the CyberWire. For links to all of today's stories, check out our daily briefing at thecyberwire.com. 

Dave Bittner: The CyberWire podcast is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliott Peltzman, Tre Hester, Brandon Karpf, Eliana White, Puru Prakash, Justin Sabie, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Gina Johnson, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Rick Howard, Peter Kilpe. And I'm Dave Bittner. Thanks for listening. We'll see you back here tomorrow.