Are tech companies at fault for the addictive nature of social media? What to expect from the White House’s cybersecurity strategy. DHS gives CISA thumbs-up for Log4j response.

At a glance.

• Are tech companies at fault for the addictive nature of social media?
• What to expect from the White House’s cybersecurity strategy. 
• DHS gives CISA thumbs-up for Log4j response.

Are tech companies at fault for the addictive nature of social media?

The New York Law Journal examines how lawsuits against social media companies are utilizing product liability claims as a way to bypass Section 230 of the Communications Decency Act, an immunity statute that protects tech companies from being sued as third-party publishers. Instead of focusing on a company’s alleged negligence, an increasing number of plaintiffs are alleging that these platforms intentionally attempt to addict users. Carrie Goldberg of C.A. Goldberg in New York explains, “I expect this approach to be the new avenue for holding tech companies liable for the damages that they’re inflicting on their users…More and more law firms are recognizing the viability of this legal theory, and courts are catching on.” Law firm Beasley Allen has filed about fifteen suits against Meta, Joseph VanZandt, an attorney with the firm, says there are strong parallels between these cases and litigation involving addictive drugs like tobacco. 

What to expect from the White House’s cybersecurity strategy. 

CyberScoop spoke with three sources who say an upcoming White House strategy on cybersecurity, the first released since the Trump administration, will give the federal government more power in protecting the country’s digital infrastructure from cyberattacks. “They’re taking a look at how to more forcefully use government power in the cyber arena. The sense is that we’ve not used the full breadth and scope of US power to address some of the underlying systemic cyber issues,” said one source, who wished to remain anonymous. The Office of the National Cyber Director (ONCD) is in charge of the drafting of the strategy, expected to be complete in September, and according to the sources, ONCD has shared its ideas with industry experts and requested feedback. Topics addressed include countering digital authoritarianism in countries like China and Russia, strengthening the US cybersecurity workforce, the shared cybersecurity responsibility of the tech industry and government, information sharing, and defending the IT systems of federal agencies and departments. 

DHS gives CISA thumbs-up for Log4j response.

The US Homeland Security Department’s Cyber Safety Review Board yesterday released its inaugural report, an investigation of the Cybersecurity and Infrastructure Security Agency’s response to the Log4j bug. As the Washington Post explains, the vulnerability, discovered in December 2021, impacts the extremely popular Java-based logging utility, allowing attackers to hijack everything from industrial control systems to consumer electronics. The Federal News Network reports that the panel gave CISA a positive review, determining that the vulnerability did not result in any “significant" attacks on the nation’s critical infrastructure systems. CBS News notes that Chair Rob Silvers, the undersecretary for policy at DHS, and Vice Chair Heather Adkins, senior director of security engineering at Google, headed up the 15-member panel established last year as part of President Biden’s executive order on cybersecurity, and the report is the product of nearly five months of investigation. 

The board conducted interviews with approximately eighty organizations and experts in industry, foreign government, and security, including representatives from the Chinese government, since it was an engineer at Chinese cloud provider Alibaba that first detected the flaw. As the Record by Recorded Future adds, the panel confirmed that Alibaba reported the vulnerability to the Chinese Ministry of Industry and Information Technology more than two weeks after it was discovered, but Beijing declined to answer questions about possible sanctions against the company. Silvers stated, “This lack of transparency heightened the board’s concern that China’s regulatory regime will discourage network defenders from engaging in beneficial vulnerability disclosure activity with software developers.” CyberScoop explains, the board found no evidence that China used its advanced knowledge of the weakness to exploit networks. 

Despite CISA’s strong response, the Register notes the board called Log4j an “endemic vulnerability,” stating that organizations will likely have to endure risks associated with the bug for "a decade or longer." Silvers stated, “Log4j is one of the most serious software vulnerabilities in history…This event is not over.” The report included nineteen recommendations for organizations going forward. Some are common sense measures, like proactive system monitoring and regular system upgrades. The panel also recommends taking action to secure the larger open-source software ecosystem, highlighting organizations like OpenSSF, Open Web Application Security Program, and The Open Source Software Security Mobilization Plan that provide services to assess project risk.

We received a number of comments from industry on the report. Google, which contributed to the study, issued this statement by VP of Security Royal Hansen: “Google was honored to participate in the development of the Cyber Safety Review Board’s first report on the log4j vulnerabilities and share our own experiences in responding to this and other incidents. We support the report’s findings and look forward to continuing to partner with the Department, industry stakeholders, and other government entities around the world to strengthen our security ecosystem.”

Thomas Pace, a US Department of Energy veteran and currently CEO of NetRise, looked at the implications of the vulnerability for critical infrastructure operators: "ICS operators rarely know what software is running on their XIoT devices, let alone know if there are instances of Log4j that can be exploited. Just because these attacks have not been detected does not mean that they haven't happened. We know for a fact that threat actors are exploiting known vulnerabilities across industries. Critical infrastructure is no different."

Terry Olaes, Director of Sales Engineering at Skybox, points out that threat actors were quick to operationalize Log4j exploits, and that the threat won't be going away any time soon:

“Cybercriminals were swift to weaponize this critical remote code execution vulnerability when it was disclosed back in December, with far-reaching consequences. A CISA official estimated that hundreds of millions of devices are likely affected due to its widespread use. Skybox Research Lab, has been tracking Log4j since the exploit was publicly released in December 2021, and while the findings of the report are unfortunate, they are not surprising given Log4j’s widespread use across market-leading vendors. Log4j threats expose victims that lack mature cybersecurity risk models to attacks that have remote code execution (RCE) vectors like ransomware, and there will likely be many attacks associated with this vulnerability for years to come.

"In the years ahead, threat actors will innovate new and creative ways to exploit common tools like Log4j. As a result, preventing breaches requires immediately minimizing your exposure through smart and targeted mitigation. For a widespread vulnerability like Log4j, patching all of the instances isn’t practical. Not only is it time-consuming, it’s also hugely costly as well. History shows that the ‘patch everything’ strategy is a monumental waste of effort due to the fact that typically it’s a very small subset of devices that are actually exposed to the attack itself. That is why it is crucial to take a more proactive approach to vulnerability management by learning to identify and prioritize exposed vulnerabilities across the entire threat landscape.

"Organizations should ensure they have solutions capable of quantifying the business impact of cyber risks into economic impact. This will help them identify and prioritize the most critical threats based on the size of the financial impact, among other risk analyses such as exposure-based risk scores. Organizations should also emphasize exposure analysis, which identifies exploitable vulnerabilities and correlates data with an organization’s network configurations and security controls to determine if a system is vulnerable to a cyberattack. This strategy includes path analysis, which determines which attack vectors or network paths could be used to access vulnerable systems. They must also enhance the maturity of their vulnerability management programs to ensure they can quickly discover whether or not a vulnerability impacts them and how urgent it is to remediate.”

Dan Murphy, Distinguished Architect at Invicti, reminds CISOs that their operators may be unaware of the ways in which the vulnerability may exist in their systems: "The Cyber Safety Review Board's assessment of lower tier Log4j exploits in critical infrastructure is one piece of information, but CISOs need to take into account that critical infrastructure operators may not know the number of Log4j instances within their software supply chain and if those instances have been exploited. As we have seen in financial services and other more mature sectors, Log4j is difficult to detect and still at risk for exploit by attackers and nation-state threat actors. It's important for infrastructure operators to continue to keep their eyes on Log4j as it could have potential to be exploited."

Roger Grimes, data-driven defense evangelist at KnowBe4, thinks the report gives a good, perspicuous overview of the risks and remediations:

"This is an excellent report and it makes good recommendations across the board. There are no surprises and things that have not been said many times before by other groups, but it's great to see them all collected into one report. However, the most welcome recommendations include improving the default security and health of the open source software ecosystem, including recommending that developers get trained in secure software development. We know for sure that one of the single best things we can do to improve software security is to make sure all developers have training in common security bugs and how to avoid them. Yet, very few universities and programming schools give developers any training in secure software development, much less make it a key part of their curriculum. Why do we still have an escalating number of software vulnerabilities...over 20,000 publicly identified bugs last year? Because we don't teach developers how to avoid those bugs. We get what we sow. In this case, DHS is saying we need to fix that, in open source software as well."

Pravin Madhani, CEO and Co-Founder of K2 Cyber Security, sees a continuing scramble to address the problem, and points to the importance of understanding how your applications actually work:

“Security teams are still racing to patch and protect their enterprise apps and services from Log4j, underscoring the security risks associated with open source software, and the challenges of protecting web applications against zero day attacks. Vulnerabilities in web applications are the leading cause of high-profile breaches and defending against them should be a key part of every enterprise’s security strategy.

"As the Cyber Safety Review Board articulated, there are a number of basic steps that should be taken to protect against vulnerabilities, including security testing for vulnerabilities earlier in the development cycle, making sure that software and operating systems are kept up to date and patched, and utilizing a multi-layered, defense-in-depth approach.

"The most significant protection against zero day and other attacks comes from using security technologies that sit closer to, and understand best, how your application works.  Security solutions like runtime application protection provide the context, visibility and control to identify and block new zero day attacks launched against your applications. The ability to block zero-day attacks is particularly important as it offers protection while the software is being patched, which can be quite a lengthy and involved process.”

And, finally, Chris Clements, vice president of solutions architecture at Cerberus Sentinel, sees another object lesson in third-party risk:

“The Log4j incident demonstrates just how at risk thousands of organizations are, due to uncontrolled third-party software dependencies they may not even be aware that they are using. It’s a real wake up call for both developers and end users that upstream changes from developers not under your control can pose significant risk to your products and operations. Worse, in such situations, vulnerable organizations can be left with little recourse for remediation unless they have the development capabilities to correct the vulnerability themselves. In a sense, we are lucky that the Log4j issue had an almost perfect storm of remediation response. The developers themselves:

• "Were still actively maintaining the project
• "Quickly recognized the seriousness of the issue
• "Dedicated themselves to urgently correcting the issue

"Had any of these items not been the case, vulnerable products and organizations could have had little means of self-correcting the problem. The thing is, curative actions by the Log4j development team mostly happened out of the goodness of their hearts. As free and open-source software, they were likely under no obligation at all to fix the issue had they not wanted to. This type of uncontrolled dependency should be a major concern for product developers looking to avoid catastrophic situations in the future either from dependency developer mistakes or even directly malicious actions like purposefully introducing vulnerabilities or backdoors.”