News

The new CIP-005-7 version has added a new requirement (R3), are you aware of this change? This new standard is coming into effect on October 1 and the controls to achieve the requirement must be in place prior to the effective date. Has your organization found a solution to meet the new requirements?

For those entities that have already had to implement, at some level, the Interactive Remote Access (IRA) requirements applicable to High Impact BCS and their associated PCA and Medium Impact BCS with external routable connectivity, this should not be a foreign concept.

The purpose of this new requirement is to ensure that your Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS) are not vulnerable to some of the threats introduced by having vendors and suppliers manage and/or support your assets remotely.

 What language are you speaking?

Before we dive into describing the controls needed and the opportunities available to solve for meeting these compliance requirements, let’s take a step back and come to terms with some TERMS.

There are many acronyms used within the industry and I don’t want to bore you with hours of acronym definitions. For a better breadth of understanding I highly recommend becoming familiar with the governing bodies formal descriptions found in the  “NERC Glossary of Terms”.

For the purpose of this discussion, I am providing some important terms relative to this specific requirement:

• Bulk Electric System Cyber System (BCS)
  • One or more BES Cyber Assets logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity
• Protected Cyber Asset (PCA)
  • One or more Cyber Assets connected using a routable protocol within or on an Electronic Security Perimeter that is not part of the highest impact BES Cyber System within the same Electronic Security Perimeter. The impact rating of Protected Cyber Assets is equal to the highest rated BES Cyber System in the same ESP
• Electronic Access Control or Monitoring System (EACMS)
  • Cyber Assets that perform electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems. This includes Intermediate Systems
• Physical Access Control System (PACS)
  • Cyber Assets that control, alert, or log access to the Physical Security Perimeter(s), exclusive of locally mounted hardware or devices at the Physical Security Perimeter such as motion sensors, electronic lock control mechanisms, and badge readers.
• External Routable Connectivity (ERC)
  • The ability to access a BES Cyber System from a Cyber Asset that is outside of its associated Electronic Security Perimeter via a bi-directional routable protocol connection
• Intermediate Remote Access (IRA)
  • User-initiated access by a person employing a remote access client or other remote access technology using a routable protocol. Remote access originates from a Cyber Asset that is not an Intermediate System and not located within any of the Responsible Entity’s Electronic Security Perimeter(s) or at a defined Electronic Access Point (EAP). Remote access may be initiated from: 1) Cyber Assets used or owned by the Responsible Entity, 2) Cyber Assets used or owned by employees, and 3) Cyber Assets used or owned by vendors, contractors, or consultants. Interactive remote access does not include system-to-system process communications
• Intermediate System (IS)
  • A Cyber Asset or collection of Cyber Assets performing access control to restrict Interactive Remote Access to only authorized users. The Intermediate System must not be located inside the Electronic Security Perimeter

Now that you have a little background information on the terms we will be referencing, let’s move on to what the requirements are and why they are important for the protection of your BCS.

NERC CIP-005-7 R3- Vendor Remote Access Management for EACMS and PACS:

• (R3.1) Have one or more method(s) to determine authenticated vendorinitiated remote connections.
• (R3.2) Have one or more method(s) to terminate authenticated vendorinitiated remote connections and control the ability to reconnect.

Remote access is a common term initially associated with someone accessing your environment from the internet or outside your organization.  However, remote access is any type of connection or session that allows you to connect to a device from your desktop/laptop without physically connecting to the device. This includes all of your privileged employees’ access to systems they manage.

NERC CIP defines these connections as an “Interactive Remote Access” which typically is performed by a user-initiated activity. There is also a second type known as a “system-to-system” connection. This is just as it sounds; service accounts, script/batch accounts, computer processes. See the forementioned glossary of terms for a better understanding.

Both of these remote access types present a significant amount of risk to the BCS, EACM, and PACS environments.  The risk manifests itself through the different levels of risk mitigation controls through the different functional network’s criticality ratings.

Your BCA’s and PCA’s probably have more cyber security controls deployed around them, known as defense-in-depth architecture, to preserve the operational reliability of that network than the network that is hosting your laptop or desktops.  When a remote connection is established, the less secured remote device now introduces foreign threats to the environment.

Remote access by a vendor further elevates this risk because you are not in control or knowledgeable of how well their security posture is. Just by allowing a remote connection from a vendor your organization has assumed/accepted a certain level of risk.

Some Things to Consider

• How well do you trust the vendor’s cyber security posture at their facility?
• Are you comfortable that the tools they use have been secured appropriately to the level of criticality of your environment?
• Do you trust the actions they are performing within the environment? Can you validate that work?
• How do you know their login ID has not been compromised?

So How Do I keep my critical environment safe as I meet my compliance objectives?

ZERO TRUST: Deny-by-Default

In simple terms: Don’t trust anyone or anything!!! Know what is on the network, authorize only those personnel and assets to perform the business functions needed and deny, remove, or block all other activity.

For those items you have authorized, audit and log all activity to include changes to the environment.  You can read additional coverage on supply chain risk in our blog here.

Control Each Connection

Broker the connected session by establishing a protocol break between the BCS/EACM/PACS and the remote vendor’s Cyber Asset. This allows for the ability to authorize the data flow, monitor the session creation and terminate any connected session on demand.

It also provides the ability to define a baseline policy around connection behavior such that the authorization and access can be alert and ready to remove, if desired, the vendor’s ability to re-establish the connection.

Ensure You Are Auditing and Logging

And as always you must have the ability to capture system events, session events, and user activity events to be correlated.  This provides for the monitoring, alerting, and auditing for potential malicious activity and incident identification.

Isolate Your Supply Chain

One way to make sure you are doing this is by not giving full access to your supply chain. Instead, those vendors who need access to certain information are segmented into their own space, in addition to layering other security measures like privileged access management on top of it. In the event of a breach on their end, you have reduced your risk.

Taking Your Next Steps

The threat of internal and external remote access to OT and IT environments are the core of our focus. Our solution, ConsoleWorks, delivers on this focus.  It provides risk mitigating controls that meet and exceed the NERC CIP compliance requirement(s).

See our three part series on the Zero Trust security architecture to see how ConsoleWorks complements your NERC CIP and Enterprise strategies.

If you would like more details on how ConsoleWorks can help you meet compliance while increasing efficiency and security, we are always available to talk about your particular needs here.

Organizations struggle with password security and getting to the bottom of password management best practices can be tough. There are many systems in a modern organization needing password protection. Each also offers varying levels of password complexity. Organizations can suffer serious fallout from a breach when an account’s password is compromised, therefore the need for a strong password management implementation is high.

That’s why we’re reviewing PWM best practices today, to ensure that you are resolving these security gaps. While we’ve talked about the journey companies take to achieving a fully mature password management implementation, we want to look at what best practices you should be using while going through your implementation.

What Are the Benefits of Password Management

Oftentimes in the OT landscape, for instance, endpoints don’t allow for complex passwords or even various usernames. This results in a lot of sharing of passwords, sometimes even across various devices. While sharing passwords is its own issue, these issues compound when an employee is dismissed, as now you have a serious security vulnerability. How many machines could that person access using the username and password that they know?

Having a system in place to manage your passwords, allowing you to change them quickly,  to checkout passwords as needed, or, in the event of an emergency situation where access to critical infrastructure is needed immediately, to switch them to the same password and then change them back to a unique password after the problem is resolved, provides many benefits to your organization.

Implementing a strong PWM solution and using password management best practices while doing it, will offer you better flexibility and security of your fleet.

Password Management Benefits:

• Protect older devices with limited password complexity
• Quickly change passwords during an emergency and change them back afterward.
• Easily manage security vulnerabilities of known endpoint credentials when an employee is terminated
• Reduce or remove the sharing of credentials within the organization
• Schedule password changes as required by your company or compliance needs.
• Enable password checkouts

With these benefits in mind, let’s review the password management best practices that grant you all the capabilities of a strong implementation.

Password Management Best Practices

Protect Older Devices with a Password Management Solution

OT assets can be difficult to protect. Some of these OT assets do not provide the same level of complexity, from passwords or other security features, that IT teams have access to on their newer devices. In this event, you should require users to access it indirectly. For example, ConsoleWorks can know the endpoint’s true password, while all users connecting to the device must login with their own credentials and passwords to ConsoleWorks, which then brokers that connection. Make sure your PWM solution offers this functionality.

Don’t Reuse or Share the Same Passwords Across Devices

This still happens all too often and is an important password management best practice to make sure you are following. You amplify security challenges by sharing passwords or using the same one. If an employee is terminated, you now have a much more complex security issue. How many logins do they know and to how many devices?

In the event of sharing those logins, it is not as easy as deactivating the terminated employee’s account. In some cases, you may not even know the extent of their access due to the shared knowledge of passwords across devices.

Use Multifactor Authentication

Compromised passwords are among the most common methods of attack. To strengthen your defense against it, you should enforce multifactor authentication methods in order to gain access. At least in the event of a compromised password, there are still more hurdles to overcome to gain entry through that compromised account due to further steps being necessary to verify identity. Your most advanced systems, as we discussed in our maturity model, will use many different contextual points to ensure the user is who they really say they are.

Use a Password Manager

A password manager should be used to protect your most privileged credentials. This, in coordination with other cybersecurity solutions like privileged access management, will secure your critical assets. A good password manager can also automate password functions for you, increasing your productivity in addition to heightening your security.

Best Practices that Keep You Secure

These password management best practices will help you along your way to a strong implementation. If you missed our previous best practices, you can also review our best practices for role-based access, network segmentation and baseline configuration monitoring.

With these best practices in mind, you’re ready to take the next step in your implementation. Should you have any questions, we are always available to talk about your particular needs here.

The TSA released an updated version of its cybersecurity requirements for pipeline owners and operators. The revised TSA pipeline security directive aims to further enhance security and resilience after releasing their first security directive last year in July.

The original TSA pipeline security directive followed in the wake of the Colonial Pipeline attack, which we discussed and also covered methods to remain more secure in this environment of heightened attacks on critical infrastructure. Similarly, the Biden administration released an executive order calling for Zero Trust in response to the increased attacks on critical infrastructure. The reissued directive from the TSA now focuses on performance-based measures to achieve critical cybersecurity outcomes that get you closer to a Zero Trust architecture.

The new directive outlines four approaches: “The reissued security directive takes an innovative, performance-based approach to enhancing security, allowing industry to leverage new technologies and be more adaptive to changing environments. The security directive requires that TSA-specified owners and operators of pipeline and liquefied natural gas facilities take action to prevent disruption and degradation to their infrastructure.”

What are TSA’s Pipeline Security Directive Requirements for Owners and Operators

Below we are reviewing the four approaches outlined in the TSA pipeline security directive and how ConsoleWorks supports its needs for pipeline owners and operators:

• Develop network segmentation policies and controls to ensure that the Operational Technology system can continue to safely operate in the event that an Information Technology system has been compromised and vice versa.

ConsoleWorks monitors all system events from the endpoint to the network equipment used to segment your infrastructure and pulls configurations from each to establish a “known-good” baseline of the configuration.  Once there is a change event, authorized or not, ConsoleWorks can be setup to alarm the asset owner of the change. For example, it will see when firewalls, switches, or other network device settings are changed and deviate from the initial baseline settings.

Should a user change these settings, intentionally or not, ConsoleWorks will tell you exactly by who and when these settings were changed. By validating your configuration baselines ConsoleWorks ensures operational reliability of your network segmentation. It also ensures that your asset inventory doesn’t drift from its established baselines and leave you open to security gaps.

• Create access control measures to secure and prevent unauthorized access to critical cyber systems.

Proper access control measures are a necessary tool to mitigate cyber intrusions. Implementing a least-privilege role-based access control methodology allows an organization to increase its Zero Trust security maturity model.  ConsoleWorks inherently limits the capabilities of an intruder who gains access to a user’s account. As your first line of defense, it defends your systems and prevents unrestricted access through the use of user and device profiles with granular security Access Control Rules (ACR’s).  Its secure remote access ensures only privileged actors have access to your devices.

ConsoleWorks will even allow you to control which commands the user is able to execute by controlling the exact inputs they are allowed to enter. If a user tries to act in a way that is not congruent with their role, ConsoleWorks alerts a supervisor or boots the user off the system. This ensures that an unintended or a malicious command cannot be executed. It even provides user context awareness. Things like location, device, and other attributes, are checked every time a user attempts to enter the network.

And last but not least, with a cybersecurity platform like ConsoleWorks, all user activity is captured for playback and forensic auditing and/or analysis.

• Build continuous monitoring and detection policies and procedures to detect cybersecurity threats and correct anomalies that affect critical cyber system operations.

ConsoleWorks collects and logs all data from your network equipment and your endpoints for correlation and normalization, allowing thresholds and alerts to be setup to ensure that you are notified appropriately when things are out of the normal within your operations.

These two components, of both user and endpoint, give you a full picture, rather than one half. An instrumental challenge with other log aggregation systems and network security auditing software is that  during the course of log analysis those systems use the timestamp from the asset itself.  Multiple, different timestamps through the course of an event makes it complicated to correlate activities and efficiently determine the root cause of the event.

With ConsoleWorks’ complete situational awareness  you get a central pane of glass to better understand what is happening, where and by whom, minimizing the mean time to response to a critical event.

• Reduce the risk of exploitation of unpatched systems through the application of security patches and updates for operating systems, applications, drivers and firmware on critical cyber systems in a timely manner using a risk-based methodology.

ConsoleWorks uses its Baseline Configuration Management to identify system and software versioning.  This can be leveraged to integrate with industry or custom solutions to assist in automating the patch gaps. After the initial collection is sent, it can continually execute the process on a pre-defined schedule, per policy or compliance requirement.

ConsoleWorks Helps You Meet the TSA Pipeline Security Directive Requirements

ConsoleWorks helps enforce your critical security requirements, as outlined here in the TSA pipeline security directive by enforcing least-privileged access, logging, monitoring, and alerting as well as monitoring patch and configuration changes. It’s a cybersecurity operations platform that can help critical infrastructure attain its Zero Trust goals. Should you have any questions about your cybersecurity, the TSA security directive, or around what meeting your security needs looks like, you can always talk to us here.

Segmenting your network adds layers and security zones to it, dividing it into multiple segments acting as their own network. This is a key piece in the Zero Trust architecture, as we covered in our Zero Trust series here. For those looking to introduce a sophisticated network defense and enable Zero Trust, these network segmentation best practices will help you.

What Are the Benefits of Network Segmentation

Before we get into network segmentation best practices, let’s review a few key reasons why you should be segmenting your network in the first place. A primary reason you segment your network is to obstruct lateral movement of a bad actor.

In a traditional “flat” network, if a user gains access, they can quickly move across the network with little challenge. There are few barriers to entry and once they pass those barriers, there is very little stopping them.

By spreading assets into various security zones, each with their own security and redundancies, a user who gains access to the corporate network may find that they are unable to access the endpoints they are looking for to begin with. Each security zone can have its own access rules, boundaries and protections, acting as its own subnetwork. In a Zero Trust environment, this would be reinforced and complemented by other elements of the architecture.

Network Segmentation benefits:

• Additional security layers and redundancies make it harder for a bad actor to access your critical endpoints, even if they can breach one security measure.
• Improved monitoring and threat detection
• Further clarify and enforce your access control policies by enforcing least-privileged access to your most sensitive security zones with a platform like ConsoleWorks
• Enforce a Zero Trust architecture
• Meet contractual and regulatory needs

With these in mind, let’s review the network segmentation best practices that will help you achieve the most out of the benefits you receive from well-implemented network segmentation.

What Are Network Segmentation Best Practices

Learn Your Natural Boundaries First

Learn your natural boundaries first. These boundaries will be dictated by your operational and security needs, and further by regulations or contracts. The needs of your accounting segment will certainly differ from your OT segment requirements, and each will have its own regulations or compliance requirements to fulfill. This will help you to initially map out your segments.

From there you can further microsegment your most critical assets and endpoints, adding additional layers of security and access rules around them to ensure they are well protected.

Don’t Over Segment Your Network

Keeping the first practice in mind, it’s also important not to over segment your network, as this can become a hindrance just to accessing or even knowing what is going on. Your network segmentation must meet your needs, both security and operational, while not impairing you.

Ensure You Are Auditing and Logging

This will take you even closer to realizing your Zero Trust needs. You’ll have greater insights into what is happening on your network and as you have various security zones, you can easily monitor and assess what is happening within each, or even prevent something from spilling over into other zones.

Isolate Your Supply Chain

We’ve talked already about the risks you take on from your supply chain and that you must account for these. One way to make sure you are doing this is by not giving full access to your supply chain. Instead, those vendors who need access to certain information are segmented into their own space, in addition to layering other security measures like privileged access management on top of it. In the event of a breach on their end, you have reduced your risk.

Taking Your Next Steps

Having these network segmentation best practices in mind, you’re ready to complement other parts of your Zero Trust security architecture. You can review what those elements are in our three part series. Should you have any questions, we are always available to talk about your particular needs here.

Least-privileged, role-based access is a critical part in achieving Zero Trust security. Our role based access control best practices highlight what you should do both when implementing it and while you are enforcing it.

If you are still at the beginning of your journey for implementing role-based access control, you will also find our Secure Remote Access Maturity Model helpful, as it explains the maturity levels (0-5) and what a mature implementation looks like. Understanding the maturity model, in addition to today’s role-based access control best practices, will help you have a strong understanding of what makes a good implementation.

What Are the Benefits of Role Based Access Control

In our Zero Trust series, we highlighted why least-privileged access control was one of the key pieces in a Zero Trust implementation. A strong, least-privileged access control policy, focusing on user identity and authentication measures providing just the right level of access and at just the right time, are foundational to a Zero Trust framework and maintaining your security.

Role-based access control benefits:

• Helping you meet compliance and reporting needs
• Improving the security of your network
• Protecting your most important endpoints or information
• Controlling what a user is able to do while connected to your network
• Granting a formalized and faster access policy
• Managing time-based access to the most important parts of your network

With a mature implementation that follows role based access control best practices, you’ll be in an environment of heightened security and awareness. You’ll only be permitting access to users when they need it, for the duration they need it. Those users will only be able to see applications and endpoints residing in your network that are relevant to performing their role.

You’ll also be enforcing strong authentication measures on these users before they are even allowed to access your environment. This combination of authentication and enforcement of your security policies will ensure your endpoints remain safe.

What Are Role Based Access Control Best Practices

Know What Your Roles Are

The most important thing to get right before implementing your role-based access control policies are the actual roles. A common mistake here is thinking that your roles are your job titles. These are not the same thing.

For example, your Systems Administrators may have wholly different scopes between their roles, even though they are sitting right next to each other. In the example of a Windows systems administrator, is it necessary for this user to know about your Cisco routers or about your Linux systems or even make connections to them? Or should this role only know about the things within the scope of Windows? Must your Linux Systems Administrator be aware of your Windows devices?

Determining these roles and what is different about them, beyond just the job title, are key elements to define so you can determine the next role-based access control best practice on our list.

After Defining Your Roles, Determine What That Role is Permitted to Do

Just as important as defining your roles, is defining what that role is allowed to do and access. You’ll need to determine within your organization who will define the access each role is going to have. This most likely entails consulting multiple people.

This is just as critical as getting your roles right. If you permit too much access, you have failed to properly enforce least-privileged access and are leaving room on the table to enable a true Zero Trust implementation that permits just the right level of access at just the right time.

Realize That Some Users May Have Multiple Roles

Another important role-based access control best practice is realizing that some users may have multiple roles. You don’t potentially want them exercising those roles at the same time. A Linux systems admin who has permission to handle Linux boxes at two different plants might need to have two separate roles to access each plant. One for Linux Admin Plant A and for Plant B. This is helping you enforce Zero Trust and also regulatory requirements.

Enforce Your Role Based Access Company Wide

Once you have defined your roles and determined the level of access you are going to permit them, now you must ensure that it is enforced across the company, not just in silos. Without a company-wide implementation, you are leaving yourself vulnerable to exactly what you are trying to protect yourself against, and as we have talked about before, devastating hacks can occur from just one account with uncontrolled access.

Make Sure You Are on the Right Track

Our ConsoleWorks cybersecurity platform helps you control access and more. You can learn more about how ConsoleWorks takes you to the highest levels of least-privileged, role based access control like we outline in our maturity model with our datasheet here.

Having these role-based access control best practices in mind, you’re ready to take the next step in your implementation. Should you have any questions, we are always available to talk about your particular needs here.

Your device baselines are a critical part in your cybersecurity. While many baseline configuration management implementations are done to appease regulatory and compliance requirements, the true benefit is to your security. Our baseline configuration management maturity model reviews the maturity levels (0-3) of a BCM implementation. As you achieve higher levels of BCM maturity, you can see how it is a critical piece for maintaining your cybersecurity.

In addition to our BCM maturity model, we also reviewed the baseline configuration best practices that you should be considering during your implementation, going hand-in-hand with today’s review of BCM maturity levels.

What is a Baseline Configuration Management Maturity Model

A Baseline Configuration Management Maturity Model is a model detailing the design implementation and features of BCM in your environment, ranked from levels 0 – 3. As you ascend in maturity levels, your security is enhanced, and the sophistication of your implementation rises with it.

A mature baseline configuration management implementation enhances your security by raising your awareness of your device baselines. This combats problems related to device drift, intentional or unintentional configuration changes that leave you vulnerable, like a port being opened and more. This monitoring is performed after a user has completed their session to said device.

Achieving the highest level in the baseline configuration management maturity model will take you beyond even the needs required by regulatory or compliance standards. With a truly mature BCM implementation, you will have a core piece of your Zero Trust security architecture implemented and working to ensure you are safe from threats.

Baseline Configuration Management Maturity Model Stages

BCM Maturity Level 0:

At level zero, you are simply installing and configuring your endpoints without verifying or checking later if those devices have changed in any significant way. You are not sure what your devices looked like when they were first installed and cannot discern when they have changed from that baseline in a way that could disrupt operations or leave you vulnerable to security threats.

 

BCM Maturity Level 1:

At level one in the baseline configuration management maturity model, though it is rudimentary, you are starting the process of monitoring your baselines. Here you are recording endpoint baselines manually, and also hand checking device configurations against your baselines manually.

While this gives you insights into your fleet, you have a new challenge: large fleets of devices can take months or even a year to manually check. This is a problem for your security, as well as your compliance and regulatory needs.

If an endpoint configuration has changed in a way that can result in vulnerability or failure, you do not want to wait months or a year to learn this. Even more, because verification is done manually, it is prone to human error.

Configurations may not be properly recorded or verified against their baselines. If something is missed, you’ll need to wait until that device’s baseline is checked again, meaning another long interval that you are at risk.

BCM Maturity Level 2:

Level 2 in the BCM maturity model addresses your manual challenges seen at level 1. You have systems in place to automate your baseline management process. You have eliminated those man hours related to checking your fleet and increased your security. If a device baseline changes now, you will know much sooner.

Here you’re also easily meeting the required intervals dictated by compliance or regulatory needs. What is missing at this level is a proper beyond Zero Trust-level implementation of BCM, which treats even your devices as untrusted.

BCM Maturity Level 3:

At full maturity, you have taken your automation further. Not only are your baselines checked automatically, but they are checked every time a session terminates. Your BCM has become a true part of your cybersecurity mix that keeps you secure by alerting you immediately to baseline changes across your devices.

In a Zero Trust environment, this can be used in conjunction with recording of user sessions to understand exactly what happened and when. If a file or port has changed, you will know now rather than at the determined intervals required by compliance and regulatory needs. From here you can determine your appropriate actions of needing to take the machine out of the network or switching its settings back to its baseline.

Your Path to Achieving BCM Maturity

While we reviewed BCM today, it is important to remember that a fully mature cybersecurity architecture involves many pieces. We recommend visiting our Password Management, Secure Remote Access and Zero Trust maturity models as well, which elucidate the features and design needs to attain higher maturity levels across other areas of your cybersecurity.

Should you need any help or have questions about attaining higher levels of maturity, or want to go beyond Zero Trust security in your environment, you can always reach out and talk to us here.