Pratum Blog

Pratum vCISO Jeff Hudgens with quote

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.

Reports to Request From Your Partners

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.):

  • SOC 2® Report – This report issued by a Certified Public Accountant delivers an unbiased opinion on an organization’s security policies (Type I) and their effectiveness over a period of time (Type II).
  • ISO 27001 certification – This provides an internationally recognized standard for measuring information security.
  • PCI DSS self-assessment questionnaire/attestation of compliance – The Payment Card Industry (PCI) Data Security Standard (DSS) is intended to ensure that an organization handles credit card data properly. For smaller merchants, this is a self-assessment.
  • HITRUST certification –This standard from the Health Information Trust Alliance provides a security review matrix recognized throughout the healthcare industry.
  • Public-facing penetration testing report – Here, a third party provides a high-level report on the number of vulnerabilities they discovered when hired to simulate a hacker’s attack on an organization’s system. Note that penetration tests vary widely in quality and depth, so you should read the report carefully to ensure that it addresses your concerns. (This blog explains what to look for in a quality pen test.)

Questions to Ask Your Partners

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:

  • How do you encrypt data?
  • How often do you perform vulnerability scans and penetration tests?
  • What identity and access management policies/tools do you use?
  • How do you secure your physical facility?
  • Have you ever suffered a data breach? What happened?

When to Be Skeptical of the Answers

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:

  • The vendor indicates it “does not meet criteria that require a SOC 2® report.” We often hear this from vendors that actually DO provide a service/solution that meets the intent for having a SOC 2® audit performed.
  • The vendor indicates that their solution utilizes a cloud provider, such as AWS, and then states that AWS has security certifications that mean the vendor is also secure. As the following section explains, counting on AWS or any other cloud provider for security controls usually isn’t sufficient.

Special Concerns About Cloud Environments

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.

Information Security Risk Matrix

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.

Keep It Simple

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.

Formula to Determine Risk Likelihood and Impact

The standard described in NIST SP 800-53 implies that a realistic assessment of risk requires an understanding of these areas:

  • Threats to an organization
  • Potential vulnerabilities within the organization
  • Likelihood and impacts of successfully exploiting the vulnerabilities with those threats

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:

Risk Likelihood Chart showing impact and risk

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.

Drilling Down on Specific Residual Risk

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:

  • Avoidance – Elimination of the cause of the risk. You could, for example, prevent employees from accessing certain parts of your system on mobile devices.
  • Mitigation – Reduction of the probability of a risk’s occurrence or of its impact. Adding multifactor authentication, for example, greatly reduces the probability of a hacker getting into a user’s account.
  • Transfer – Sharing of risk with partners, such as through insurance or other ventures.
  • Acceptance – Formal acknowledgement of the presence of risk with a commitment to monitor it.

Finding Help When You Need It

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.

End Goal: An Acceptable Level of Risk

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.

Jave Log4j Vuln Code

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.

What is the Vulnerability?

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. That means a long list of big-name companies and software providers are affected, including Amazon Web Services (AWS), IBM, Oracle, Cisco, Apple, Minecraft, ConnectWise and many others.

 

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.

 

How Do I Update Apache?

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.

What Other Applications Are Vulnerable?

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.

 

How Do I Check for the Vulnerability on My System? 

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: DNS Logging Server Code If the server requests a DNS lookup, it should be logged with the provider.

What Should I Do To Protect My System?

In addition to upgrading your version of Apache and installing the patches that software vendors provide, CISA also recommended these three additional steps: 

  • Enumerate any external facing devices that have log4j installed. 
  • Make sure that your SOC is actioning every single alert on the devices that fall into the category above.
  • Install a web application firewall (WAF) with rules that automatically update so that your SOC is able to concentrate on fewer alerts. 

What if I Can’t Update or The Application Vendor Hasn’t Updated Their Software Yet? 

Adding the JVM flag JVM Flag Code 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.

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.