Every organization is unique, so the risks they each face are not the same. In order to make a plan of action to protect your business, you need to first understand where the threats against you are. Once you know those risks and gaps, you can start to identify the likelihood of them occurring and the impact they could have on your organization.
Because of this, an information security risk assessment forms the cornerstone of any cybersecurity policy. Clear risk knowledge is crucial when making risk-based decisions for your company. Without full knowledge of where, how, and why a threat could occur, you won’t be able to stop it. That’s why understanding likelihood and impact for any given threat are both important factors in the risk assessment process.
Pratum’s consultants perform information security risk assessments using a clear four-step process based on a clear formula. Start thinking about your risks by reviewing the basic threat likelihood/impact formula below.
You don’t need a complex system in order to improve or support your organization’s security environment. However, your organization’s leaders need tools that show them where to spend time and resources in order to reduce potential risks to the company. That’s how risk assessments can shed light on the key factors in this decision-making process.
A better understanding of the system also helps out other members of your staff. Members of the IT department need to know what products and processes to put into place in order to limit potential risks. The more knowledge they have, the better they can work with leadership to determine and address security concerns. Sharing the risk assessment results with members of the IT team will help them understand where they’ll get the most from efforts to reduce risks.
The standard described in NIST SP 800-53 implies that a realistic assessment of risk requires an understanding of these areas:
For handling the most basic level of risk assessment, risk managers can follow this simple formula:
Risk = (Threat x Vulnerabilities) x Impact
The first part of the formula (Threats x Vulnerabilities) identifies the likelihood of a risk. For example, if there’s a known security flaw in older versions of software you use, there’s the threat of hackers exploiting that particular vulnerability to compromise your system. But if you’ve applied the latest software patches that fix the problem, then the vulnerability cannot be exploited, and the threat has been eliminated.
Impact measures how much disruption you’ll face if the threat actually occurs. Combining likelihood and impact produces a residual risk rating of Low, Medium or High. Each organization’s residual risk rating may differ based on the likelihood and impact that each control deficiency introduces.
You could also represent this concept with a simple chart like this one:
For example, let’s consider the risk of a hacker getting access to a folder containing all of your public-facing marketing materials. That event may have a medium likelihood, but it has a very low impact. Those materials are already publicly available on your website, etc., so unauthorized access to them does no harm. That risk gets a Low rating.
But the formula changes if the risk is an employee in the Accounts Payable department clicking a phishing link. There’s at least a medium likelihood of one of those employees making this mistake. And the impact would be very high if a hacker got access to a user account that controls financial transactions. That risk gets a High rating.
Keep in mind that a very High impact rating could make a risk a top priority, even if it has a low likelihood. If a breach could shut down a hospital’s life-support equipment, for example, that risk obviously deserves serious consideration on your priority list.
If you’d like to read detailed guidelines on how to rate risks by various factors, consult NIST SP 800-30.
Now that you know the formulas for determining likelihood and impact during a risk assessment, it’s time to focus on specific risks.
1. Inherent risk – This is the risk level and exposure your system faces without taking into account any mitigating measures or controls that are actively in place. Where is your system at its weakest when no other security measures are in place to protect them? Which risks deserve the highest rating based on their likelihood and potential impact?
2. Residual risk – An area with a higher likelihood and impact of a threat on the organization, from an inherent risk level, may need additional controls to reduce the level of risk to an acceptable level. After you apply those controls, you are left with what we call “residual risk.” If the residual risk level after mitigating controls is still higher than you prefer, then additional risk management measures and techniques should be introduced.
Mitigating measures you may apply include:
Reading through how to determine likelihood and impact can help you understand first steps in your risk assessment process. But you’ll probably still need help from cybersecurity consultants to carry out a full assessment. These experts look over a number of key factors you may not have considered.
Cybersecurity consultants analyze your organization’s structure, policies, standards, technology, architecture, controls, and more to determine the likelihood and impact of potential risks. They will also review your current controls and evaluate their effectiveness.
For example, a financial management company turned to Pratum when it realized that investors were choosing portfolio managers based, in part, on a company’s strength of cybersecurity. The management firm asked Pratum’s consultants to take a deep dive into its administrative, physical and technical controls. Pratum guided the company in developing a clear summary of its high and moderate risks along with recommendations for remediation. (You can read about the entire process in this case study.)
Consultants also assess any gaps between your current security posture and where you want your organization to be. A core part of that process will be determining accountability and assigning risk ownership at the appropriate level and to the appropriate team. It’s important to have the right security measures in the right hands.
The end goal is to get to a level of risk that is satisfactory to your management team. It’s important to evaluate and be aware of the risk in your environment so you can implement appropriate controls to mitigate this risk and secure sensitive information. Evaluating risk means understanding the biggest factors of any security threat, likelihood and impact.
If you’re looking for a security partner to address your risk assessment needs, please contact a Pratum Consultant at any time for more details on ways you can secure your business.
Hackers are compromising systems worldwide using the Java Log4j vulnerability discovered late last week.
Every IT leader should immediately assess their system’s Log4j vulnerability and take proper remediation steps. The information below summarizes what you should do about this developing situation.
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 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.