Your risk management strategy isn’t just about what you do. It’s about what your vendors are doing, too. That means a complete information security plan requires following best practices for third-party risk management of the vendors you rely upon. Sometimes you can simply review reports that the third parties send you. Sometimes you have to create custom questionnaires to address your specific concerns. And sometimes you have to ask hard questions to cut through the haze of what your vendors are really saying about their security posture.
This blog highlights best practices our consultants have identified when performing third-party risk assessments on the businesses that help keep you in business.
To protect all parties, always start by signing a mutual non-disclosure agreement with every vendor before asking them to answer your questions or send you copies of reports on their information security policies.
Then you can move on to asking for copies of reports provided by outside assessors. Here are some reports that companies commonly request to support a risk assessment on a potential or current vendor. (Of course, each of these won’t be available for every vendor.):
In addition to the reports above, you may decide that vendors should complete a custom security questionnaire created by your company. Common questions on these questionnaires include:
Your job isn’t done just because a vendor returned the form you requested. A qualified member of your team needs to review the answers to ensure that the questions were answered thoroughly and that the answers meet your expectations. An experienced reviewer will be able to spot answers that are overly vague, sound misinformed or deflect attention from issues that the vendor doesn’t really want to address.
This blog provides tips on what you should look for when reviewing a third-party report.
Don’t be afraid to go back with more questions. Your goal isn’t simply to have a completed questionnaire on file for the vendor. You need assurance that the vendor’s controls are adequate and that risks are managed properly.
Here are two areas where Pratum commonly sees red flags on third-party risk assessments:
You should be especially vigilant about responses from vendors that provide solutions based on a cloud-vendor’s infrastructure. Many organizations don’t fully understand the shared responsibilities inherent to working with cloud providers.
Vendors need to understand that your risk assessment includes their controls, not just the controls at the cloud provider. For example, a vendor may just say, “Our hosting provider is AWS, and they have a SOC 2®.” That’s not good enough. While the cloud provider’s controls are certainly relevant, they don’t cover all of your concerns. We have seen plenty of vendors using insecure workloads because of misconfiguration or other issues.
This problem may even pop up when you ask about physical security. The vendor may dodge this question by stating, “We are not allowed access to AWS datacenters.” That’s probably true. But to assess the vendor’s risk posture, you need to know about the physical security controls employed at the vendor’s facilities.
For a detailed guide to getting started on a third-party risk management program, see this summary of a recent presentation at Pratum’s Secure Iowa conference. For advice on customizing a program for your specific situation, contact us to talk to a consultant today.
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.
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.
Get our blog articles delivered
to your inbox: