Discover connected device security resources to get a deeper understanding of how Ordr can help you secure and manage traditional, IoT, IoMT, or OT devices.
As shared in our press release, we’re excited to announce that Ordr has successfully achieved SOC 2 Type 2 Compliance.
This is a milestone for Ordr, as we’ve been investing heavily in our security programs and operations since our inception. It also takes a tremendous amount of discipline to get to SOC 2. This SOC 2 certification announcement is a testament to the rigor and diligence in the way we build our product, run our cloud and data center operations, how we protect our IT assets, and how we secure our customer instances on a daily basis.
It demonstrates to our customers the confidence that we have the proper controls in place to protect their data, and is another example of how Ordr is leading the connected device security market.
Why is SOC 2 Important?
With cyberattacks hitting the headlines almost every single day, protecting your data is critical. This includes not only the data that stays within the confines of your technical infrastructure but also data that is “managed” by security vendors.
SOC 2 certification provides attestation that Ordr is meeting the rigorous standards for data protection and security.
What is a SOC 2 assessment?
Developed by the American institute of CPAs (AICPA), SOC 2 defines criteria for managing customer data in accordance with five key service principles: security, availability, processing integrity, confidentiality, and privacy.
SOC 2 assessments can be carried out in one of two ways:
A SOC 2 Type 1 assessment attests to the design and implementation of controls at a single point in time.
A SOC 2 Type 2 assessment attests to the design, implementation, and operating effectiveness of controls over a period of time, usually between 3 and 12 months.
In our case, Ordr was certified for SOC 2 Type 2. As part of our SOC 2 Type 2 audit, the assessor validated that our controls were not only designed and implemented, but that they also operated effectively and as intended over the defined period.
While the SOC 2 Type II assessment takes longer to complete, it demonstrates our commitment to robust information security and the implementation of controls, systems, and processes to protect sensitive customer data for some time now.
What criteria did Ordr meet in our SOC 2 assessment?
To complete the audit, Ordr engaged with an independent third-party auditing firm, who performed an extensive audit and examination of Ordr Systems Control Engine systems, tools, processes and operations in the following areas:
If you’d like to learn more about Ordr, or understand how we address the problem of connected device security, please follow us on LinkedIn or Twitter, or request a demo here.
Last week we posted about the Log4j vulnerability, advised all organizations to continue patching, and shared that Ordr was not impacted. We also provided an overview of Ordr features that you can use to detect and protect against attacks leveraging Log4j.
In this blog, we will dive into the details of how attackers are taking advantage of this vulnerability. The Russia-based Conti ransomware gang, for example, is exploiting Log4j via vulnerable VMware networks that have not yet been patched. We will look closely at the details of how you can use the Ordr System Control Engine’s (SCE) existing functionality and newly released enhancements to detect and protect against the Log4j vulnerability.
First, here’s a summary of how Log4j attacks progress in a network:
An attacker sends a simple HTTP GET request, or a well-crafted protocol message, to the target server. The request is a “User-Agent” header which includes a URL for a JNDI lookup, or a message with the exact string, JNDI for non-web protocols.
The request is passed to the Log4j library for logging.
The Log4j library attempts a JNDI lookup as directed by the URL. The URL directs this request to an LDAP server that is under the attacker’s control.
The LDAP server responds with directory information with a protocol header that includes a Java class to execute. The JNDI library instantiates and executes the class, which has the same system-level privileges as the server software that included the Log4j/JNDI libraries.
The successfully injected malware can then do whatever the attacker wants. Risks include ransomware, exfiltration of sensitive data, and any other malware function.
What can Ordr do for you?
Identifying vulnerable targets
Ordr uses multiple methods to detect targets for Log4j. These include monitoring of SPAN or network traffic to detect attacks or probing a device with active scans to identify vulnerable devices. These are logged in the Ordr Security Dashboard Threat Card as a “special category” created to track Log4j attacks.
IDS based attack detection
The Ordr platform includes an integrated intrusion detection engine that monitors traffic to detect malware and attack attempts. Ordr sensors continuously monitor both North-South and East-West traffic for signs of malicious activity or violations of security policies. This provides real-time visibility into instances of potential network compromises and insights into any lateral movement attempts made by an attacker.
Anomaly detection
The Ordr platform also includes a machine learning-based behavioral analytics engine. This method is used to confirm a possibility of attack, not a confirmation of an attack. It is recommended this information be analyzed, along with other potential events Ordr has added, for Log4j detection. Ordr SCE analyzes and baselines the traffic based on expected behavior, and any deviation from this normal traffic is marked as anomalous on the system. This model works well for all devices that have predictable traffic patterns. For example, a medical device running limited traffic patterns that suddenly displays new communication patterns should be considered potentially anomalous and be investigated.
Vulnerability probing
Ordr has introduced new vulnerability detection software for Log4Shell. This new scanner takes advantage of Ordr SCE’s knowledge of the devices being scanned. IoT and medical devices require special consideration to avoid interfering in their operation. This capability is not available in most vulnerability scanning products which will aggressively probe all ports in the ranges of IP addresses they are configured to scan. This type of heavy-duty scanning could be detrimental to the operation of the medical devices that could be providing patient care or IoT automation functions.
Unlike typical IT scenarios where security teams can run a set of scripts to see what kind of Log4j version is built into the server, healthcare operations do not have the privilege to run scripts directly on heavy iron, like CT/X-ray equipment, as well as patient monitoring devices. With Ordr’s scanner, you can select only specific devices to be scanned at a time. It is also typical that a hospital standardizes on a specific make/model, and all that is required is to run this test on only one of them to understand the software decomposition. Ordr generates a report after the scan to show a list of devices that are vulnerable to Log4j.
How does the Ordr scanner work?
Devices are selected by IP, device type, or various search mechanisms.
The Ordr scanner runs on Ordr sensor, and does not need full credential access.
The Ordr scanner injects a string in the packet that triggers a call back to the sensor if a vulnerability is present.
The Ordr scanner performs scans on open ports of HTTP, FTP, telnet, and Syslog; It generates a report after the scan is run.
Detecting callbacks to C&C sites
The Ordr platform includes the ability to track and visualize communications to malicious attacker domains; in this case, Log4j attacker domains.
Tracking malicious communications
The Ordr platform subscribes to reputable threat intelligence feeds and is available to every customer today. These feeds detect many of the callbacks to Log4j IPs and domains, but do not associate the family with that. To overcome this problem, Ordr has built a mechanism to scout the internet for all callbacks available for Log4j domains and Ips, and has built a mechanism to update the callbacks dynamically at each customer deployment. The feature provides a two-fold advantage: it covers more callbacks than any of the subscribed threat feeds cover, and it associates the Log4j family to these IP addresses for easy tracking.
Ability to track communications on malicious ports
Another feature available in the Ordr product is tracking communications to the internet based on ports and protocols. As most of the studies have suggested, most of the callbacks for Log4j uses 1389, 2202, and 39536 ports. A simple rule available in Ordr SCE will track every communication to Public IP addresses not owned by the enterprise and mark it as malicious if it matches the rule. All these communications can be viewed on individual devices or under “Blocked Port” on the security page.
Visibility to Log4j traffic patterns
Traffic analysis engine
Ordr SCE provides the ability to visualize problematic traffic centrally in the Group Traffic Analysis tool. This screen features a constellation plot that shows the recognized groups and individual bubbles. To make tracking of Log4j easy, Ordr has created a new bubble specific to Log4j, and all communications from inside the enterprise can be viewed with a single click.
In the example below, the operator clicked on the Log4jRCE Sites bubble. The only traffic lines plotted were to the Workstations and Medical Devices group. This means that other groups such as Servers are not yet active with Log4Shell traffic.
Policy profiles to track communications
Users are given an option to create a policy profile to track communications from a discrete set of devices. In the case of Log4j, it is recommended to create a new policy profile to track devices that are potentially vulnerable to Log4j. In this case, start with servers and expand it to other potential devices. After creating the policy profile, Ordr SCE evaluates every flow from these devices as a base and marks new communication as malicious. These are color coded based on the risk of the communication.
Highlighting infected devices using a risk score
Ordr assigns a risk score for every device in the network based on the events detected for that device. Each event described above will change the risk score of the device based on the criticality of the event. In the case of Log4j, devices with attributes such as a vulnerable system, where an exploit is identified or if the device is communicating to Log4j callback will have a risk score of critical. The risk score gets adjusted based on the events detected and the criticality of the device.
Ordr has deep integration with firewalls and NAC vendors. Users will have an option to quarantine connected devices based on their risk level, or if they detect a Log4j security event or behavior anomaly. They all point to a possibility of an attack in the enterprise.
In summary, Ordr has one of the most comprehensive features to detect the Log4j vulnerability and protect against exploitation. For more information, please reach out to us at info@ordr.net or request a demo here.
Like many other security and incident response teams, Ordr was busy over the weekend responding to the critical Apache Log4j vulnerability (NIST details here CVE 2021-44228). We want to make sure our customers understand what the Log4j vulnerability is, how it affects them, and how Ordr helps keep their enterprises protected.
What is the critical Apache Log4j Vulnerability?
Log4j is an Apache Java logging library used in many forms of enterprise and open-source software. This includes cloud platforms, web applications, and email services that could be at risk from attackers attempting to exploit this vulnerability.
The Log4j vulnerability (CBE-2021-44228), also known as “Log4Shell,” is a vulnerability that was announced on December 9. The attack vector is extremely trivial for threat actors. A single string of text can trigger an application to reach out to an external location if it is logged via a vulnerable instance of Log4j. It can allow unauthenticated remote code execution and access to servers. There are already active examples of attackers attempting to exploit this Log4j vulnerability in the wild, from installing cryptomining malware, installing Cobalt Strike malware, and of botnets attempting to use it for botnet activities.
Is the Ordr Platform or Ordr operations impacted by Log4j?
No. The good news is that all three areas of Ordr operations–Ordr internal IT, Ordr Data Center/AWS that use various tools and hosts cloud instances of Ordr Systems Control Engine (SCE), and the Ordr SCE that runs on customer premises–are NOT impacted by Log4j.
What about healthcare organizations and medical devices impacted by Log4j?
While the full scale of affected devices and systems is still being analyzed, healthcare organizations should consider any web-connected medical device vulnerable as they likely use Java-based applications or other Java components.
Identifying medical devices with Log4J vulnerability may require a slightly different approach. In a typical IT scenario, security teams can scan or run scripts on servers to identify what kind of log4j version is being used but in healthcare situations, hospital staff do not have the privilege to run scripts directly on heavy iron devices like CT/X-ray machines as well as patient monitoring devices.In addition, in some cases, it is not feasible to patch these medical systems.
Ordr will also work with medical device manufacturers as they disclose their vulnerability to make sure customers are kept up to date.
Another best practice for healthcare organizations is to monitor device communications from these devices to watch for connections to suspicious IP/URLs. Ordr’s Traffic Analysis and behavioral-based anomaly can provide visualization and baselining of traffic patterns of medical devices. We will monitor external communication to make sure malware is not getting downloaded, exploited through this vulnerability and communicating to attacker C2 domains.
Can we use the Ordr Systems Control Engine to detect systems impacted by Log4j?
Yes. Ordr has comprehensive threat protection capabilities that will detect systems and assets impacted by this vulnerability:
You can start by using Ordr to first identify all workstations and servers that may be vulnerable.
Our integrated IDS/threat detection engine has already been updated with signatures to detect active exploits of Log4j. You can investigate impacted systems that are being exploited.
Ordr threat intelligence and malicious IP/URL database lookup have already been updated to detect the latest external communications to Log4j IoCs (indicators of compromise)
You can create an Ordr custom policy profile and use the Ordr behavioral anomaly detection to monitor workstations and servers suspected to have this vulnerability and track their external communication.
Look for more best practices and new enhancements on detecting and protecting against Log4j using Ordr this week.
What can I do to mitigate the Log4j vulnerability’s impact?
While this vulnerability is extremely trivial to exploit, the mitigation is also trivial. For more details, please reference the recommendations provided by the Apache foundation.
Identify vulnerable systems on your network, and update. The CVE-2021-44228 Log4j RCE vulnerability was patched in Log4Jv2.15.0 by Apache
The vulnerability can also be mitigated in previous releases (>=2.14.1)
By setting the system property flag “log4j2.formatMsgNotLooku[s” to “true”
By removing the NdsiLookup class from the classpath
Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
Remove the JndiLookup and JndiManager classes from the log4j-core jar. Note that removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Please note that log4j versions 1.x are not affected by this vulnerability. Also, JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector.
For more questions on Ordr or the Log4j vulnerability, reach out to us at info@ordr.net, or if you’re a customer, please reach out to your customer success team.
The connected device security market has been heating up over the last five years, as evinced by Palo Alto Networks’ acquisition of Zingbox in 2019, the CyberX acquisition by Microsoft in 2020, and Insight Partners’ purchase of Armis, also in 2020. This week’s announcement of Claroty’s acquisition of Medigate continues the trend and leaves no doubt that device security is a high priority for enterprise cybersecurity. This is a very large market that will do nothing but accelerate as the number and variety of connected devices – and the potential attack surface – continues to expand.
The recent Claroty-Medigate news validates Ordr’s “whole enterprise approach” to device security, and our widely shared perspective that IoT/OT are converging–and that you need a security strategy that spans both these environments to protect the enterprise. That has been our strategy from the outset: providing a single, simple solution to provide visibility and security to every connected device. While our competition focuses on integrating disparate, complex solutions created for distinct market segments, we will instead keep our focus entirely on the needs of our customers.
When we speak to our customers, it’s clear that security leaders across industries recognize the urgent need to discover and secure the full spectrum of connected devices in their environment. That’s why Ordr customers benefit from our sole focus on their resilience against attack, encompassing every vulnerable device, from highly specialized equipment to general IT, IoT, and building infrastructure. Enterprises choose Ordr because we deliver:
Architecture leadership: We are a platform built from the ground up to address the visibility and protection of any connected device—IoT, IoMT, and OT. This means we deliver not only granular details about every device, but also how it is communicating, its network connectivity and flows, and its risks and behavior. Our ability to then automatically generate policies to secure any vulnerable device (on existing infrastructure like firewalls, switches and NAC) is a game changer, saving not just hours in resources, but reducing errors in manual policy creation and preserving ROI in existing infrastructure investments.
Customer-first culture: Our investments in and commitment to customer support, technical excellence, and professional services ensures success for the long-term. KLAS Research says, “Ordr’s culture of flexibility and willingness to partner stands out as reasons they are selected.” That’s because our team is easy to work with and has the integrity to deliver what we promise.
Proven deployments: We’ve been doing this since our first product availability in 2017. With every deployment, our Ordr Data Lake, our device database, and the number of network flows we monitor grows. Our team has proven track record of success in discovering and securing every connected device across its entire database. Together with our customers, we’re sharing these best practices in external conferences like HIMSS, AAMI, Manusec, and CSO50 to ensure the entire security community benefits from best practices.
If you are among those enterprises grappling with the challenges of securing your complex, hyper-connected infrastructure against cyberattacks, the good news is you don’t have to wait months or years for an integrated solution. With Ordr, you can get the visibility into your IT/IoT/OT environment that you need, with the ability to secure and protect your assets today.
Just for a minute, pretend you’re playing the villain in a game and you want to be the innocent civilians of Metropolis to your will. Your weapon: a special chemical that, when swallowed, will cause a person to do whatever you command. You have two ways to achieve your objective:
Go house to house throughout the city and slip the chemical into each residence’s plumbing
Penetrate the municipal water headquarters and dump the chemical into the city’s water tower, which also happens to be largely unguarded
Not a tough choice, is it?
Now you can understand the appeal to cybercriminals who want to do maximum damage — all at once — to corporations and their customers by attacking their software supply chains.
Let’s switch your role again. You now are no longer the villain — now you’re the hero, defending potential victims. And rather than a made-up game, you’re in charge of cyber security for a major corporation and you need to stop the bad guys before they infiltrate your company through a third-party software partner. What do you do?
In this blog, we’ll examine the methodology of the attackers, the status of corporations and suppliers in being aware of and combating the threat, and finally, best practices you can follow to help your company stay safe.
The Soft Underbelly: Software Vendors
Real-life bad guys increasingly like to target software supply chains to reach their ultimate destinations. Their common methodology is to infiltrate a software vendor’s network and employ malicious code to compromise the software, which is sent to the vendor’s customers. It then compromises the customer’s data or system.
The infiltration can come when a company first acquires the vendor’s software or in subsequent actions, such as through a software patch or hotfix. In these cases, the compromise still occurs before the patch or hotfix enters the customer’s network. This is referred to as going “upstream” in the supply chain to compromise systems earlier in the software distribution process.
These types of attacks affect all users of the compromised software and can have widespread consequences for all software customers. As we suggested in the water supply comparison, attacks on software supply chains act as “force multipliers” in gaining access to hundreds or thousands of companies with a single compromise. What looks initially like a minor ripple on the attack surface can almost instantly become a cyber attack tidal wave, damaging organizations near and far.
Source: Gartner
Flying Blind on Software Supply Chain Dangers
Overall, organizations don’t have great visibility into risks posed by third parties, especially when it comes to complex software supply chain ecosystems. A full third of organizations are clueless about their software supply chain risk exposure. Only 22.5% monitor their entire supply chain, and 32% perform vendor risk assessments no more than once every six months (BlueVoyant).
Increasingly Complex Attack Methodologies
So how are these attacks being executed? There are three common techniques:
Compromising software updates
Undermining code signing
Exploiting open-source code
The three are not executed in isolation. Rather, they’re often leveraged in combination or with other, less common techniques.
Compromising Software Updates
Software vendors typically continuously distribute updates from centralized servers through cloud infrastructure to their customers. This is part of routine product maintenance. Threat actors can compromise an update by infiltrating the vendor’s network and either inserting malware into the outgoing update or altering the update to grant the threat actor control over the software’s normal functionality. A well-known example of this method is NotPetya, which caused major global disruptions across the financial, healthcare, and industrial sectors.
Undermining Code Signing
Code signing is used to validate the identity of the code’s author and the integrity of the code. Attackers undermine code signing by self-signing certificates, breaking signing systems or exploiting misconfigured account access controls. By undermining code signing, threat actors are able to successfully compromise software updates. They impersonate a trusted vendor and insert malicious code into an update. For example, APT 41, a China-based threat actor, routinely undermines code signing while conducting sophisticated software supply chain compromises against the United States and other countries.
Exploiting Open-Source Code
Open-source code exploitation occurs when threat actors insert malicious code into publicly accessible code libraries, which unsuspecting developers—looking for free blocks of code to perform specific functions—then add to their own third-party code.
These compromised malicious libraries will often contain the same code and functionality of those they are impersonating, but they also include additional functionality that can be used for malicious purposes. This allows the threat actors to obtain boot persistence, open a reverse shell on remote devices, or deploy a remote code execution (RCE) attack. Open-source code compromises affect privately owned software because developers of proprietary code routinely leverage blocks of open-source code in their products.
It Will Get Worse Before It Gets Better
Attackers look to infiltrate and disturb supply chain systems in order to disrupt business and harm a company’s production system. Because there are multiple means of pervading the supply chain, it is difficult to secure all means and prevent an event from happening.
Especially with organizational supply chains and third-party relationships continuing to grow, there is an increasing opportunity for attackers to strike. Nobelium, the Russia-based threat actor behind the supply chain attack on SolarWinds, is targeting cloud service providers and IT services organizations in a large-scale and ongoing campaign designed to infiltrate systems belonging to downstream customers of these companies. “Since May, Nobelium has attacked at least 140 cloud service providers and compromised 14 of them, according to Microsoft, which has been tracking the campaign. Between July 1 and mid-October of 2021, Microsoft security researchers observed some 22,868 Nobelium attacks on organizations in the US and elsewhere (Source: Microsoft).”
Best Practices for Protecting Your Organization
To protect a business from supply chain attacks, we need to identify the areas that pose a risk and maintain a system to safeguard them. The best practices that result from this understanding boil down to these:
Know what devices and systems are on your network: the first rule of cybersecurity is know what you have. You need to be monitoring devices and systems for anomalous behavior that may have been compromised as part of a supply chain attack.
Ensure suppliers implement security practices: You’ll need everyone in the supply chain to implement their best housekeeping to secure your business from the very beginning of the supply chain.
Limit access to data: Prioritize who should be given access, restricting it to only those who need it.
Implement effective auditing and reporting practices: Collect data and log it for review to understand the methods that work and those that don’t, then only employ the effective practices.
Test your own security measures: Put your practices to the test and note how they hold up to various threats you may want to emulate.
Work in collaboration: Communication is key to keeping a good relationship and prioritizing a smooth supply chain exchange of goods.
In Summary
While software supply chains are critical for businesses, attacks on the chains are growing in part due to the multiple alleys of access and the “force multiplier” effect we described at the beginning. It is simple to attack a single network within the supply chain and gain access to several companies at one time.
Therefore businesses must take extra measures to stop supply-chain attackers by emphasizing good relationships, necessary security practices, and routine cleaning and testing. The more these are implemented, the better shape business will be in to nullify the attackers from the onset.
Read More on how Ordr can help with supply chain attacks like Solarwinds
