3rd Party Risk Management , Application Security , Critical Infrastructure Security
Log4j Flaw: Healthcare Sector Warned to Take ActionExperts: Extent of Impact Uncertain, But Entities Must Assess, Mitigate Risk
Healthcare sector organizations, like entities across other industries, are being warned by federal authorities and others to carefully assess how the recently identified severe remote code execution vulnerability in the Apache Log4j Java logging library might affect their environments, and then to swiftly address the issue.
See Also: LIVE Webinar | Stop, Drop (a Table) & Roll: An SQL Highlight Discussion
The Department of Health and Human Service's Health Sector Cybersecurity Coordination Center, or HC3, in an alert issued Dec. 10 advised healthcare and public health organizations to survey their infrastructure to ensure they are not running vulnerable versions of Log4j.
"Any vulnerable systems should be upgraded, and a full investigation of the enterprise network should commence to identify possible exploitation if a vulnerable version is identified," the advisory says.
The exact extent to which Log4j is deployed throughout the health sector is unknown, HC3 says. "It’s a common application, utilized by many enterprise and cloud applications, including several large and well-known vendors. Therefore, it’s highly likely that the health sector is impacted by this vulnerability, and possibly to a large-scale extent."
HC3 recommends treating the vulnerability as a high priority, the advisory says.
Maintained by the nonprofit Apache Software Foundation, open-source Log4j provides logging capabilities for Java applications and is widely used, including for Apache web server software.
The flaw is present in the Apache Log4j library, versions 2.0-beta9 to 2.14.1, and the U.S. Cybersecurity and Infrastructure Security Agency in a Dec. 10 alert also advised organizations across all sectors that they should approach fixing it with the highest priority.
On Friday, the Food and Drug Administration issued an alert about the Log4j flaw, as well, directed at medical device makers.
"Manufacturers should assess whether they are affected by the vulnerability, evaluate the risk, and develop remediation actions. As Apache Log4j is broadly used across software, applications, and services, medical device manufacturers should also evaluate whether third-party software components or services used in or with their medical device may use the affected software and follow the above process to assess the device impact," the FDA says.
Manufacturers who may be affected by the Log4j vulnerability should communicate with their customers and coordinate with CISA, the FDA urges. "As this is an ongoing and still evolving issue, we also recommend continued vigilance and response to ensure medical devices are appropriately secured."
HHS' Office for Civil Rights, which enforces HIPAA, on Tuesday also issued an advisory based on CISA's alert.
The Log4j flaw is "a massive issue across the board," says Benjamin Denkers, chief innovation officer at privacy and security consultancy CynergisTek.
"Every industry has been spending the last week trying to identify and remediate. The ease of exploitation for this vulnerability doesn’t require a high level of sophistication. Successful exploitation allows for remote code execution, which give attackers a foothold into the environment."
"This is a serious issue and it cannot be downplayed how quickly organizations need to respond," says Erik Decker, CISO of Utah-based healthcare delivery system Intermountain Healthcare and co-chair of a HHS cybersecurity advisory task force. "It allows for a bad actor to execute remote code against servers, or downstream servers, that are vulnerable over the internet. Bad actors use vulnerabilities like these as their first step in large-scale compromises." he says.
The intention could be data theft, ransomware, or intellectual property theft, he says. "It was reported that the Conti ransomware gang is now exploiting this vulnerability to release ransomware on internal systems."
For healthcare sector entities, Log4j would be part of a larger application implementation, Denkers says. "You wouldn’t necessarily know it was installed, as it could be one of hundreds of potential packages being utilized for that application to run."
Christopher Frenz, assistant vice president of IT security of Mount Sinai South Nassau hospital in Oceanside, New York, offers a similar assessment.
"Because Log4j is a popular software library used in a plethora of applications that also means there are an abundance of applications that are potentially vulnerable to exploit," he says.
"This widespread use means there is not only a large potential attack surface, but a challenge for many organizations to even locate all the points at which they are vulnerable."
CISA is compiling a list of vulnerable applications that organizations can begin to use to assess where they might have the vulnerability, but many medical software vendors and medical device manufacturers with vulnerable applications are not yet on the list, Frenz says.
Decker says entities could have Log4J in their enterprises and not realize it because it is "difficult to discover with the current vulnerability scanners," he says.
"Many vendors do not allow for administrative access to their appliances. We must rely on their vulnerability disclosure process to know if the software is vulnerable or not. Do not assume just because your scanning doesn’t detect the vulnerability that you have no instances of it," he says.
Frenz says he has been "a long-time proponent of healthcare organizations requesting a software bill of materials for applications and devices that they onboard, and this vulnerability clearly illustrates why this is critical."
A Software Bill of Materials, or SBOM, for every application and device would make identifying where this vulnerability existed much easier, he says.
Healthcare entities must assess whether they have been affected by the Log4j vulnerability, but should also put the problem into proper perspective, some experts urge. "Bottom line: Log4j is ubiquitous throughout IT applications and it is not a threat specific to health," says Denise Anderson, president of the Health Information Sharing and Analysis Center, in a statement to Information Security Media Group.
"As always, there is a need to overlook a lot of the 'noise' and Fear, Uncertainty, Doubt - FUD - such as 800,000 'attacks' being less about actual attacks/exploits and more about various people, including researchers, scanning for vulnerable devices," she says, referring to various security vendors' reports this week in which they claim to have already blocked hundreds of thousands of attack attempts exploiting the Log4j flaw.
"The basic mitigation strategy is to upgrade to version 2.16.0 and at a minimum to 2.15.0 as soon as possible - if not immediately - when some appliance in an environment is confirmed to be exploitable," she says. H-ISAC also issued a bulletin about the vulnerability to the health sector on Dec. 10.
The H-ISAC advisory notes that some researchers suspect that some ransomware actors have already begun leveraging the vulnerability for attacks. (See: Nation-State Attackers Wielding Log4j).
Healthcare organizations should make an effort to identify vulnerable applications and patch Log4j vulnerabilities wherever possible, particularly with any vulnerable application that is public-facing, Frenz says.
"Given the breadth of applications this vulnerability is likely present in, it is also critical that healthcare organizations consider that they may not be able to readily discover and patch every possible instance of this vulnerability," he says.
Organizations need to also consider implementing compensating controls that will keep them protected in the event an unidentified vulnerable system or an as-yet-unpatched system becomes the target of an attack, he says.
"It may be advisable to consider using threat intelligence to block known attacker IPs, using a web application firewall to filter attack attempts, network segmentation of systems, or consider implementing egress filtering to stop the outbound LDAP [Lightweight Directory Access Protocol] connections that exploitation commonly requires as some example of compensating controls," Frenz says.
"While these and other controls may not provide perfect protection, they help to mitigate the risk associated with the attack as vulnerable systems are likely to exist in every organization for the foreseeable future."
Denkers warns that organizations not only need to be concerned with where they might have instances in their own environment, but also about partners and vendors who are just as likely to be affected.
He suggests that healthcare sector entities have their security operations center on "high alert" and stay apprised of Log4j 's indicators of compromise.
Also, entities should identify all vulnerabilities and understand the attack surface throughout the organization. "This will be done through a mixture of vulnerability scanning, validating with remote users, and checking with affiliates to ensure vulnerable systems have been identified and properly patched," he says.
Denkers also suggests entities consider multiple methods of identifying Log4j instances. "The goal here is to help organizations understand the complete picture and avoid false negatives," he says.
Entities should also use web application firewalls to help filter malicious requests, according to Denkers. "If Log4j was found, conduct a compromise assessment to ensure the systems in question weren’t exploited."