Ordr Announces Integration with ServiceNow Vulnerability Response Read more here!

If Ralph Waldo Emerson had been a CISO and not a poet, he might have said, “Like life, Zero Trust is not a destination, but a journey.” And he’d be right, of course. For all the love Zero Trust has gotten from zealous marketers who promise that an investment in their cybersecurity product will deliver Zero Trust, the fact is that enterprises are far too dynamic for any one product to achieve that state. In fact, Zero Trust is not a static state, but an ideal that must be as dynamic as the environment in which it prevails.

Dynamic Environment, Dynamic Tool

When Ordr talks about Zero Trust, it is within the context of the challenges of protecting organizations that are increasingly reliant on connected devices to manage and run their operations. Devices within the domains of the Internet of things (IoT), Internet of medical things (IoMT), and operational technology (OT) are, by their nature, dynamic. They connect to and disconnect from networks often, finding a home where they are needed. They move around and increase an enterprise’s attack surface as they aggregate and grow in number. That kind of changeability and complexity requires a security platform like Ordr that has the speed and intelligence to discover, identify, and secure every device operating in the network.

According to the FBI, healthcare was the industry most targeted by ransomware gangs in 2021.

This is especially important for healthcare organizations that rely on IoT, IoMT, and OT devices to manage their facilities and provide a high level of care to patients. These devices gather data, provide diagnostics and therapeutic functions, and automate activity at all levels. But those devices also expand the attack surface of the organizations that deploy them, and threat actors have been taking advantage. According to the FBI, healthcare was the industry most targeted by ransomware gangs in 2021, affecting more than 550 organizations, compromising the protected health information (PHI) of more than 40 million people, and inflicting financial losses of $6.9 billion.

Wisdom of Old CISOs

Standing up to the threat requires thoughtful investments in security tools that address the specific needs of each organization, backed by a deliberate and strategic plan that maximizes the efficacy of those tools to achieve and maintain a continuous Zero Trust posture. And as Emerson said Zero Trust is a journey, another famous CISO, philosopher Lao Tzu said the journey of a thousand miles to Zero Trust begins with a single step. Fortunately for healthcare organizations looking to protect their IoT, IoMT, and OT assets, that single step is one of five in a connected device security maturity model that Ordr has outlined in a new ebook entitled  A Practical Guide: Implementing Connected Device Security for Healthcare Organizations.

Five Easy Pieces

Authored by Gartner veteran and Ordr strategic advisor Brad LaPorte, with close consultation by many of our own subject matter experts, “A Practical Guide” includes recommended actions, technical considerations, and helpful insights that complement each of the five steps of maturity for connected device security, which are:

  • Step One – Asset Visibility: a foundational exercise that must be launched and operationalized to discover and classify every device, and map its flows.
  • Step Two – Vulnerability and Risk Management: used to extend the capabilities of the organization to effectively see and know about all the devices present in the environment.
  • Step Three – Reactive Security: prioritization of activities necessary, such as blocking specific inbound and outbound communications to mitigate risks, risks.
  • Step Four – Proactive Security: establish automated policies to ensure rapid threat detection and prevention, and begin to implement proactive Zero Trust segmentation policies.
  • Step Five – Optimized Security: use of real time analysis and micro-segmentation to automate dynamic policy changes, scale protections reflective of an environment’s current state, and enable continuous improvement.

As you can see, each step in the maturity model builds on the previous step in sequence; there are no shortcuts. And the speed with which an organization progresses from Step One to Step Five will differ. It’s also important to recognize that, when starting from a place of no or incomplete connected device visibility, each step of the journey represents a significant improvement toward Zero Trust. And when a connected device security strategy is implemented and fully matured, it can be applied holistically across an entire organization or focused on multiple critical areas, in sequence or in parallel.

When starting from a place of no or incomplete connected device visibility, each step of the journey represents a significant improvement toward Zero Trust.

If you want to read A Practical Guide: Implementing Connected Device Security for Healthcare Organizations, you can download it here with our compliments. We’ve scheduled a webinar for January 19 to discuss the topic. Or, if you want to talk to one of our healthcare connected device security experts (or an expert in any other industry), get in touch. We’d love to hear from you.

(Updated on November 10th with new Ordr capabilities) 

On October 26th, OpenSSL Project a critical vulnerability associated with OpenSSL versions 3.0 and higher. The version released on November 1st — OpenSSL version 3.0.7 —addresses this vulnerability.

  • CVE-2022-3602 is an arbitrary 4-byte stack buffer overflow that could trigger crashes or lead to remote code execution (RCE).
  • CVE-2022-3786 can be exploited by attackers via malicious email addresses to trigger a denial-of-service state via a buffer overflow.
  • These vulnerabilities were downgraded from critical to as high (CVSS score 8.8 from 9.0) on November 1st.

Here is what you need to know about this critical vulnerability:

What is OpenSSL? 

OpenSSL is a widely used open-source cryptography utility implemented to keep secure the web traffic exchange between a client and server. It is used to generate public and private keys, install SSL/TLS certificates, verify certificate information, and provide encryption.

Most web servers across the internet and within Intranets use SSL certificates to secure connections and the website being browsed. These certificates are traditionally generated by OpenSSL.

How concerned should we be about this vulnerability? 

OpenSSL can be misused if the vulnerable version is in use. The good news is that this vulnerability impacts a very specific version of OpenSSL and patching quickly will address any associated risks.

A flaw in OpenSSL has previously affected businesses. In April 2014, OpenSSL’s Heartbleed flaw was discovered. Numerous web servers, including those running popular websites like Yahoo, included it. Security teams rushed to apply updates because the vulnerability was simple to exploit.

How is this OpenSSL vulnerability exploited? 

Both CVE-2022-3602 and CVE-2022-3786 vulnerabilities are prone to buffer overflow attacks that can perform RCE (Remote Code Execution) or expose contents of the memory that contains private keys or proprietary information.

The chances of these vulnerabilities getting abused are low because one of the conditions is a malformed certificate signed by a trusted CA.

The issue lies in the verification process of certificates that OpenSSL performs for certificate-based authentication. The exploitation of the vulnerabilities could allow an attacker to launch a Denial of Service (DoS) or even a Remote Code Execution attack.

Patches for the two weaknesses found in OpenSSL v3.0.0 to v3.06 have now been released.

Which OpenSSL versions are vulnerable? 

  • OpenSSL versions 3.0 and above are vulnerable.
  • OpenSSL 3.0.0, the first stable version of OpenSSL 3.0, was released in September 2021, about one year ago. Any older operating systems prior to 3.0.0 are not impacted by this vulnerability.
  • Open SSL version 3.0.0 to 3.0.6 are affected by this vulnerability.
  • OpenSSL version 3.0.7 includes the fix for the critical vulnerability.

CRITICAL Severity: This affects common configurations, which are also likely to be exploitable. Among these are significant disclosures of server memory (potentially revealing user information), vulnerabilities that are easily exploitable to compromise server private keys remotely, or situations where remote code execution is possible. We will keep these issues private and release a new version of all supported versions as soon as possible.

HIGH Severity: This includes issues that are of a lower risk than critical, perhaps due to affecting fewer common configurations or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month, where this is something under our control.

Is the Ordr platform impacted by the OpenSSL vulnerability?   

Ordr has reviewed our usage of OpenSSL. This vulnerability does not impact Ordr as we do not use the impacted version.

How Ordr can help? 

Ordr has added two new capabilities:

  1. A new scanner that will detect versions of the OpenSSL that are vulnerable.

  1. New IPS signatures that can detect exploits of this OpenSSL vulnerability

New Ordr Scanner to Detect Vulnerable Versions of OpenSSL  

  • Ordr scanner uses the following command-line Options:
  • As servers have an open HTTP port; A curl command is used to connect to them to find the SSL version
  • In cases where clients do not usually have web services, the “ssh” command can be used instead.
  • As for a detection method, we use HTTPS headers, SSH headers, and credentialed scans to get the information.
  • Some scanners use only authenticated approach that requires full credentials, but Ordr uses an unauthenticated way to get information about Open SSL versions.
  • Ordr scanner also uses tools like Nmap to find open ports as a precursor before finding out about the OpenSSL version.
  • Example screenshots of detecting Open SSL that is built into the Ordr scanner.

Sample SSL command 

Sample SSH command 

Packet Parser with IDS Signatures to Detect Exploit Attempts 

  • While the Ordr scanner detects all the machines that have this vulnerability, the next step is to see if any exploits are exploting this vulnerability.
  • There is a parser on the wire that we need to enhance with rules to get versions of TLS, certs, and cryptography.
  • Ordr has an intrusion detection engine that scans for exploits of this vulnerability with the correct signatures. For example, given below is a signature that would help identify the exploit of this vulnerability.
  • CVS-2022-3602 Detection – Detection of this pattern was done using IDS Signatures.
  • A buffer overflow can be triggered by sending an X.509 certificate with a specially crafted email address in the “id-on-SmtpUTF8Mailbox” field (OID, resulting in a crash (Denial of Service – DoS) or potentially remote code execution on a vulnerable client or server. Potential opportunities for exploitation can occur if a server requests authentication information after a malicious client connects or if a client connects to a malicious server, which would then make the client vulnerable.
  • “OpenSSL x509 crafted email address buffer overflow attempt” is detected with the following signature.
  • In the event that there is a malicious activity involving OpenSSL, Ordr has pushed the latest signature to all its customers, and the alarms will be raised.