CONTACT US
1-844-4ZPE-SYS
ZPE CLOUD

Providing Out-of-Band Connectivity to Mission-Critical IT Resources

Home » Micro-segmentation » Page 6

Critical Entities Resilience Directive

by | Jun 5, 2024 | Application Hosting, Data Center Management, Data Center Resilience, Improve Network Security, Micro-segmentation, Minimize Impact of Disruptions, Monitoring & Reporting, Out of Band Management, Remote Network Management, Streamline Deployments, Vendor Neutral Platform, Zero Trust Security

Critical Entities Resilience Directive
The Critical Entities Resilience (CER) Directive is an EU regulation designed to prevent disruption to the services considered essential to society or the economy. The CER Directive outlines the obligations of critical entities to prepare for any potential hazard, including natural disasters, human errors, terrorist attacks, and cybersecurity breaches. EU Member States have until 17 October 2024 to adopt and publish resilience measures required for their critical entities, and those measures officially take effect from 18 October 2024. Member States must identify and notify critical entities by July 2026; these entities then only have ten months to comply with CER requirements. With such a tight timeframe to demonstrate compliance with the Critical Entities Resilience Directive, organizations that might be deemed critical should begin preparing their resilience strategies now.

Citation: Directive (EU) 2022/2557 of the European Parliament and of the Council of 14 December 2022 on the resilience of critical entities and repealing Council Directive 2008/114/EC

Who does the Critical Entities Resilience Directive apply to, and why does it matter?

The CER Directive covers eleven sectors and subsectors that provide services essential to society, the economy, public health & safety, or preserving the environment. These include:

In-Scope Sectors Covered by the CER Directive
Sector Subsectors
Energy
  • Electricity
  • Heating and cooling
  • Oil & gas
  • Hydrogen
Transport
  • Air
  • Rail
  • Water
  • Road
  • Public transportation
Banking
  • Deposit, lending, and credit institutions
Financial Market Infrastructure
  • Trading venues
  • Clearing systems
Health
Drinking Water
  • Drinking water suppliers
  • Drinking water distributors
Waste Water
  • Collection
  • Treatment
  • Disposal
Digital Infrastructure
Public Administration
Space
  • Operators of ground-based infrastructure for space-based services
Food Production, Processing, and Distribution
  • Large-scale industrial food production and processing
  • Food supply chain services
  • Food wholesale distributors

The Critical Entities Resilience Directive is one of several new EU regulations (such as DORA and NIS2) created to establish consistent guidelines for resilience in sectors where any service disruption has a significant negative impact on society or the economy. Whereas DORA applies primarily to financial institutions and supporting services, and NIS2 focuses on cybersecurity threats, the CER Directive is broader in scope and addresses other, non-digital threats to resilience such as natural disasters and global health crises (e.g., COVID-19).

The penalties for noncompliance will vary by Member State but are likely to include fines, public notification, remediation, and withdrawal of authorization.

CER Directive requirements for critical entities

Most of the CER Directive requirements apply to Member States, outlining how the designated authorities will adopt and enforce resilience measures and support critical entities in achieving compliance. However, there are five key provisions that relevant organizations should be aware of as they prepare for their identification as critical entities.

1. Article 4: Strategy on the resilience of critical entities

EU Member States have until 17 January 2026 to adopt a strategy outlining the guidelines and procedures for critical entities to achieve and maintain a high level of resilience. Essentially, this strategy will describe the requirements for CER Directive compliance in each Member State and provide guidance on how to meet those requirements. Potentially critical entities can prepare by examining existing resilience frameworks and regulations to anticipate the policies, tools, and procedures that will likely be required.

2. Article 5: Risk assessment by Member States

Member States have until 17 January 2026 to perform a risk assessment of all essential services. These assessments must account for natural and human-made risks, including accidents, natural disasters, public health emergencies, terrorist attacks, and antagonistic threats. Member States will then use the risk assessments to identify critical entities within each sector.

3. Article 12: Risk assessment by critical entities

Critical entities must perform risk assessments using similar criteria to Article 5 within nine months of being notified of their designation as critical and at least every four years afterward. If an organization already conducts risk assessments according to other similar resilience guidelines or frameworks, Member States have the authority to decide whether or not those assessments meet CER Directive compliance requirements.

4. Article 13: Resilience measures of critical entities

Critical entities must take the appropriate technical, security, and policy measures to ensure resilience, including a comprehensive strategy for service continuity and disaster recovery. Examples of resilience measures outlined by the CER Directive include:

CER Directive Resilience Measures
Requirements Examples
Adopt disaster risk reduction and climate adaptation measures Using an environmental monitoring system to detect and respond to rising temperatures, humidity, and other relevant conditions
Ensure adequate physical protection of the premises and critical infrastructure, including fencing, barriers, perimeter monitoring tools, detection equipment, and access controls Installing proximity sensors in data center racks to automatically notify security teams if an unauthorized user physically tampers with remote infrastructure
Respond to, resist, and mitigate service disruptions Deploying out-of-band (OOB) serial consoles with cellular capabilities to ensure continuous remote management access to critical infrastructure
Recover from incidents using business continuity measures to resume provisioning essential services Building a resilience system containing all the infrastructure and tools needed to rebuild and recover while still delivering core services
Manage employee security by classifying personnel who exercise critical functions, establishing access rights and controls, and performing background checks as needed Adopting zero-trust security policies and controls that assign access privileges according to role (role-based access control, or RBAC)

5. Article 15: Incident notification

Critical entities must notify the competent authority of any incidents that have or could significantly disrupt essential services within 24 hours of detection. The significance of a disruption is determined according to the following parameters:

  • How many users the disruption affects;
  • How long the disruption lasts;
  • The geographical area the disruption affects.

The incident notification must explain the nature, cause, and potential consequences of the disruption, including any cross-border implications.

How Nodegrid simplifies CER Directive compliance

Nodegrid is a Gen 3 out-of-band management platform that makes the perfect foundation for a resilience system. Nodegrid OOB separates the control plane from the data plane to ensure continuous remote management access to critical infrastructure even during production network outages. Vendor-neutral serial consoles and integrated branch service routers directly host third-party software for security, automation, recovery, and more, reducing hardware overhead at each site while ensuring teams have access to all the tools they need to restore essential services.

Looking to Upgrade to a Nodegrid serial console?

Prepare for the Critical Entities Resilience Directive by replacing your discontinued, EOL serial console with a Gen 3 out-of-band solution from Nodegrid.

Click here to learn more!

Read more about network resilience:

PCI DSS 4.0 Requirements

by | May 15, 2024 | Data Center Management, Improve Network Security, Increase Productivity, Micro-segmentation, Minimize Impact of Disruptions, Modernize Legacy Environments, Monitoring & Reporting, NetDevOps, Network Automation, Out of Band Management, Remote Network Management, Serial Consoles, Streamline Deployments, Vendor Neutral Platform, Zero Trust Security

Businessman,Using,Virtual,Touch,Screen,Clicks,Abbreviation:,Pci,Dss.,Concept
The Security Standards Council (SSC) of the Payment Card Industry (PCI) released the version 4.0 update of the Data Security Standard (DSS) in March 2022. PCI DSS 4.0 applies to any organization in any country that accepts, handles, stores, or transmits cardholder data. This standard defines cardholder data as any personally identifiable information (PII) associated with someone’s credit or debit card. The risks for PCI DSS 4.0 noncompliance include fines, reputational damage, and potentially lost business, so organizations must stay up to date with all recent changes.

The new requirements cover everything from protecting cardholder data to implementing user access controls, zero trust security measures, and frequent penetration (pen) testing. Each major requirement defined in the updated PCI DSS 4.0 is summarized below, with tables breaking down the specific compliance stipulations and providing tips or best practices for meeting them.

Citation: The PCI DSS v4.0

PCI DSS 4.0 requirements and best practices

Every PCI DSS 4.0 requirement starts with a stipulation that the processes and mechanisms for implementation are clearly defined and understood. The best practice involves updating policy and process documents as soon as possible after changes occur, such as when business goals or technologies evolve, and communicating changes across all relevant business units.

Jump to the other requirements below:

Build and maintain a secure network and systems

Requirement 1: Install and maintain network security controls

Network security controls include firewalls and other security solutions that inspect and control network traffic. PCI DSS 4.0 requires organizations to install and properly configure network security controls to protect payment card data.

Stipulations for Compliance

Best Practices

Network security controls (NSCs) are configured and maintained.

Validate network security configurations before deployment and use configuration management to track changes and prevent configuration drift.

Network access to and from the cardholder data environment (CDE) is restricted.

Monitor all inbound traffic to the CDE, even from trusted networks, and, when possible, use explicit “deny all” firewall rules to prevent accidental gaps.

Network connections between trusted and untrusted networks are controlled.

Implement a DMZ that manages connections between untrusted networks and public-facing resources on the trusted network.

Risks to the CDE from computing devices that can connect to both untrusted networks and the CDE are mitigated.

Use security controls like endpoint protection and firewalls to protect devices from Internet-based attacks and zero-trust and network segmentation to prevent lateral movement to CDEs.

Requirement 2: Apply secure configurations to all system components

Attackers often compromise systems using known default passwords or old, forgotten services. PCI DSS 4.0 requires organizations to properly configure system security settings and reduce the attack surface by turning off unnecessary software, services, and accounts.

Stipulations for Compliance

Best Practices

System components are configured and managed securely.

Continuously check for vendor-default user accounts and security configurations and ensure all administrative access is encrypted using strong cryptographic protocols.

Wireless environments are configured and managed securely.

Apply the same security standards consistently across wired and wireless environments, and change wireless encryption keys whenever someone leaves the organization.

Protect account data

Requirement 3: Protect stored account data

Any payment account data an organization stores must be protected by methods such as encryption and hashing. Organizations should also limit account data storage unless it’s necessary and, when possible, truncate cardholder data.

Stipulations for Compliance

Best Practices

Storage of account data is kept to a minimum.

Use data retention and disposal policies to configure an automated, programmatic procedure to locate and remove unnecessary account data.

Sensitive authentication data (SAD) is not stored after authorization.

Review data sources to ensure that the full contents of any track, card verification code, and PIN/PIN blocks are not retained after the authorization process is completed.

Access to displays of full primary account number (PAN) and ability to copy cardholder data are restricted.

Use role-based access control (RBAC) to limit PAN access to individuals with a defined need and use the masking approach to display only the number of digits needed for a specific function.

PAN is secured wherever it is stored.

Render PAN unreadable using one-way hashing with a randomly generated secret key, truncation, index tokens, and strong cryptography with secure key management.

Cryptographic keys used to protect stored account data are secured.

Manage cryptographic keys with a centralized key management system that’s PCI DSS 4.0 compliant to restrict access to key-encrypting keys and store them separately from data-encrypting keys.

Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

Use a key management solution that simplifies or automates key replacement for old or compromised keys.

Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks

While requirement 3 applies to stored card data, requirement 4 outlines stipulations for protecting cardholder data in transit.

Stipulations for Compliance

Best Practices

PAN is protected with strong cryptography during transmission.

Encrypt PAN over both public and internal networks and apply strong cryptography at both the data level and the session level.

Maintain a vulnerability management program

Requirement 5: Protect all systems and networks from malicious software

Organizations must take steps to prevent malicious software (a.k.a., malware) from infecting the network and potentially exposing cardholder data.

Stipulations for Compliance

Best Practices

Malware is prevented, or detected and addressed.

Use a combination of network-based controls, host-based controls, and endpoint security solutions; supplement signature-based tools with AI/ML-powered detection.

Anti-malware mechanisms and processes are active, maintained, and monitored.

Update tools and signature databases as soon as possible and prevent end-users from disabling or altering anti-malware controls.

Anti-phishing mechanisms protect users against phishing attacks.

Use a combination of anti-phishing approaches, including anti-spoofing controls, link scrubbers, and server-side anti-malware.

Requirement 6: Develop and maintain secure systems and software

Development teams should follow PCI-compliant processes when writing and validating code. Additionally, install all appropriate security patches immediately to prevent malicious actors from exploiting known vulnerabilities in systems and software.

Stipulations for Compliance

Best Practices

Bespoke and custom software are developed securely.

Use manual or automatic code reviews to search for undocumented features, validate that third-party libraries are used securely, analyze insecure code structures, and check for logical vulnerabilities.

Security vulnerabilities are identified and addressed.

Use a centralized patch management solution to automatically notify teams of known vulnerabilities and pending updates.

Public-facing web applications are protected against attacks.

Use automatic vulnerability security assessment tools that include specialized web scanners that analyze web application protection.

Changes to all system components are managed securely.

Use a centralized source code version management solution to track, approve, and roll back changes.

Implement strong access control measures

Requirement 7: Restrict access to system components and cardholder data by business need-to-know

This PCI DSS 4.0 requirement aims to limit who and what has access to sensitive cardholder data and CDEs to prevent malicious actors from gaining access through a compromised, over-provisioned account. “Need to know” means that only accounts with a specific need should have access to sensitive resources; it’s often applied using the “least-privilege” approach, which means only granting accounts the specific privileges needed to perform a job role.

Stipulations for Compliance

Best Practices

Access to system components and data is appropriately defined and assigned.

Use RBAC to provide accounts with access privileges based on their job functions (e.g., ‘customer service agent’ or ‘warehouse manager’) rather than on an individual basis.

Access to system components and data is managed via an access control system.

Use a centralized identity and access management (IAM) system to manage access across the enterprise, including branches, edge computing sites, and the cloud.

Requirement 8: Identify users and authenticate access to system components

Organizations must establish and prove the identity of any users attempting to access CDEs or sensitive data. This requirement is core to the zero trust security methodology which is designed to limit the scope of data access and theft once an attacker has already compromised an account or system.

Stipulations for Compliance

Best Practices

User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.

Use an account lifecycle management solution to streamline account discovery, provisioning, monitoring, and deactivation.

Strong authentication for users and administrators is established and managed.

Replace relatively weak passwords/passphrases with stronger authentication factors like hardware tokens or biometrics.

Multi-factor authentication (MFA) is implemented to secure access into the CDE.

MFA should also protect access to management interfaces on isolated management infrastructure (IMI) to prevent attackers from controlling the CDE.

MFA systems are configured to prevent misuse.

Secure the MFA system itself with strong authentication and validate MFA configurations before deployment to ensure it requires two different forms of authentication and does not allow any access without a second factor.

Use of application and system accounts and associated authentication factors is strictly managed.

Whenever possible, disable interactive login on system and application accounts to prevent malicious actors from logging in with them.

Requirement 9: Restrict physical access to cardholder data

Malicious actors could gain access to cardholder data by physically interacting with payment devices or tampering with the hardware infrastructure that stores and processes that data. These PCI DSS 4.0 requirements outline how to prevent physical data access.

Stipulations for Compliance

Best Practices

Physical access controls manage entry into facilities and systems containing cardholder data.

Use logical or physical controls to prevent unauthorized users from connecting to network jacks and wireless access points within the CDE facility.

Physical access for personnel and visitors is authorized and managed.

Require visitor badges and an authorized escort for any third parties accessing the CDE facility, and keep an accurate log of when they enter and exit the building.

Media with cardholder data is securely stored, accessed, distributed, and destroyed.

Do not allow portable media containing cardholder data to leave the secure facility unless absolutely necessary.

Point of interaction (POI) devices are protected from tampering and unauthorized substitution.

Use a centralized, vendor-neutral asset management system to automatically discover and track all POI devices in use across the organization.

Use of application and system accounts and associated authentication factors is strictly managed.

Whenever possible, disable interactive login on system and application accounts to prevent malicious actors from logging in with them.

Regularly monitor and test networks

Requirement 10: Log and monitor all access to system components and cardholder data

User activity logging and monitoring will help prevent, detect, and mitigate CDE breaches. PCI DSS 4.0 requires organizations to collect, protect, and review audit logs of all user activities in the CDE.

Stipulations for Compliance

Best Practices

Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

Use a user and entity behavior analytics (UEBA) solution to monitor user activity and detect suspicious behavior with machine learning algorithms.

Audit logs are protected from destruction and unauthorized modifications.

Never store audit logs in public-accessible locations; use strong RBAC and least-privilege policies to limit access.

Audit logs are reviewed to identify anomalies or suspicious activity.

Use an AIOps tool to analyze audit logs, detect anomalous activity, and automatically triage and notify teams of issues.

Audit log history is retained and available for analysis.

Retain audit logs for at least 12 months in a secure storage location; keep the last three months of logs immediately accessible to aid in breach resolution.

Time-synchronization mechanisms support consistent time settings across all systems.

Use NTP to synchronize clocks across all systems to help with breach mitigation and post-incident forensics.

Failures of critical security control systems are detected, reported, and responded to promptly.

Use AIOps to automatically detect, triage, and respond to security incidents. AIOps also provides automatic root-cause analysis (RCA) for faster incident resolution.

Requirement 11: Test security of systems and network regularly

Researchers and attackers continuously discover new vulnerabilities in systems and software, so organizations must frequently test network components, applications, and processes to ensure that in-place security controls are still adequate. ge changes; ensure alerts are monitored.

Stipulations for Compliance

Best Practices

Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.

Use a wireless analyzer to detect rogue access points.

External and internal vulnerabilities are regularly identified, prioritized, and addressed.

PCI DSS 4.0 requires internal and external vulnerability scans at least once every three months, but performing them more often is encouraged if your network is complex or changes frequently.

External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.

Work with a PCI DSS-approved vendor to perform external and internal penetration testing; conduct pen testing on network segmentation controls.

Network intrusions and unexpected file changes are detected and responded to.

Use AI-powered, next-generation firewalls (NGFWs) with enhanced detection algorithms and automatic incident response capabilities.

Unauthorized changes on payment pages are detected and responded to.

Use anti-skimming technology like file integrity monitoring (FIM) to detect unauthorized payment page changes; ensure alerts are monitored.

Maintain an information security policy

Requirement 12: Support information security with organizational policies and programs

The final requirement is to implement information security policies and programs to support the processes described above and get everyone on the same page about their responsibilities regarding cardholder data privacy.

Stipulations for Compliance

Best Practices

Acceptable use policies for end-user technologies are defined and implemented.

Enforce usage policies with technical controls capable of locking users out of systems, applications, or devices if they violate these policies.

Risks to the cardholder data and environment are formally identified, evaluated, and managed.

Use a centralized patch management system to monitor firmware and software versions, detect changes that may increase risk, and deploy updates to fix vulnerabilities.

PCI DSS compliance is managed.

Service providers must assign executive responsibility for managing PCI DSS 4.0 compliance.

PCI DSS scope is documented and validated.

Frequently validate PCI DSS scope by evaluating the CDE and all connected systems to determine if coverage should be expanded.

Security awareness education is an ongoing activity.

Require all users to take security awareness training upon hire and every year afterwards; it’s also recommended to provide refresher training when someone transfers into a role with more access to sensitive data.

Personnel are screened to reduce risks from insider threats.

In addition to screening new hires, conduct additional screening when someone moves into a role with greater access to the CDE.

Risk to information assets associated with third-party service provider (TPSP) relationships is managed.

Thoroughly analyze the risk of working with third-parties based on their reporting practices, breach history, incident response procedures, and PCI DSS validation.

Third-party service providers (TPSPs) support their customers’ PCI DSS compliance.

Require TPSPs to provide their PCI DSS Attestation of Compliance (AOC) to demonstrate their compliance status.

Suspected and confirmed security incidents that could impact the CDE are responded to immediately.

Create a comprehensive incident response plan that designates roles to key stakeholders.

Isolate your CDE and management infrastructure with Nodegrid

The Nodegrid out-of-band (OOB) management platform from ZPE Systems isolates your control plane and provides a safe environment for cardholder data, management infrastructure, and ransomware recovery. Our vendor-neutral, Gen 3 OOB solution allows you to host third-party tools for automation, security, troubleshooting, and more for ultimate efficiency.

Ready to know more about PCI DSS 4.0 Requirements?

Learn how to meet PCI DSS 4.0 requirements for network segmentation and security by downloading our isolated management infrastructure (IMI) solution guide.
Download the Guide

Opengear Alternatives for the OM2200 and OM1200

by | Apr 15, 2024 | Failover Connectivity, Improve Network Security, Increase Productivity, Micro-segmentation, Minimize Impact of Disruptions, Out of Band Management, Remote Network Management, Serial Consoles, Simplify Branch Infrastructure

NSRSTACK2-1
The Opengear Operations Manager is a series of NetOps console servers providing out-of-band remote access to manage remote network infrastructure in data center, edge, and branch deployments. There are a few reasons to consider alternative options, including a lack of 3rd-party integrations, 5G support, and gateway routing capabilities. This blog goes over the pros and cons of the Operations Manager solutions before discussing Opengear alternatives that provide greater automation, orchestration, and security features as well as all-in-one branch networking capabilities.

Table of contents

Executive summary

  • Opengear’s Operations Manager (OM) appliances are NetOps console servers providing out-of-band (OOB) management for remote network infrastructure.
  • While OM appliances provide some automation capabilities, especially with the upgraded Automation Edition, they offer limited third-party integrations and end-device automation features.
  • The OM2200 and OM1200 both lack integrated branch gateway functionality and have limited security features overall.
  • The Nodegrid platform from ZPE Systems overcomes these limitations with vendor-neutral OOB serial consoles and branch services routers.
  • Nodegrid enables end-to-end automation through end-device ZTP and unlimited third-party integrations with leading tools like Ansible and Chef.
  • Nodegrid also consolidates data center and branch networking functionality like gateway routing, 5G cellular failover, and security to provide all-in-one solutions.

Reviewing the Opengear Operations Manager platform

Operations Manager (or OM) is Opengear’s line of NetOps console servers. OM appliances come with Smart OOBTM for out-of-band management, including automated port discovery and VLAN support. Opengear’s x86 Lighthouse platform supports Python scripts and Docker container deployments for NetOps automation. Lighthouse also supports over 100 power vendors’ equipment, allowing it to monitor and control UPS batteries, PDU outlets, and power load balancing. It’s important to note that, while the standard (Enterprise) edition of Lighthouse supports Python and Docker, customers must upgrade to the Automation edition for zero-touch provisioning (ZTP) or other third-party automation integrations. Additionally, OM solutions do not support 2FA or SAML authentication.

Opengear OM2200

The Opengear OM2200 Operations Manager model is designed for data center and high-density use cases. It features 16, 32, 48 serial and 24 serial/Ethernet mixed port configuration options, with an optional global LTE-A Pro cellular module. The OM2200 provides five regional options for dual AC power as well as a dual DC power cord model.

Click here to see a complete Opengear OM2200 Operations Manager product SKUs list.

OM2200 Pros:

  • Plenty of RAM and storage space
  • Many options for power and serial port configurations
  • Uniquely broad support for 3rd-party power equipment
  • Some NetOps automation capabilities

OM2200 Cons:

  • Requires upgraded software licenses for ZTP and most 3rd-party automation
  • No 2FA or SAML 2.0 support
  • No managed USB serial ports
  • No 5G support

Opengear OM1200

The Opengear OM1200 Operations Manager model is meant for small edge deployments. The compact chassis supports 4 serial, 8 serial, and 8 serial/8 Ethernet port combinations. It provides OOB and failover access via dual Ethernet (SFP Fiber is available on the 4E and 8E models) as well as an optional global LTE-A Pro cellular module.

Click here to see a full list of Opengear OM1200 Operations Manager product SKUs.

OM1200 Pros:

  • Compact size
  • Cost-effective range of port configurations
  • Supports 3rd-party power equipment, Docker, and Python

OM1200 Cons:

  • Requires upgraded software licenses for ZTP and most 3rd-party automation
  • No 2FA or SAML 2.0 support
  • It doesn’t have gateway routing/SD-WAN capabilities
  • No 5G support

Opengear Operations Manager limitations

Both the OM2200 and OM1200 models suffer from similar limitations regarding automation, especially with the base version of the Lighthouse software. Even the upgraded Automation Edition, which unlocks ZTP and RESTful APIs, doesn’t provide much automation for end devices beyond running Python playbooks. This limits operational efficiency, slows down new deployments, and impedes the team’s ability to quickly rebuild core infrastructure after a failure or ransomware attack. Another issue with the OM1200, in particular, is that while its compact size will save space in your edge data center and branch office rack, it’s still a single-purpose device. That means you still need to purchase separate solutions for gateway routing, switching, and/or edge compute. These additional devices take up space, cost extra money, and require time to configure and manage.

Opengear alternatives from ZPE Systems

ZPE Systems provides an alternative option for NetOps-enabled OOB console servers called the Nodegrid solution. All Nodegrid devices run on the open, Linux-based, x86 Nodegrid OS which supports VMs and Docker containers to run your choice of third-party automation, software-defined networking/SD-WAN, and security applications. Nodegrid’s robust, onboard security protects lost or stolen devices with features like TPM 2.0, encrypted SSD, UEFI BIOS, secure boot, and geofencing. Nodegrid can also extend ZTP and other automation to legacy and mixed-vendor end devices for end-to-end network infrastructure automation. Try ZPE’s product selector to see which of Nodegrid’s serial consoles or integrated branch routers is right for your deployment. Below, we review the two models that serve as direct replacements for the Opengear OM1200 and OM2200 solutions.

Nodegrid Serial Console Plus (NSCP)

The Nodegrid Serial Console Plus (NSCP) is an alternative to the OM2200 for data center and high-density deployments. The NSCP connects 16, 32, 48, or 96 (Patent No. 9,905,980) serial devices, all in a standard 1U rackmount chassis. Dual SFP+, dual Gigabit Ethernet, and optional Wi-FI and 4G/5G LTE modules provide secure Gen 3 OOB management access and failover, ensuring blazing fast speeds and high performance. Plus, the NSCP comes with two managed USB 3.0 ports for additional flexibility.

Click here to see a complete list of Nodegrid NSCP product SKUs.

Nodegrid Net Services Router (NSR)

The Nodegrid Net Services Router (NSR) is an alternative to the OM1200 for edge data center and branch office use cases. The NSR is a modular, compact device that can deliver gateway routing, switching, serial console, and compute capabilities all in a single appliance. Gen 3 OOB and network failover are provided out of the box via dual SFP+ and dual Gigabit Ethernet ports, with optional modules for WiFi and dual-SIM 5G/4G LTE. Additional NSR modules include:

  • 16-port GbE Ethernet
  • Storage
  • 16-port Serial (for console server capabilities)
  • 16-port USB serial
  • Compute
  • 8-port PoE+
  • M.2 Cellular/Wi-Fi/SATA
  • 16-port GbE Ethernet SFP
  • 8-port Ethernet SFP+

Click here to see a complete list of Nodegrid NSCP product SKUs.

Key takeaways:

While the OM1200 and OM2200 provide OOB management with some automation, they have serious limitations that negatively impact operational efficiency. Nodegrid is an Opengear alternative providing a vendor-neutral OOB management platform that delivers unlimited automation, enhanced security, and all-in-one networking for ultimate operational efficiency.

Trade in to get a discount on Opengear alternatives

If you’re ready to replace end-of-life devices from Opengear or other vendors, now’s your chance to get a discount. Visit our trade-in page to get your trade-in offer.
Get Trade-In Offer

See Nodegrid’s Opengear Alternatives in action

Reach out today to view a demo of Nodegrid’s Opengear alternatives in action.
Request a Demo

Opengear OM2200 – Product SKU’s:

OM2216

16 x Serial, 8GB RAM, 64GB SSD, 8 x USB 2.0, 2 x GbE/SFP Fiber

OM2216-AU

Dual AC – Australian power cord

OM2216-EU

Dual AC – European Union power cord

OM2216-JP

Dual AC – Japanese power cord

OM2216-UK

Dual AC – United Kingdom power cord

OM2216-US

Dual AC – United States power cord

OM2216-DDC

Dual DC power

OM2216-L-AU

Global 4G LTE-A Pro cellular module, Dual AC – AU power cord

OM2216-L-EU

Global 4G LTE-A Pro cellular module, Dual AC – EU power cord

OM2216-L-JP

Global 4G LTE-A Pro cellular module, Dual AC – JP power cord

OM2216-L-UK

Global 4G LTE-A Pro cellular module, Dual AC – UK power cord

OM2216-L-US

Global 4G LTE-A Pro cellular module, Dual AC – US power cord

OM-2216-DDC-L

Global 4G LTE-A Pro cellular module, Dual DC power

 

OM2224-24E

24 x Serial, 24 x GbE, 8GB RAM, 64GB Flash

OM2224-24E-AU

1 x GbE/SFP, Dual AC – Australian power cord

OM2224-24E-EU

1 x GbE/SFP, Dual AC – European Union power cord

OM2224-24E-JP

1 x GbE/SFP, Dual AC – Japanese power cord

OM2224-24E-UK

1 x GbE/SFP, Dual AC – United Kingdom power cord

OM2224-24E-US

1 x GbE/SFP, Dual AC – United States power cord

OM2224-24E-DDC

1 x GbE/SFP, Dual DC power

OM2224-24E-L-AU

1 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – AU power cord

OM2224-24E-L-EU

1 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – EU power cord

OM2224-24E-L-JP

1 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – JP power cord

OM2224-24E-L-UK

1 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – UK power cord

OM2224-24E-L-US

1 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – US power cord

OM2224-24E-DDC-L

1 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual DC power

OM2224-24E-10G-AU

10 x GbE/SFP, Dual AC – AU power cord

OM2224-24E-10G-EU

10 x GbE/SFP, Dual AC – EU power cord

OM2224-24E-10G-JP

10 x GbE/SFP, Dual AC – JP power cord

OM2224-24E-10G-UK

10 x GbE/SFP, Dual AC – UK power cord

OM2224-24E-10G-US

10 x GbE/SFP, Dual AC – US power cord

OM2224-24E-10G-DDC

10 x GbE/SFP, Dual DC power

OM2224-24E-10G-L-AU

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – AU power cord

OM2224-24E-10G-L-EU

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – EU power cord

OM2224-24E-10G-L-JP

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – JP power cord

OM2224-24E-10G-L-UK

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – UK power cord

OM2224-24E-10G-L-US

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – US power cord

OM2224-24E-10G-DDC-L

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual DC power

 

OM2232

32 x Serial, 8GB RAM, 64GB SSD, 2 x GbE/SFP Fiber

OM2232-AU

Dual AC – Australian power cord

OM2232-EU

Dual AC – European Union power cord

OM2232-JP

Dual AC – Japanese power cord

OM2232-UK

Dual AC – United Kingdom power cord

OM2232-US

Dual AC – United States power cord

OM2232-DDC

Dual DC power

OM2232-L-AU

Global 4G LTE-A Pro cellular module, Dual AC – AU power cord

OM2232-L-EU

Global 4G LTE-A Pro cellular module, Dual AC – EU power cord

OM2232-L-JP

Global 4G LTE-A Pro cellular module, Dual AC – JP power cord

OM2232-L-UK

Global 4G LTE-A Pro cellular module, Dual AC – UK power cord

OM2232-L-US

Global 4G LTE-A Pro cellular module, Dual AC – US power cord

OM2232-DDC-L

Global 4G LTE-A Pro cellular module, Dual DC power

 

OM2248

48 x Serial, 8GB RAM, 64GB SSD

OM2248-AU

2 x GbE/SFP, Dual AC – Australian power cord

OM2248-EU

2 x GbE/SFP, Dual AC – European Union power cord

OM2248-JP

2 x GbE/SFP, Dual AC – Japanese power cord

OM2248-UK

2 x GbE/SFP, Dual AC – United Kingdom power cord

OM2248-US

2 x GbE/SFP, Dual AC – United States power cord

OM2248-DDC

2 x GbE/SFP, Dual DC power

OM2248-L-AU

2 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – AU power cord

OM2248-L-EU

2 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – EU power cord

OM2248-L-JP

2 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – JP power cord

OM2248-L-UK

2 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – UK power cord

OM2248-L-US

2 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – US power cord

OM2248-DDC-L

2 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual DC power

OM2248-10G-AU

10 x GbE/SFP, Dual AC – AU power cord

OM2248-10G-EU

10 x GbE/SFP, Dual AC – EU power cord

OM2248-10G-JP

10 x GbE/SFP, Dual AC – JP power cord

OM2248-10G-UK

10 x GbE/SFP, Dual AC – UK power cord

OM2248-10G-US

10 x GbE/SFP, Dual AC – US power cord

OM2248-10G-DDC

10 x GbE/SFP, Dual DC power

OM2248-10G-L-AU

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – AU power cord

OM2248-10G-L-EU

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – EU power cord

OM2248-10G-L-JP

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – JP power cord

OM2248-10G-L-UK

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – UK power cord

OM2248-10G-L-US

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual AC – US power cord

OM2248-10G-DDC-L

10 x GbE/SFP, Global 4G LTE-A Pro cellular module, Dual DC power

Opengear OM1200 – Product SKU’s

OM1204

4 x Serial, 2GB RAM, 16GB Flash, 1 x GbE

OM1204-L

4 x Serial, 2GB RAM, 16GB Flash, 1 x GbE, Global 4G LTE

OM1204-4E

4 x Serial, 4 x GbE, 4GB RAM, 16GB Flash, 1 x GbE SFP 

OM1204-4E-L

4 x Serial, 4 x GbE, 4GB RAM, 16GB Flash, 1 x GbE SFP, Global 4G LTE 

OM1208

8 x Serial, 2GB RAM, 16GB Flash, 1 x GbE

OM1208-L

8 x Serial, 2GB RAM, 16GB Flash, 1 x GbE, Global 4G LTE

OM1208-8E

8 x Serial straight X2 pinout, 8 x GbE switch, 4GB RAM, 16GB SSD, 2 x USB 2.0, 2 x GbE/SFP Fiber

OM1208-8E-L

8 x Serial straight X2 pinout, 8 x GbE switch, 4GB RAM, 16GB SSD, 2 x USB 2.0, 2 x GbE/SFP Fiber, Global 4G LTE

Nodegrid Serial Console Plus – Product SKU’s

Nodegrid Serial Console Plus (NSCP)

4-Core Intel CPU, 4GB DDR4 RAM, 32GB SSD, 2 x SFP+, 2 x GbE, 2 x USB 3.0, 1 x HDMI, 1 x Console

NSCP-T16R-STND-SAC

16 x Cisco Rolled Serial, Single AC power

NSCP-T16R-STND-DAC

16 x Cisco Rolled Serial, Dual AC power

NSCP-T16R-STND-DDC

16 x Cisco Rolled Serial, Dual AC power

NSCP-T32R-STND-SAC

32 x Cisco Rolled Serial, Single AC power

NSCP-T32R-STND-DAC

32 x Cisco Rolled Serial, Dual AC power

NSCP-T32R-STND-DDC

32 x Cisco Rolled Serial, Dual DC power

NSCP-T48R-STND-SAC

48 x Cisco Rolled Serial, Single AC power

NSCP-T48R-STND-DAC

48 x Cisco Rolled Serial, Dual AC power

NSCP-T48R-STND-DDC

48 x Cisco Rolled Serial, Dual DC power

NSCP-T96R-STND-SAC

96 x Cisco Rolled Serial, Single AC power

NSCP-T96R-STND-DAC

96 x Cisco Rolled Serial, Dual AC power

NSCP-T96R-STND-DDC

96 x Cisco Rolled Serial, Dual DC power

Nodegrid Net SR – Product SKU’s

Nodegrid Net Services Router (NSR)

Multi-Core Intel CPU, On-board Switch, 8GB DDR4 RAM, 32GB MSATA, Hot-Swappable Fans, 2 x SFP+, 2 x GbE

NSR-TOP1-DAC

Dual AC power, 5 Slots support

NSR-BASE-DAC

Dual AC power, 3 Slots support

NSR-TOP1-SAC

Single AC power, 5 Slots support

NSR-BASE-SAC

Single AC power, 3 Slots support

NSR-TOP1-SAC-POE

Single AC and PoE, 5 Slots support

NSR-BASE-SAC-POE

Single AC and PoE, 3 Slots support

Expansion Cards

NSR-16ETH-EXPN

16 x GbE Ethernet expansion card

NSR-8ETH-POE-EXPN

8 x GbE Ethernet with PoE+ expansion card

NSR-16SRL-EXPN

16 x RJ45 Serial Rolled expansion card

NSR-16USB-EXPN

16 x USB Type A expansion card

NSR-8SFP-EXPN

8 x 10GbE SFP expansion card

NSR-DISK-EXPN

Storage expansion card

NSR-COMP-EXPN

Compute 4-core, 8GB DDR4, 32GB SATA expansion card

NSR-M2-EXPN

M.2/SATA Expansion Card

The Future of Edge Computing

by | Mar 18, 2024 | Actionable Data, Application Hosting, Consolidation, Edge Computing, Micro-segmentation, Monitoring & Reporting, Network Automation, Network Edge Orchestration, Out of Band Management, Remote Network Management, Simplify Branch Infrastructure, Streamline Deployments, Vendor Neutral Platform, Virtualization, Zero Trust Security

The Future of Edge Computing
Edge computing moves computing resources and data processing applications out of the centralized data center or cloud, deploying them at the edges of the network and allowing companies to use their edge data in real-time. An explosion in edge data generated by Internet of Things (IoT) sensors, automated operational technology (OT), and other remote devices has created a high demand for edge computing solutions. A recent report from Grand View Research valued the edge computing market size at $16.45 billion in 2023 and predicted it to grow at a compound annual growth rate (CAGR) of 37.9% by 2030.

The current edge computing landscape comprises solutions focused on individual use cases,  lacking interoperability and central orchestration. The future of edge computing, as described by leading analysts at Gartner, depends on unifying the edge computing ecosystem with comprehensive strategies and centralized, vendor-neutral management and orchestration. This future relies on edge-native applications that integrate seamlessly with upstream resources, remote management, and orchestration while still being able to operate independently.

Where is edge computing now?

Many organizations already use edge computing technology to solve individual problems or handle specific workloads. For example, a manufacturing department may deploy an edge computing application to analyze log data and provide predictive maintenance recommendations for a single type of machine or assembly line. A single company may have a dozen or more disjointed edge computing solutions in use throughout the network, creating visibility and management headaches for IT teams. This piecemeal approach to edge computing results in what Gartner calls “edge sprawl”: many disparate solutions deployed without centralized control, security, or visibility. Edge sprawl increases management complexity and risk while decreasing operational efficiency, creating significant roadblocks for digital transformation initiatives.

Additionally, many organizations misunderstand edge computing by thinking it’s just about moving computing resources as close to the edge as possible to collect data. In reality, the true potential of the edge involves using edge data in real-time, gaining “cloud-in-a-box” capability that works in concert with the network’s upstream resources.

Anticipating the future of edge computing

At Gartner’s 2023 IT Infrastructure Operations & Cloud Strategies Conference, edge technology experts predicted that, by 2025, enterprises will create and process more than 50% of their data outside the centralized data center or cloud. Surging edge data volume will accelerate the challenges caused by a lack of strategy or orchestration.

Gartner’s 6 Edge Computing Challenges

Lack of extensibility

Many purpose-built edge computing solutions can’t adapt as use cases change or expand as the business scales, limiting agility and preventing efficient growth.

Inability to extract value from edge data

Much of the valuable data generated by edge sensors and devices gets left on the table, so to speak, because companies lack the resources needed to run all their data analytics and AI apps at the edge and are stuck simply collecting data rather than being able to do much with it.

Data storage constraints

Edge computing deployments are often smaller and have more data storage constraints than large data centers and cloud deployments, but quickly distinguishing between valuable data and destroyable junk is difficult with edge resources.

Knowledge debt from edge-native apps

Edge-native applications are designed for edge computing architectures from the ground up. Edge containers are similar to cloud-native apps, but clustering and cluster management work much differently, creating what’s known as “knowledge debt” and straining IT teams.

Lack of security controls, policies, & visibility

Edge deployments often lack many of the security features used in data centers, and sometimes other departments install edge computing solutions without onboarding them with IT for the application of security policies and monitoring agents, adding risk and increasing the attack surface.

Inability to remotely orchestrate, monitor, & troubleshoot

When equipment failures, configuration errors, or breaches take down edge networks, remote teams are often cut-off and unable to troubleshoot or recover without traveling on-site or paying for managed services, increasing the duration and cost of the outage. Current edge solutions are novel and don’t connect to or integrate with the full networking stack.
At the Gartner conference, analyst Thomas Bittman gave multiple presentations echoing his advice from the Building an Edge Computing Strategy report published earlier in the year. In preparing for the future of edge computing, Bittman urges companies to proactively develop a comprehensive edge computing strategy encompassing all potential use cases and addressing the challenges described above. His recommendations include:

  • Enabling extensibility by utilizing vendor-neutral platforms that allow for expansion and integration, which supports growth and agility at the edge.
  • Looking for opportunities to deploy artificial intelligence, data analytics, and machine learning alongside edge computing units, for example, with system-on-chip technology or all-in-one edge networking and computing devices.
  • Anticipating data storage and governance challenges at the edge by defining clear policies and deploying AI/ML data management solutions that dynamically determine data value.
  • Reducing knowledge debt by utilizing vendor-neutral platforms that support familiar container and cluster management technologies (like Docker and Kubernetes).
  • Securing the edge with a multi-layered defense, including hardware security, frequent patches, zero-trust policies, strong authentication, network micro-segmentation, and comprehensive security monitoring.
  • Centralizing edge management and orchestration (EMO) with a vendor-neutral platform that unifies control, supports environmental monitoring, and uses out-of-band (OOB) management while interoperating with automated edge management workflows (such as zero-touch provisioning and infrastructure configuration management).

Bittman’s recommended edge computing strategy uses the central EMO as a hub for all the technologies, processes, and workflows involved in operating and supporting the edge. This strategy will prepare companies for the future of edge computing and support efficient, agile growth and innovation.

Enter the future of edge computing with Nodegrid

Nodegrid is a vendor-neutral edge management and orchestration platform from ZPE Systems. Nodegrid easily interoperates with your choice of edge solutions and can directly run third-party AI, ML, data analytics, and data governance applications to help you extract more value from your edge data. The open, Linux-based Nodegrid OS can also host Docker containers and edge-native applications to reduce hardware overhead and knowledge debt.

Nodegrid devices protect your edge management interfaces with hardware security features like TPM and geofencing, support for strong authentication like 2FA, and integrations with leading zero-trust providers like Okta and PING. The Nodegrid OS and ZPE Cloud are Synopsys-validated to address security at every stage of the SDLC. Plus, you can run third-party security solutions for SASE, next-generation firewalls, and more.

Nodegrid edge networking solutions use out-of-band technology to give teams 24/7 remote visibility, management, and troubleshooting access to edge deployments. It freely interoperates with third-party solutions for infrastructure automation, monitoring, and recovery to support network resilience and operational efficiency. Nodegrid is like a cloud-in-a-box solution, incorporating edge computing and the full networking stack. Nodegrid’s edge management and orchestration platform provides single-pane-of-glass visibility, control, and resilience while supporting future edge growth.

Use Nodegrid for your Gartner-approved edge computing strategy

The Nodegrid EMO platform helps you anticipate the future of edge computing with vendor-neutral, single-pane-of-glass visibility and control. Watch a free Nodegrid demo to learn more.

Request a Demo

DORA Act: 5 Takeaways For The Financial Sector

by | Mar 7, 2024 | Data Center Management, Data Center Resilience, Data Logging, Improve Network Security, Increase Productivity, Micro-segmentation, Minimize Impact of Disruptions, Modernize Legacy Environments, Monitoring & Reporting, Network Automation, Remote Network Management, User Management, Zero Touch Provisioning (ZTP), Zero Trust Security

Thumbnail – DORA Act 5 Takeaways for the Financial Sector

The Digital Operational Resilience Act (DORA) is a regulatory initiative within the European Union that aims to enhance the operational resilience of the financial sector. Its main goal is to prevent and mitigate cyber threats and operational disruptions. The DORA Act outlines regulatory requirements for the security of network and information systems “whereby all firms need to make sure they can withstand, respond to and recover from all types of ICT-related disruptions and threats” (DORA Act website).

Who and What Are Covered Under the DORA Act?

The DORA Act is a regulation that covers all financial entities within the European Union (EU). It recognizes the critical role of information and communication technology (ICT) systems in financial services. DORA applies to financial services including payments, securities, credit rating, algorithmic trading, lending, insurance, and back-office operations. It establishes a framework for ICT risk management through technical standards, which are being released in two phases, the first of which was published on January 17, 2024. The DORA Act will go into effect in its entirety on January 17, 2025.

With cyberattacks constantly in the news cycle, it’s no surprise that governing bodies are putting forth standards for operational resilience. But without combing through this lengthy piece of legislation, what should IT teams start thinking about from a practical standpoint? Here are 5 takeaways on what the DORA Act means for the financial sector.

DORA Act: 5 Takeaways for the Financial Sector

1. Shore-up your cybersecurity measures

The DORA Act emphasizes strengthening cybersecurity measures within the financial sector. It requires financial institutions, such as banks, stock exchanges, and financial infrastructure providers, to implement robust cybersecurity controls and protocols. These include adopting advanced authentication mechanisms, encryption standards, and network segmentation to protect sensitive financial data and critical infrastructure from cyber threats. Part of this will also require organizations to apply system patches and updates in a timely manner, which means automated patching will become necessary to every organization’s security posture.

2. Implement resilience systems

Operational resilience is a key focus area of the DORA Act, aiming to ensure the continuity of essential financial services in the face of cyber threats, natural disasters, and other operational disruptions. Financial institutions are required to develop comprehensive business continuity plans, establish redundant systems and backup facilities, and conduct regular stress tests to assess their ability to withstand and recover from various scenarios. Implementing a resilience system helps with this, as it provides all the infrastructure, tools, and services necessary to continue operating during major incidents.

3. Conduct regular scans for vulnerabilities

The DORA Act mandates financial institutions to implement robust risk management practices to identify, assess, and mitigate cyber risks and operational vulnerabilities. This includes conducting regular assessments, vulnerability scans, and penetration tests, and developing incident response procedures to quickly address threats. This is all part of taking a proactive approach to identify and mitigate cyber incidents, and reduce the impact that adverse events have on financial stability and consumer confidence.

4. Collaborate and share information with industry peers

The DORA Act encourages financial institutions to share cybersecurity threat intelligence, incident data, and best practices with industry peers, regulators, and law enforcement agencies. The ability to monitor systems and collect data will be crucial to this approach, and will require systems that can rapidly (and securely) deploy apps/services during ongoing incidents. This will help financial institutions to better understand emerging threats, coordinate responses to cyber incidents, and strengthen collective defenses against threats and operational disruptions.

5. Segment physical and logical systems to pass regular audits

Through the DORA Act, regulators are empowered to conduct regular assessments, audits, and inspections of systems. This will ensure that financial institutions are implementing adequate controls and safeguards to protect against cyber threats and operational disruptions. A crucial part to this will involve physical and logical separation of systems, such as through Isolated Management Infrastructure, as well as implementing zero trust architecture across the organization. These will help bolster resilience by eliminating control dependencies between management and production networks, which will also help to streamline audits.

Get the blueprint to help you comply with the DORA Act

DORA’s requirements are meant to help IT teams better protect sensitive data and the integrity of financial systems as a whole. But without a proper network management infrastructure, their production networks are too sensitive to errors and vulnerable to attacks. ZPE has created the blueprint that covers these 5 crucial takeaways outlined in the DORA Act. The architecture outlined in this blueprint has been trusted by Big Tech for more than a decade, as it allows them to deploy modern cybersecurity measures, physically and logically separated systems, and rapid recovery processes. Download the blueprint now.

Download blueprint

What to do if You’re Ransomware’d: A Healthcare Example

by | Feb 28, 2024 | Data Logging, Improve Network Security, Micro-segmentation, Minimize Impact of Disruptions, Network Automation, Out of Band Management, User Management, Virtualization, Zero Touch Provisioning (ZTP), Zero Trust Security

What to do if youre ransomwared

This article was written by James Cabe, CISSP, a 30-year cybersecurity expert who’s helped major companies including Microsoft and Fortinet.

Ransomware gangs target the innocent and vulnerable. They hit a Chicago hospital in December 2023, a London hospital in October the same year, and schools and hospitals in New Jersey as recently as January 2024. This is one of the biggest reasons I’m committed to stopping these criminals by educating organizations on how to re-think and re-architect their approach to cybersecurity.

In previous articles, I discussed IMI (Isolated Management Infrastructure) and IRE (Isolated Recovery Environments), and how they could have quickly altered outcomes for MGM, Ragnar Locker victims, and organizations affected by the MOVEit vulnerability. Using IMI and IRE, organizations find that the key to not only speedy recovery, but also to limiting the blast radius and attack persistence, is isolation.

Why is isolation (not segmentation) key to ransomware recovery?

The NIST framework for incident response has five steps: Identify, Protect, Detect, Respond, and Recover. It’s missing a crucial step, however: Isolate. Stay tuned for a full breakdown of this in my next article. But the reason this is so critical is because attacks move at machine speed, and are very pervasive and persistent. If your management network is not fully isolated from production assets, the infection spreads to everything. Suddenly, you’re locked out completely and looking at months of tedious recovery. For healthcare providers, this jeopardizes everything from patient care to regulatory compliance.

Isolation is integral to building a resilience system, or in other words, a system that gives you more than basic serial console/out-of-band access and instead provides an entire infrastructure dedicated to keeping you in control of your systems — be it during a ransomware attack, ISP outage, natural disaster, etc. Because this infrastructure is physically and virtually isolated from production (no dependencies on production switches/routers, no open management ports, etc.), it’s nearly impossible for attackers to lock you out.

So, what really should you do if you’re ransomware’d? Let’s walk through an example attack on a healthcare system, and compare the traditional DR (Disaster Recovery) response to the IMI/IRE approach.

Ransomware in Healthcare: Disaster Recovery vs Isolated Recovery

Suppose you’re in charge of a hospital’s network. MDIoT, patient databases, and DICOM storage are the crown jewels of your infrastructure. Suddenly, you discover ransomware has encrypted patient records and is likely spreading quickly to other crown jewel assets. The risks and potential fallout can’t be understated. Millions of people are depending on you to protect their sensitive info, while the hospital is depending on you to help them avoid regulatory/legal penalties and ensure they can continue operating.

The problem with Disaster Recovery

Though the word ‘recovery’ is in the name, the DR approach is limited in its capacity to recover systems during an attack. Disaster Recovery typically employs a couple things:

  • Backups, which are copies of data, configurations, and code that are used to restore a production system when it fails.
  • Redundancy, which involves duplicating critical systems, services, and applications as a failsafe in the event that primaries go down (think cellular failover devices, secondary firewalls, etc.).

What happens when you activate your DR processes? It’s highly likely that you won’t be able to, and that’s because the typical DR setup relies on the production network. There’s no isolation.

Think about it this way: your backup servers need direct access to the data they’re backing up. If your file servers get pwned, your backup servers will, too. If your primary firewall gets hacked, your secondary will, too. The problem with backup and redundancy systems — and any system, for that matter — is that when they depend on the underlying infrastructure to remain operational, they’re just as susceptible to outages and attacks. It’s like having a reserve parachute that depends on the main parachute.

And what about the rest of your systems? You just discovered the attack has encrypted your servers and is quickly bringing operations to a crawl. How are you going to get in and fight back? What if you try to log into your management network, only to find that you’re locked out? All of your tools, configurations, and capabilities have been compromised.

This is why CISA, the FBI, US Navy, and other agencies recommend implementing Isolated Management Infrastructure.

IMI and IRE guarantee you can fight back against ransomware

You discover that the ransomware has spread. Not only has it encrypted data and stopped operations, but it has also locked you out of your own management network and is affecting the software configurations throughout the hospital. This is where IMI (Isolated Management Infrastructure) and IRE (Isolated Recovery Environment) come in.

Because IMI is physically separate from affected systems, it guarantees management access so teams can set up communication and a temporary ‘war room’ for incident response. The IRE can then be created using a combination of cellular, compute, connectivity, and power control (see diagram for design and steps). Docker containers should be used to bring up each step.

Diagram showing a chart containing the systems and open-source tools that can be deployed for an Isolated Recovery Environment

Image: The infrastructure and incident response protocol involved in the Isolated Recovery Environment. These products were chosen from free or open source projects that have proven to be very useful in each of these stages of recovery. These can be automated in pieces for each phase, and then be brought down via Docker container to eliminate the risk of leakage or risk during each phase.

Without diving too far into the technicalities, the IRE enables you to recover survivable data, restore software configurations, and prevent reinfection. Here are some things you can do (and should do) in this scenario, courtesy of the IRE:

Establish your war room

You can’t fight ransomware if you can’t securely communicate with your team. Use the IRE to create offline, break-the-glass accounts that are not attached to email. This allows you to communicate and set up ticketing for forensics purposes.

Isolate affected systems

There’s no use running antivirus if reinfection can occur. Use the IRE to take offline the switch that connects the backup and file servers. Isolate these servers from each other and shut down direct backup ports. Then, you can remote-in (KVM, iKVM, iDRAC) to run antivirus and EDR (Endpoint Detection and Response).

Restore data and device images

The key is to have backup data at its most current, both for patient data and device/software configurations. Because the IRE provides an isolated environment, and you’ve already pulled your backups offline, you can gradually restore data, re-image devices, and restore configurations without risking reinfection. The IRE ensures devices “keep away” from each other until they can be cleansed and recovered.

Things You’ll Need To Build The IMI and IRE

Network Automation Blueprint

We’ve created a comprehensive blueprint that shows how to implement the architecture for IMI and IRE. Don’t let the name fool you. The Network Automation Blueprint covers everything from establishing a dedicated management network, to automating deployment of services for ransomware recovery. Get your PDF copy now at the link below.

Download blueprint

Gen 3 Console Servers To Replace End-of-Life Gear

It’s nearly impossible to build the IMI or deploy the IRE using older console servers. That’s because these only give you basic remote access and a hint of automation capabilities. You’ll still need the ability to run VMs and containers. Gen 3 console servers let you do all of the things for IMI and IRE, like full control plane/data plane separation, hosting apps, and deploying VMs/containers on-demand. They’ve also been validated by Synopsys and have built-in security features I’ve been talking about for years. Check out the link below for resources about Gen 3 and how we’ll help you upgrade.

Upgrade to Gen 3

Get in touch with me!

I’d love to talk with you about IMI, IRE, and resilience systems. These are becoming more crucial to operational resilience and ransomware recovery, and countries are passing new regulations that will require these approaches. Get in touch with me via social media to talk about this!