Blog

Organizations spend more than ever on security, yet the rate and impact of attacks continue to grow. Is a positive or negative security model the right approach to address today’s concerns, specifically to protect IoT devices?

SPOILER ALERT: you need a hybrid model based on behavioral analytics.

Traditional approaches to cybersecurity simply can’t keep pace with attackers becoming increasingly specialized, organized, and sophisticated. Security leaders and practitioners know that a new approach to security is needed, but navigating the myriad buzzwords and claims about artificial intelligence (AI), machine learning (ML), and behavioral analytics can be challenging. With that in mind, I want to explain how and why a new approach using behavioral analytics (including AI/ML analytics algorithms) solves real-world security problems today.

The Negative Security Model

A negative security model will “allow everything” by default while attempting to identify the “bad.” This approach is a mainstay of security tools such as antivirus software or IDS/IPS and has dominated cybersecurity for most of its brief history.

Just as credit card companies use rules and known attributes to identify fraud, negative security controls use rules and signatures to identify known threats previously seen in the wild. When the threat is seen again, security tools can detect and block the malicious traffic, malware, exploit, URL, etc.

Negative security controls are good at identifying known threats. However, tools using these controls can only identify and block what they are told to block. A signature must exist, or a tool must be configured to block malicious activity. Ongoing care and feeding are required to keep tools up to date with the latest signatures and configurations to detect and stop threats.

A negative security model alone is essentially defenseless against widespread zero-days such as the recent Log4j vulnerability, which impacted thousands of enterprise products and created massive exposure for virtually every modern organization.

Depending entirely on negative controls for threats has some serious limitations, and organizations need both negative and positive controls to protect their assets and environments.

The Positive Security Model

A positive security model is the opposite of a negative security model and works by defining allowed actions. Instead of defining a blocklist of “bad” actions, the positive security model defines what is “good” or allowed. Think of positive security as the doorman at an invitation-only party as a simple analogy. Instead of identifying and blocking “bad” attendees, the positive security doorman uses the guest list to define who should be let in.

A network firewall is a classic example of a positive security tool. Only specific, required network ports are open, while all other ports and traffic are denied by default.

A tool using the positive security model can address the shortcomings of a tool using the negative security model by providing a far more proactive approach to security. Instead of constantly chasing the “bad,” a positive model focuses on what applications, users, and devices need to do their job. Everything else is flagged or blocked. It doesn’t matter if an attacker targets a zero-day vulnerability – anything that doesn’t match the “good” list or vastly differs from normal activity will be denied.

As a simple example, attackers often gain initial access to an environment by using phishing emails to get a user to click a link or open an attachment. The attacker can easily evade negative security controls by altering a URL or malware payload. As controls become more sophisticated, so do attackers by changing their tools and methodologies.

Once on a user’s device, the attacker will target other assets in the environment in an attempt to move laterally, often using protocols such as SMBv1 or RDP. Since this movement is outside the norms of valid activity, positive security controls can recognize and deny the abnormal behavior without prior knowledge of the methods used or the specific threat.

Blending Security Models With Behavioral Analytics

To meet today’s security challenges, a blend of negative and positive controls is essential. More importantly, behavioral analytics must be applied to enable a positive security model, control an organization’s complex communication patterns and address security challenges in ways never possible before.

Positive security is more complicated than simply allowing communications or opening ports on a firewall. Instead of focusing on individual traits or indicators, positive security requires understanding the more complicated world of behavior.

Consider the different scenarios of medical devices in a research facility, outpatient care, and a critical care environment. Some of the devices may be similar in make and model; however, their use and criticality in each environment will dictate different requirements, priorities, and risk tolerance.

A system needs awareness of a device’s purpose, the services or assets it needs to access, and how similar devices in the environment behave to provide the right level of protection.

In recent years, anomaly detection and behavioral analytics have been hot topics in security but have delivered mixed results. The ultimate goal for successful solutions today is to leverage behavioral analytics for truly reliable and valuable insights. For that, we need to cover three essentials.

1. Get all the right data from the best sources

Instead of simply identifying specific behavior as abnormal, the goal of positive security is to enforce controls that keep devices and data safe while ensuring each device can function in the environment as needed. Positive security requires a deep understanding of what each device is, its role, purpose, and communication patterns. To get this level of deep understanding requires large amounts of ground truth data. Arguably, the network provides the most accurate and reliable source of data needed to understand this level of detail.

An agent-based approach will result in blind spots across the exploding population of unmanaged devices that include IoT, IoMT, OT, and other connected devices. Agents are notoriously painful to manage, and for many unmanaged devices, agents are either not available or difficult to develop. It’s virtually impossible to ensure agent compatibility with the myriad combinations of connected device hardware, software, and firmware. Agents impact performance in the best case and completely disable devices in the worst case.

Understanding device behavior requires a “show me, don’t tell me” approach, and looking at device communication flows over the network provides the best source of truth.

To quote Batman, “It’s not who you are underneath, it’s what you do that defines you.”

Normal behavior informs the positive security model for a specific device profile, and normal behavior can be determined by baselining communications flows and understanding the systems it communicates with. With this understanding, policies can align with a zero trust framework limiting device communications to the required systems and nothing else.

Ordr collects and analyzes network data to create a baseline of normal behavior, and map communication flows for every device. The baseline for each device is automatically tuned, updated, and compared to the device’s historical behavior and similar devices in the environment. Device flow information is enriched with device context, threat insights (threat intelligence, third-party vulnerability databases, and reputation data), network data (from switches, routers, and wireless controllers), and additional data (IPAM, DNS, CMDB, Active Directory) as we continuously analyze the activity of every device. All of this data is collated into the Ordr Data Lake and continuously analyzed to identify any changes in behavior.

2. Organize the data for effective analysis

We need to know every device’s “what, where, and why.” An algorithm won’t magically generate needed answers from massive amounts of data. Getting valuable insights requires organizing data hierarchically with relationships properly established.

Is the device a patient monitor, a security camera, or a printer?

Where is the device located, and why does it behave the way it does?

What data and systems does the device serve, and what does it require?

Ordr organizes data to see the interrelationships between devices, the network, and how data flows in all directions to answer these questions. Ultimately, all this context is organized in terms of the device itself. While analyzing hundreds of thousands of records may still be required, analyzing organized data is far more manageable and focused than iterating over massive amounts of data.

Analyzing organized data enables focus on specific types of devices and behaviors to uncover valuable security insights. Analyzing organized data can be used to learn how patient monitors behave as a generic device and a specific model of monitor. We can understand how other similar devices in the network behave to identify unique traits and specific needs in each organization.

Analyzing organized data can help answer important questions that drastically change a security team’s ability to respond to an event. For example, when a hospital sees a malicious outbound DNS request, there may be no need for action if the request is from a visitor’s laptop on the guest network. On the other hand, it would cause serious concern if the malicious request came from a hospital-owned infusion pump. Ordr provides these insights by properly organizing and analyzing data.

3. Understanding and explaining behavior

Once we know where to look, we need to understand what we see in terms of behavior on the network. Having partial information for security is not helpful, and this is where most cybersecurity behavioral analysis attempts fall short. If a security tool can’t explain in detail what was detected, an analyst has to do the work to understand what happened. A tool that generates anomalies it can’t explain will quickly drown security analysts in work or, more likely, cause them to miss critical events. It’s not enough to say a learning algorithm triggered an alert. More context is required to instill confidence and to ensure priority for action.

Ordr analyzes network data to create a baseline of behavior for each device in an environment. That baseline is then combined and analyzed with the baseline of other devices. With this approach, Ordr identifies activity outside of normal behavior for the device, its cohorts in the environment, or similar devices deployed globally.

Additional details such as the specific device, physical location, internal and external connections, and communication information are critical to ensure that incident response teams have enough detail. Proving this detail in an easy-to-understand, graphical way with the flexibility to customize the view is critical for any AI-based tool to be useful.

Analysis to uncover attribution and explainability is complicated. Making this easy for security teams is one of the essential traits of Ordr. The image below shows the enormous scale of analysis needed for a single Ordr customer deployment.

Ordr ultimately rolls behavior up to the device level. The center of the diagram above highlights the Ordr database of behavioral patterns for over 500,000 devices.

Understanding the behavior of these devices requires the analysis of 96 million network flows. However, to truly perform attribution and achieve understanding, we need to analyze the 100 streams that make up each flow and the packets that make up each stream. This essential task is where the analysis gets complex, and most behavioral analysis systems fall short.

To achieve positive controls, we must understand and use automation to control behavior. There are too many devices and network segments for security teams to understand the complexities of each one. Instead, security tools must understand and control behaviors in the same set-it-and-forget-it way that traditional firewalls control network ports.

Providing this level of simplicity to security teams requires a new type of analysis and a new type of security solution. One that we at Ordr continue to build and optimize.

Ordr’s Unique Approach to IoT Security

While most behavioral analytics solutions have failed to live up to the hype, Ordr provides actionable and practical answers to secure your connected devices without creating new headaches for users or security teams.

To illustrate, consider blending the positive and negative security models along with behavioral analytics to detect the multiple stages of a ransomware attack kill chain. In most instances, Indicators of Compromise (IoCs) are not available immediately after detecting an attack in the wild. In these cases, a positive security model compliments a negative security model by providing greater insight into a potential problem in the network and the attack timeline. Once IoCs are defined, they can be validated using the negative security model.

The screenshot below shows the detection of stages of the kill chain using different security models.

If you have thoughts or questions about this blog, or simply want to learn more about Ordr, reach out to the team for a deep dive discussion.

Cybersecurity and cyber threats have been in competitive co-evolution for years, with each side adapting to the other. Historically firewalls, IPS, antivirus, and modern endpoint protection tools have been common elements in the first line of defense to keep the bad guys out. Try as we might, bad things still happen to good networks. Attackers constantly develop new threats, target new vulnerabilities, or bamboozle a busy employee into doing the wrong thing. The first line of defense is never perfect, so it’s critical to develop a solid second line of defense.

For many organizations, the second line of defense amounts to simply recreating the first line of defense in more places. This approach misses the ways threats differ once inside an organization and also ignores some of the essential advantages defenders have at their disposal.

This post briefly revisits some of the high points in the evolution of cybersecurity and cyber threats, looking at what has worked for defenders, where things have gone wrong, and how lessons learned have helped build new lines of defense. Some deep topics will admittedly be oversimplified. The point of this post is not to denigrate any of the great security tools in use today. Instead, the point is to highlight some of the broad trends and inherent issues security teams need to consider.

An Absurdly Condensed History of the First Line of Cyberdefense

Until recently, many organizations thought of the inside of their network as trusted and the outside Internet as untrusted. Firewalls provided a natural barrier and control point for this boundary, denying unsolicited connections from the untrusted outside by default and leaving a few pinholes open for essential services. Trusted insiders, however, could connect to pretty much any outside service they wanted, and that service would be allowed and trusted. While this approach worked to keep random strangers out, it didn’t work if users and assets on the inside were already compromised.

Attackers had countless ways to attack. They could send phishing emails containing a malicious link in an attempt to gain access. If an email security solution was in place and the attacker was unsuccessful, they could shift to a new vector not subjected to email checks such as DNS tunneling. If a DNS-based firewall or perhaps a web application firewall (WAF) was in use, an attacker could pivot to target cloud applications. The cat and mouse game continued, so various methods were needed to detect and prevent threats.

Attackers found ways to slip past detections. Modifying malicious payloads ensured previously known signatures didn’t match while encoding, obscuring, or encrypting helped attacks slip past detection logic without being inspected.

The ever-growing deluge of new vulnerabilities didn’t help. With the recent log4j exploit, setting a username in the apple profile resulted in a new attack vector. Exploiting Microsoft’s hole, a hacker can enter the enterprise by typing something inside the chat window of a video game.

If all else fails for the attacker, one final incredibly effective tool remains – social engineering. Instead of breaking in, an attacker can convince a user to give out passwords or install malicious software in the guise of a valid application or tool.

A New Line of Defense Introduces New Advantages

History has shown the first line of defense is eventually breached, and we must assume adversaries will get in or have already gained access. With access, the attacker typically attempts to move laterally to reach a high-value asset such as a server with all AD credentials, a device with sensitive patient information in a hospital, or a management platform with the ability to coordinate all PLCs on a manufacturing floor.

While this is all doom and gloom, there are ways to detect and stop attackers by shifting focus from chasing an infinite number of threats to focusing on a smaller number of malicious behaviors. For example, there may be hundreds of thousands of variants for a piece of malware, but when it comes to lateral movement, tools like Mimikatz behave the same when performing actions like pass-the-hash.

The same is generally true of all sorts of secondary attacker actions. For example, when an attacker performs internal reconnaissance, it’s easy to detect when a device starts indiscriminately reaching out to a new or large number of devices. Likewise, SMBv1 is at the center of many Windows vulnerabilities and lateral movement attempts. We can now watch all devices speaking SMBv1 and see which system suddenly communicates to many other systems over SMBv1. The same is true for RDP – a protocol designed for remote diagnostics. We can quickly identify excessive RDP usage that falls outside normal administrator behavior.

These examples highlight important advantages for defenders. When an attack has moved inside the network, we can see everything as long as we make an effort to look. When an attacker is still outside, we have almost no insight into who they are, what they’ve been doing, and where they’ve been. When they move to our turf, we see the entire battlefield. Instead of only looking at individual traits or actions, we see the complex behaviors across multiple hosts and how they develop over time.

Instead of making a yes/no decision based on a few milliseconds of analysis, we can inform decisions by understanding the complete history of the network, the behavior of all devices in it, and the collective knowledge of how threats behave. Using inputs like this is how Ordr works.

Building a Second Line of Defense with Ordr

Ordr analyzes network traffic and traits of each host to conclusively identify each device, whether it is a laptop, server, or the wide variety of IoT, IoMT, or OT devices. The platform builds global and local baselines for normal behavior of every device and allows organizations to identify suspicious or malicious behavior quickly. As soon as a risk or threat is identified, the platform can automatically create and implement policies to isolate any affected hosts and prevent the spread of an attack.

Ordr’s capabilities provide a logical approach to building a second line of defense. Every device is identified and protected based on its unique needs and functions, regardless of being managed or unmanaged. The entire environment is monitored for signs of threats and malicious behaviors, regardless of how those threats got in. Thanks to automation, Ordr enables a robust second line of defense at a fraction of the effort and cost of traditional threat prevention tools.

If you want to learn more about Ordr technology, reach out for a deep dive demo.

Identity is a foundational component of modern security models, allowing organizations to control the data or services a user or account should be able to access. The explosion of IoT, IoMT, OT and other connected devices introduces significant gaps in identity-based security while creating new challenges and posing questions:

What is an identity for these devices that do not inherently have what we think of as an identity?

How can we close the gap and bring identity-based controls to these critical devices?

This post looks deeper into the challenges, these questions, and how Ordr helps provide answers in a straightforward and automated way.

It’s the End of Identity as We Know It…and I Feel Fine?

There are several methods organizations use to establish and verify identity for their users and assets. Unfortunately, none of these methods work well for the new class of connected devices.

Traditional devices such as laptops and workstations can be associated with a specific user and can be reliably linked to that user’s identity. Security teams can also verify the identity of a device by installing certificates or using USB keys. When a high-value asset is accessed, multi-factor authentication mechanisms can be leveraged by sending the user a passcode via email or text to be provided for additional verification.

The new class of connected devices are rapidly increasing in numbers and can be found everywhere in enterprise environments. Connected devices include everything from consumer products and phones to printers and media displays. In industrial settings IIoT and OT devices span the range of sensors to the multi-million dollar equipment essential to manufacturing lines. In healthcare, IoMT includes a vast array of medical devices from health monitoring equipment to magnetic resonance imaging (MRI) scanners that are critical to delivering care and ensuring patient safety.

Connected devices are increasingly critical infrastructure in organizations across industries, yet these devices can’t be managed the same as traditional devices. The simple task of installing enterprise certificates or endpoint agents is virtually impossible since many of these devices run embedded operating systems or are agentless. Even if agents could be installed, the vast diversity of hardware and software variations of IoT devices makes it almost impossible for vendors to develop and support agents.

Connected devices are commonly found with software stacks from various sources layered on embedded and customized operating systems. For these devices, any tool that uses a map of the processes to perform behavioral analysis is virtually useless.

Integrated firmware running on connected devices typically prevents any new software from being installed to ensure security and device reliability. As an example, new software can’t be installed on a piece of medical equipment once it’s gone through FDA certification.

Multi-factor authentication is another non-starter for IoT. An infusion pump can’t be expected to receive and provide a passcode to verify its identity.

Bringing Ordr to the Chaos of IoT Identity

With all of these limitations, how is identity determined and used for connected devices? The best unique identifier (not identity) is a device MAC address or serial number. MAC addresses are at least trackable (although easily spoofable), but serial numbers are nearly impossible to track and manage.

Ordr takes a new approach that doesn’t require IT and security teams to manually track the endless minutia of device details or do anything to update or change devices. Instead, Ordr automatically and passively analyzes the behavior of each device and recognizes a device’s identity based on what it actually does (i.e., the device communication).

To illustrate, let’s look at a device that claims to be a printer. Does it act like a printer? How do we know how a printer should act?

To answer this a large number of printers must be studied to understand what printers normally do, the protocols they speak, destinations they connect with, packet patterns they exhibit, etc.

With sufficient sampling a baseline can be established and used to verify if a new “printer” behaves like all the other printers previously seen – if it walks and squawks like a printer, then it’s probably a printer.

It’s also important to understand normal behavior for a particular environment. It’s not enough to know if a printer is behaving within the norms of other printers – it’s essential to know if the printer is behaving like my other printers. Is it talking to the appropriate management server, using the appropriate network segments, and so on.

The combination of global and local insights into behavior gives a very reliable approach to understanding a device’s identity. Just as importantly, it is a passive, hands-off approach that doesn’t require more work from staff or to change anything on the device itself.

As a result, Ordr is able to easily establish identity and continuously monitor it throughout its life cycle. Reach out to us to learn more about how Ordr can help with identity and security for all your IoT, IoMT, OT and other connected devices.

It’s December 8, 1941, and you’re in charge of defending the United States against future enemy air attacks like the one that devastated Pearl Harbor. What would you do?

Given the technology of the time, you wouldn’t have had many choices. You might have recruited scores of civilians and given them illustrated books showing what German and Japanese warcraft looked like and how to distinguish them from American or British planes. Then you’d ask these civilians to take up observation posts and call a phone number when they spotted anything suspicious.

That’s indeed what happened and what served as a national alert system until later in the war when radar was invented. Lucky for the United States, the action remained almost entirely away from American shores throughout World War II.

But the human radar example, along with subsequent warning and response systems, provides a rough parallel to the progress of network security defense mechanisms from the early days of IT until now. It’s a story that highlights common requirements between keeping a country safe from bombings and a network safe from breaches. From an operational standpoint, each of these systems needs to meet three objectives:

Comprehensively monitor the threat posed by the enemy
Accurately detect threats
Quickly and thoroughly respond to neutralize the threat

Noble goals, but as we shall see, they’re not so easily accomplished.

The 7 stages of network security evolution

Stage 1: Intrusion Detection System (IDS)

In the beginning, there was the intrusion detection system (IDS) method, which is not terribly different from printing up a bunch of enemy plane illustrations and telling your network to be on the lookout for them. In the IT case, the illustrations were “signatures” of the known malicious threats that had been identified based on past attacks.

There were two major problems with this system:

It didn’t do you any good if the enemy had developed a new weapon that didn’t look like the ones it attacked you with previously and…
Once spotted, the detection system didn’t prompt any automatic responses – just a “hey, you might want to do something” call to headquarters.

In all fairness, the initial ideas for IDS came about in the early 1980s when the only people using networks extensively were governmental agencies. The true cyber wars were decades away, so a relatively primitive network monitoring tool sufficed.

Stage 2: Intrusion Prevention System (IPS)

As attacks ramped up, the people who developed network security tools next added a basic response feature: blocking. The packet containing the dangerous goods was prevented from delivering the payload to a target by using an intrusion prevention system (IPS) to shut down access to email addresses, websites, and the like. In warfare terms, this is like erecting a shield over your target without doing anything to anticipate and prevent future bombing raids.

The other issue that came to undermine effectiveness was a vendor’s tendency to brag about how many attackers they’d identified to keep networks safe in the form of “playbooks.” Vendor A claimed that it was better than Vendor B because it listed, say, 3,500 malware agents in its playbook while its competition only had 2,000. This slowed down operations as the system thumbed through its databases and tried to determine if blocking was needed.

Stage 3: NetFlow

Cisco developed this protocol for its switches and routers to give SecOps a broad overview of what was happening on the network. Now the security team had visibility of activity so it could effectively monitor and troubleshoot network performance across all data sources. This provided ready-made, native tools to investigate issues without using workarounds that might or might not work.

Stage 4: Network Forensic Technology (NFT) and Metadata

While it’s great to have a broad view of threats to a network, you also need to be able to dig deep and analyze individual threats. To do so, you need to look at the packets in question – and do so quickly and efficiently. Network Forensic Technology (NFT) and metadata did exactly this by looking at the packet headers. Metadata in particular, was a significant advance in that it could see patterns and quickly group threats that resembled other threats. This is similar to the way that photo programs now can recognize a face and help viewers pull all shots of a given person from thousands they may have captured with just a few clicks rather than sorting through the entire catalog.

Stage 5: Network Analysis and Visibility (NAV)

While NetFlow gave visibility into what was happening with devices that incorporated the Cisco technology, it didn’t give teams a hint about what was happening elsewhere on their networks. Enter Network Analysis and Visibility (NAV) — a tool that pulled the covers off assets that might previously have been hidden. This means everything — in the cloud, on-prem, and even ZTE/SASE solutions — comes into view.

Stage 6: Network Traffic Analysis (NTA)

NAV was introduced in 2011, and eight years later, a further refinement came in the form of network traffic analysis (NTA). The visibility extended into such access points as IoT devices and deepened the ability to look closer and deeper at problematic traffic. There’s only one problem: We’re still largely just SEEING the threatening enemy with these devices and sealing off dangerous openings. What we need is something that can neutralize the attacking group — if not exactly a squadron of fighters shooting down enemy bombers, at least some mechanism to take countermeasures automatically.

Stage 7: Network Detection and Response (NDR)

The most recent and most effective method of defending networks from intruders, network detection and response (NDR) provides not only the extensive analytical and visibility power that previous generations have developed, but — as the name implies — an automated response as well.

In its NDR market guide, Gartner provided several criteria for a product to be classified as such. A true NDR must:

Analyze raw network packet traffic or traffic flows (for example, NetFlow records) in real-time or near real-time.
Monitor and analyze north/south traffic (as it crosses the perimeter), as well as east/west traffic (as it moves laterally throughout the network).
Be able to model normal network traffic and highlight suspicious traffic that falls outside the normal range.
Offer behavioral techniques (non-signature-based detection), such as machine learning or advanced analytics that detect network anomalies.
Provide automatic or manual response capabilities to react to the detection of suspicious network traffic.

At Ordr, we advocate that the above Gartner-outlined features aren’t enough. To more comprehensively detect against all threats, NDR should evolve, and the following capabilities need to be considered.

Integrated IDS – Yes, IDS has been around for a while, and it may not be as sexy as all other new threat detection capabilities. But it’s tried and true. A comprehensive threat detection solution should incorporate an IDS to detect known threats. An integrated IDS complements machine-learning behavioral techniques.
Device context – For security teams that receive a threat alert about a potentially-compromised device, additional insights on that device are needed to move from “detection” to “response.” For example, information on what the device actually is that’s compromised, where it is located, data enrichment, business context, what actions are possible, how to prioritize those actions, what the compensating controls should be, and what actions to take if the device is offline. This means that while NDR may be a network-centric view of cybersecurity, organizations need to evolve to an asset-centric view of cybersecurity.
Network context – In addition to device context, you need to understand details about where a device is connected, what is the wireless/wired access, what are the “normal” network flows.
Retrospective analysis – New IoCs are constantly being generated as new criminal gangs form. A detection and response solution needs to incorporate the ability to ingest newly announced indicators of compromise, and determine if an infected device is already in the network. We know that attacks stay in the network for months at a time; retrospective analysis identifies compromised devices that have bypassed existing security controls so you can address security gaps that exist.
Response – and Remediate not just Detect and Respond – Automated response means everything during a security incident; you cannot just rely on SIEM (too much data to analyze), or SOAR (assumes the recipe to remediate is in place, which it may not be). A next-generation detection and response solution needs to be able to properly generate remediation policies or segmentation policies to quarantine an infected device and orchestrate action on appropriate networking/security infrastructure. The device and network context outlined earlier is the foundation for proper policy creation to allow a potentially compromised device appropriate access required for its role while limiting exposure. Creating the ability to implement, operate, and orchestrate efficient and effective policy drive automated actions.

*Note: These capabilities above are critical and should be added to NDR requirements. Ordr supports these features and more.

Ordr: The next level of detection and response

Ordr builds on all the accomplishments of the past and moves it to something unimaginable in the early days of cybersecurity — as different from the labor-intensive, incomplete manual methods as modern missile defense systems are from those civilian plane-spotter projects. Now you have a thorough, granular understanding of all devices, the ability to detect known and unknown threats, and an automated process for defending yourself. With Ordr, you know what devices are connected, what activities they’re executing, which ones are vulnerable, and how you can secure those devices at scale.

It’s a solution that is being embraced by organizations in a wide range of verticals that need to keep their guards up — healthcare, life sciences, government, manufacturing, retail, and enterprise in general.

We invite you to see Ordr in action and see how we can give you the complete protection your organization deserves.

In yet another sign that the vulnerability of the internet of things (IoT) is becoming a priority issue for both healthcare organizations that are adopting connected medical devices, and for a U.S. federal government concerned with mandating a stronger cybersecurity posture for America’s critical infrastructure and at-risk industries, Congress is now considering the bipartisan Protecting and Transforming Cyber Health Care (PATCH) Act of 2022. The PATCH Act (HR 7084) was introduced in the House of Representatives on March 15, and its companion bill (S 3983) was introduced in the Senate on March 31.

Intended to strengthen the security of connected medical devices—also known as the internet of medical things (IoMT)—the PATCH Act would compel medical device manufacturers to demonstrate that their products meet certain minimum security requirements before being approved for use. Among the mandatory measures:

A plan to monitor, identify, and address vulnerabilities and exploits within a reasonable time once devices are approved and in use;
A plan to coordinate communication and disclosure of any discovered vulnerabilities with the Food and Drug Administration (FDA);
Processes for patching vulnerabilities and other needed updates throughout a device’s entire lifecycle; and,
Disclosure of a software bill of materials (SBOM) to the FDA and device users.

The Threat is Real and Rising

The healthcare industry is among the most frequently targeted by threat actors, and heavily reliant on connected medical devices. One recent study found that as many as 75% of all medical devices contained at least one vulnerability, and another study found that the average hospital has an inventory of more than 3,850 IoMT devices. And, according to industry reports, 49% of smaller medical organizations don’t have a cyber-attack response plan in place, 679 U.S. hospitals were breached by cyberattacks in 2021, and the U.S. Department of Health and Human Services issued a warning that cyberattacks are likely to rise as cybergangs and state-sponsored hacker groups increase activity as a result of ongoing conflict in Eastern Europe.

Poor security and inadequate vulnerability disclosure is not just an issue plaguing the IoMT. EE Times recently reported that, across all use cases, the security of connected devices is a major concern, and that manufacturers of such products are not reporting known issues and vulnerabilities with their goods. Our research report—Rise of the Machines 2021: State of Connected devices — IT, IoT, IoMT and OT—found that, in addition to IoMT, healthcare networks are populated with devices like Pelotons, smart speakers, game consoles, vending machines, and many more unmanaged devices, compounding security challenges.

PATCH Act and Action Needed

Ordr supports the PATCH Act and its goals of increasing security for healthcare organizations and the welfare of the millions of patients who rely on them for treatment. However, hospitals and other healthcare organizations cannot afford to wait for the PATCH Act to take effect if it ever becomes law. The threat to their IT networks is real and present. We recommend the immediate adoption of a number of security best practices to effect stronger security now, and to increase readiness and resiliency in the event of an attack. These include:

Implement IoMT, IoT, and operational technology (OT) device discovery to compile and maintain a real-time inventory of devices: You can’t protect what you don’t know about. Security starts with real-time visibility of exactly what you have in your network and how those components are communicating in the network.
Monitor all devices for suspicious behavior: Unlike most IT systems and software, medical devices, and many IoT and OT devices have deterministic functions. Any deviation from normal patterns can be an indication of attack or compromise. Using machine learning to baseline normal device behavior can ensure rapid response and threat mitigation.
Track who is using your devices: By tracking and associating devices to users, you can identify compromised devices and also potential account misuse.
Implement Zero Trust segmentation for vulnerable devices that cannot be patched: Zero Trust segmentation policies can keep these devices in operations by allowing “normal communications” required for its function, while limiting exposure.

Ordr, an unprecedented three-time leader in healthcare IoT security as determined by the independent KLAS Research, has the tools and expertise to help healthcare organizations see, control, and secure their entire connected device inventory. The Ordr platform is trusted by many of the world’s leading healthcare delivery organizations. You can trust us to protect your healthcare organization, too.

Ordr Knowledge Base

Become A Partner