IT and cybersecurity teams saw their priorities immediately reordered last December when hackers began widespread exploitation of a vulnerability discovered in Java Log4j. Since news of the vulnerability broke, teams scrambled to evaluate how the vulnerability affected their systems and to deploy the required patches. The information below summarizes the latest information on the breach.
If you need help identifying and fixing your vulnerability (or if you have experienced a breach related to Log4j), contact Pratum’s incident response team immediately via our website or by calling 515-965-3756.
On December 10, news broke about a critical remote code execution (RCE) vulnerability in the Java library called Log4j, which is part of open-source code maintained by the Apache Software Foundation. It is widely used by enterprise software developers.
Hackers immediately began scanning the Internet for vulnerable systems and launching hundreds of attempts per minute to exploit the vulnerability. On affected systems, hackers could gain the ability to remotely execute code and compromise or export sensitive data. You can read Apache’s advisory on the vulnerability here.
Any Log4j-core version from 2.0-beta9 to 2.14.1 is considered vulnerable and should be updated to 2.16.0. Update your version of Apache to 2.15.0 here to close the vulnerability. The log4j issue (also called CVE-2021-44228 or Log4Shell) was patched in the update.
Log4j version 2.16.0 also is available. This version disables the JNDI functionality by default and removes messages lookups. While some software supports 2.16.0, other software may still rely on the JNDI functionality. In that case, you should use version 2.15.0. Before updating, ensure that the correct patched version is selected.
A new vulnerability (CVE-2021-44832) released on December 28, 2021, affects the most recent release of Log4j, version 2.17.0. While rated a CVSS of 6.6, it should be noted that this vulnerability can allow remote code execution in systems when the Log4j configuration file is loaded from a remote location.
Due to the lower CVSS score and higher complexity requirements for exploitation, fewer users may be impacted. However, if possible, users should update to version 2.17.1 that patches this vulnerability.
Updating your version of Apache won’t address the vulnerabilities in the numerous applications that use the Apache library. You’ll need to update each of those applications as their developers release updates. Expect numerous communications from software vendors who are updating their products in order to close the vulnerability. You can review a list of known software vulnerabilities at this site.
Many older applications that rely on the Java runtime are potentially vulnerable. This can include web frontends, servers and other frameworks that use the Log4j library to log data. Even if the main application is not Java-based, it may use Log4j for logging. Plan on applying multiple upgrades and patches to your system.
Within hours of the vulnerability’s discovery, Pratum’s Security Operations Center (SOC) installed new detections/mitigations to protect the systems of our Extended Detection and Response (XDR) customers. The new rules created by our analysts detect attempted exploitation; block malicious Java processes; block executable files unless they meet specific criteria; and more. We are also actively processing and adding additional Indicators of Compromise as they are disseminated through various channels.
You should run a vulnerability scan on your system. You also can test it by using a local or third-party DNS logging service. Submit a request with the following: If the server requests a DNS lookup, it should be logged with the provider.
In addition to upgrading your version of Apache and installing the patches that software vendors provide, CISA also recommended these three additional steps:
Adding the JVM flag can prevent the vulnerability in most vulnerable Java versions.
Pratum’s incident response team is currently helping clients analyze and remediate their exposure to Log4j. For help with your specific situation, contact Pratum’s incident response team immediately via our website or by calling 515-965-3756. This situation is continuing to evolve, and we’ll update this blog as new information becomes available. You also should regularly check CISA’s Apache Log4j Vulnerability Guidance for new information.
If a bank or federal contractor experiences a data breach, the federal government wants to know about it—and the new Civil Cyber-Fraud Initiative has teeth to back it up.
Throughout 2021, the federal government has taken the fight to global hackers on multiple fronts, fueled by President Biden’s May 2021 executive order. Two of the latest moves are the Department of Justice’s Civil Cyber-Fraud Initiative and new FDIC rules that ramp up reporting requirements when federal contractors, federal grant recipients or banking entities experience data breaches.
This post explains what you need to know about how the Civil Cyber-Fraud Initiative and other new regulations could affect you.
A data breach affects far more than the compromised organization. In this era of heavily interconnected supply chains, a breach of a single organization can rapidly cascade into dozens of others. (This year’s Kaseya breach provided a painful example of how supply chain attacks can go global in very little time.) Through moves like the Civil Cyber-Fraud Initiative, the government wants to know when anyone handling its data or connected to its systems experiences a compromise.
Sharing breach information also lets the greater community stop bad guys more quickly. When breaches go unreported, hackers may keep using the same kind of attack on other organizations in both the public and private sectors. When you report a breach, the government can spread the word about the vulnerability exploited and the type of attack used, etc. and help others quickly harden their defenses. Shared breach information helps developers respond with the patches that close the vulnerabilities.
An FBI agent explained in one of our recent blogs that agents like companies to report even suspected attacks so that they can add the threat data to the information shared with all their offices.
The DOJ’s announcement of its new requirements also acknowledged a critical point for private companies: Companies should have incentives to invest in good information security. With new regulations built on cybersecurity best practices, the government wants to stop companies from skimping on security investments and undercutting prices from those doing the right thing.
In October, Deputy Attorney General Lisa O. Monaco announced the Civil Cyber-Fraud Initiative saying, “For too long, companies have chosen silence under the mistaken belief that it is less risky to hide a breach than to bring it forward and to report it. Well, that changes today.”
The new act’s enforcement comes via the False Claims Act, a tool that lets the feds levy fines against parties who put government programs and operations at risk through inadequate information security measures. In short, if you operate under federal contracts or receive federal grant funding, you need to be aware of the new requirements. Under this new program, firms could face government penalties if they knowingly:
Whistleblower provisions in the False Claims Act empower individuals to report any wrongdoing they know about (and gives them a chance to share in assets recovered). Based on the whistleblower empowerment and the regulations’ complexity, observers expect to see a significant whistleblowing, which is what the feds are hoping for. Violations could be as simple as, for example, falsely stating that you have a written incident response plan or system monitoring in place.
Plenty of questions remain about how the government will judge a “knowing” failure, how penalties would be assessed, how responsible a company is for its subcontractors, etc.
The FDIC issued its own new regulation about incident notification in November. The new rule requires banking organizations to notify their primary Federal regulator of any “computer-security incident” that rises to the level of “notification incident,” as soon as possible, with the window not to exceed 36 hours after discovering the incident.
In short, this regulation applies to incidents that could disrupt, degrade or impair banking operations and services.
The rule also requires notification of customers if services will be disrupted or degraded for four hours or more. The rule takes effect April 1, 2022.
Clearly, it will take time for organizations to sort through the new rules and establish policies accordingly. For help understanding how the Civil Cyber-Fraud Initiative and the new FDIC rules affect you, contact a Pratum expert.
The Defense Department recently pumped the brakes on the rollout of its much-discussed CMMC cybersecurity standard—and made significant changes that should greatly simplify compliance for private companies. But that raises plenty of questions about exactly where contractors go from here. We talked with Pratum’s Jeff Hudgens, a CMMC Registered Practitioner, for guidelines on what manufacturers, software developers and other contractors need to know about CMMC 2.0.
You should be constantly honing your cybersecurity policies as a matter of smart risk management. Doing that will help you be ready for CMMC when it comes into play.Jeff Hudgens Pratum CMMC Registered Practitioner
In 2019, the DoD began a lengthy process for beefing up security for every company in its supply chain via the Cybersecurity Maturity Model Certification (CMMC) standard. In all, about 300,000 companies face new cybersecurity compliance rules if they want to keep winning contracts from the Pentagon and its prime contractors. But, as you might expect from a massive new government program, confusion and controversy have dogged CMMC’s rollout.
In the latest move, CMMC 2.0 arrived in November with numerous adjustments handed down by the CMMC Accreditation Body (CMMC-AB).
No one really knows at this point, but no deadlines are looming. The DoD originally said some level of CMMC requirement would appear in all of its contracts by 2025. But with the release of CMMC 2.0, all of that is up in the air again. The DoD is diving into an open-ended “rulemaking process” and has dropped plans to include CMMC requirements in upcoming contracts. One thing we’re hearing is that the DoD may offer incentives to companies that voluntarily adopt CMMC guidelines, which sounds like an effort to motivate some early adopters.
The private sector pushed back heavily on the regulatory burden imposed by CMMC’s complexity. The new release makes the whole program simpler and, frankly, leaves a lot of lingering questions about how much will ever be required for DoD contractors. The DoD is making flexible implementation a key factor in the CMMC revisions.
Yes, they’ve been simplified. CMMC 1.0 included five levels that a vendor could be required to meet under any given DoD contract. CMMC 2.0 cuts the original five levels down to just three. This chart from the official federal CMMC site shows how the new levels compare to the old ones:
That’s one of the biggest changes in the new release. Under CMMC 1.0, every level required assessment by an approved third-party. But CMMC 2.0 dramatically reduces the requirements for third-party assessments. Companies pursuing contracts with a Level 1 requirement can now submit a self-assessment. At Level 2, some contracts will require third-party assessment. These moves are clearly designed to address industry complaints about increasing compliance regulations. At Level 3, the DoD intends for government assessors to review the security standards of contractors handling the most sensitive information.
You can still plan on some oversight, even when self-assessment is allowed. Companies that knowingly falsify their reporting may, for example, face false claims lawsuits from the Department of Justice.
Yes. In another concession meant to ease the compliance burden on companies, CMMC 2.0 lets companies achieve certification while still pursuing a Plan of Action and Milestones (POA&Ms) to fix any shortcomings. This eliminates the pass/fail nature of CMMC 1.0. In some circumstances, the DoD says it will even let companies apply for CMMC waivers.
CMMC 1.0 included a significant number of CMMC-specific requirements. Those are gone in version 2.0. Level 2 now mirrors the widely used NIST SP 800-171, and Level 3 will be based on a subset of NIST SP 800-172. The bottom line is that companies following industry standards should be able to achieve CMMC compliance without adopting other proprietary controls.
These changes take most of the urgency out of CMMC compliance since we have no idea when it will appear in DoD contracts. But CMMC’s requirements generally follow what the industry considers basic cybersecurity best practices. So you should be constantly honing your cybersecurity policies as a matter of smart risk management. Doing that will help you be ready for CMMC when it comes into play. And if you’re unwilling to take the supply chain security steps required to meet even CMMC Level 1, you’ll probably find that many large, private companies won’t feel safe doing business with you anyway.
Pratum’s compliance experts can help you understand the compliance requirements for your specific situation.
You also can get advice from governmental bodies tasked with helping manufacturers and other companies navigate the government procurement process. Each state has a Manufacturing Extension Partnership Center that can help you with CMMC. You can look up yours at nist.gov/mep/centers. You can also work with one of about 300 Procurement Technical Assistance Centers nationwide. You can find a nearby PTAC at aptac-us.org.
Get our blog articles delivered
to your inbox: