Develop policies/procedures for conducting software inventory that includes who will manage the process, what tools will be used to aid in the process, and how these tools will be used.

Determine what information requirements exist for inventory.

This minimally include the following;

• •Software name
• •Software version
• •Software developer

Determine if the tool selected meets requirements

There are two main types of software inventory methods

Passive: Inventory data gathered by actively polling devices on the network. Additional data is introduced on the network to gather this data.

Active: Inventory data most commonly collected by a SPAN port. No additional data is introduced on the network to gather this information.

To meet this CIS requirement or Critical Control. Organizations will need to understand the software needed for operations and collect what software is currently being used by manually inventorying software or by using an automated solution, some of the popular solutions listed to the left. From here, deltas can be created between what is needed for operations and what software exists in the environment.

From this baseline, Application Allowlist solutions can be used to prevent any additional software from running other than what is required for operations.

Application Allowlist solutions have a very high RIO and should be high on the list when looking at implementing endpoint protection. Most application allowlist solutions allows the administrator to run the tool in audit mode. Audit mode or learning mode. Before running learning mode on end devices use a tool such as MalwareBytes to ensure no malware is added to the whitelist. After learning mode is complete to establish the list of known good software, put the whitelisting tool in enforce mode to block any added software. Additionally, organizations can enable software downloaded from authorized vendors. This eases the maintenance and number of helpdesk tickets, as it still allows users to install typical software they may need. Granted in a typical ICS environment needing additional client software on a continual basis is seldomly required.

For Additional Guidance:
NIST 800-167 Guide to Application Whitelisting

Develop policies/procedures for conducting software inventory that includes who will manage the process, what tools will be used to aid in the process, and how these tools will be used.

Determine what information requirements exist for inventory.

This minimally include the following;

• •Software name
• •Software version
• •Software developer

Determine if the tool selected meets requirements

There are two main types of software inventory methods

Passive: Inventory data gathered by actively polling devices on the network. Additional data is introduced on the network to gather this data.

Active: Inventory data most commonly collected by a SPAN port. No additional data is introduced on the network to gather this information.

To meet this CIS requirement or Critical Control. Organizations will need to understand the software needed for operations and collect what software is currently being used by manually inventorying software or by using an automated solution, some of the popular solutions listed to the left. From here, deltas can be created between what is needed for operations and what software exists in the environment.

From this baseline, Application Allowlist solutions can be used to prevent any additional software from running other than what is required for operations.

Application Allowlist solutions have a very high RIO and should be high on the list when looking at implementing endpoint protection. Most application allowlist solutions allows the administrator to run the tool in audit mode. Audit mode or learning mode. Before running learning mode on end devices use a tool such as MalwareBytes to ensure no malware is added to the whitelist. After learning mode is complete to establish the list of known good software, put the whitelisting tool in enforce mode to block any added software. Additionally, organizations can enable software downloaded from authorized vendors. This eases the maintenance and number of helpdesk tickets, as it still allows users to install typical software they may need. Granted in a typical ICS environment needing additional client software on a continual basis is seldomly required.

For Additional Guidance:
NIST 800-167 Guide to Application Whitelisting

Organizations typically utilize the following to harden systems:

• •STIGs
• •CIS Benchmarks
• •Vendor Hardening Guides

STIGs and CIS benchmarks serve as guides/checklists for hardening, applicable to Windows and Linux workstations/servers, network appliances, and applications. Hardening guides for PLCs and HMIs can be obtained from the original equipment manufacturer (OEM) under a support contract. It's recommended to start with Category Level 1 (STIG) or Level 1 (CIS Benchmark) when using these guides.

BEFORE YOU BEGIN HARDENING: Take a backup, establish a rollback strategy, and perform an SAT or FAT test to confirm the system works as intended after hardening.

Once a secure configuration is created, many times, this configuration can then be utilized or copied to other systems to achieve widespread hardening. As an example, this can be done on Windows machines using local group policies (Workgroup non-domain environment) or GPOs (domain environment).

Publicly available, the Department of Defense (DoD) hardened GPOs can be downloaded for Windows servers, workstations, common applications, etc.

Also publicly available, the Center for Internet Security's (CIS), CIS-CAT, a configuration and vulnerability assessment solution consisting of two components: CIS-CAT Pro Assessor and CIS-CAT Pro Dashboard. The tool's components report a target system's conformance with the recommended settings in 95+ CIS Benchmarks analyzing and monitoring the security status of information systems and the effectiveness of internal security controls and processes across an organization.

Finally, CIS Build Kits include golden image GPOs for Windows and hardening shell scripts for Linux, making it easy to implement and secure machines using CIS Benchmarks.

DoD STIGs: https://public.cyber.mil/stigs/downloads/

CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks/

Hardening Demystified
Hardening involves reducing a device's attack surface, represented by the sum of all vulnerabilities. It aims to build security in depth, ultimately lowering the attack surface.

Using the block of cheese analogy:

• •The block of cheese is the device.
• Each hole represents a vulnerability.
• •All of the holes or the sum of the vulnerabilities represent the attack surface.

Key steps in plain English include:

• •Disabling unused services/protocols/ports/applications
• •Removing unnecessary software
• •Changing default passwords
• •Using secure protocols
• •Enabling security controls such as antivirus, firewalls, logging, and backups

Low Maturity - What can an organization easily do? Without following extensive STIGs or CIS Benchmarks, organizations can focus on high-impact hardening measures for Windows, Linux, and network appliances.

Windows / Linux / Network Appliances - Demystified For Windows and Linux devices, hardening means some of the following:

• •Removal of default passwords
• •Patch vulnerabilities
• •Remove unused applications
• •Remove unutilized users
• •Have a 'daily driver' lower privilege user for everyday tasks and an admin user for system changes
• •Disable ports/services/protocols not used
• •Enable logging
• •Secure authentication

For Network Appliances, hardening means some of the following:

• •Removal of default passwords
• •Disable ports/services/protocols that aren't used
• •Specific services called out in STIG and CIS benchmarks (HTTP, FTP, SNMP, Call-home, BSD, etc)
• •Use Secure Protocols (SNMPv3, SSH, HTTPS)
• •Enable Logging
• •Encrypt Passwords
• •Not using VLAN 1
• •Network protocols are set up according to best practice
• •Spanning tree, SNMP, Syslog, NTP, VLAN, Management
• •Secure authentication
• •Local, AAA (TACACS+, Radius)

Operational Technology Device Hardening- Demystified OT devices refer to PLCs, HMIs, VFDs, RTUs, etc.

The approach to OT Device hardening is similar to Windows, Linux, and network appliance hardening. Overall, Defense in Depth is built around the OT device, where proper authentication and authorization are configured, unused applications/services/ports/protocols are disabled, and secure protocols are enabled to lower vulnerabilities and reduce the attack surface.

As an example, Rockwell HMI/PLC hardening will be detailed.

Detailed hardening for Overall Rockwell Security / Panel View HMIs can be found below. Panel View is a model of HMI manufactured by Rockwell Automation.

You must have an account to view the documents below. Recommended Security Guidelines from Rockwell Automation Security Best Practices for PanelView Plus 6 & PanelView Plus 7 terminals Some of the information covered in the above documents will be covered below:

Panel View HMIs

• •Disable if not using:
• •SMB
• •FTP
• •UPnP
• •ViewPoint Server
• •VNC Server
• •Web Server
• •Secure:
• •Windows CE Desktop

PLCs

1. 1.Secure PLC Programming
• •Top 20 Secure PLC Coding Practices
• •Top 20 Secure PLC Coding Break-down and Lessons Learned by Sarah Fluchs
2. 2.PLC Security Top 20 List was started by a global community that developed a set of guidelines for leading practices for secure PLC programming. On the website, the PDF is free to download, and videos exist that instruct the viewer on how to implement the individual secure practices.
3. 3.Defense in Depth
• •Ensure the physical key switch is set to run (so the PLC can't be programmed remotely)
• •Build security around the PLC
• •Physical Security
• •USB policies/procedures
• •Best practice network design (segmentation / NIST 800 82)
• •Secure communication/protocols
• •Password Protect PLC
• •Set user permissions inside the control design software (Studio 5000 / Siemens TIA)

For Additional Guidance:

1. 1.NIST 800-128 Guide for Security-Focused Configuration Management of Information Systems
2. 2.NSA Network Infrastructure Security Guide June 2022: https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF

For Additional Guidance:
NIST 800-167 Guide to Application Whitelisting

CIS Critical Control #5 Account Management and CIS Critical Control #6 are sort of combined and originally were planned to be combined by CIS; however, from an audit perspective, they were ultimately separated.

There is a decent amount of bleedover between the two controls, so we won't worry too much about trying to stay 100% authentic to the CIS control. Our main concern is improving security no matter what specifically falls under Control 5 or 6. With that being said if you are, please download and reference the CIS Top 18. These solutions can be broken down into IAM (Identity and Access Management) and PAM (Privilege Access Management).

Identity and access solutions manage who is authorized to access organizational data and resources, whereas privileged access management solutions help organizations provide secure privileged access to data and resources by managing and monitoring privileged access.

Control #5 focuses more on Identity Access Management. Control #6 focuses more on Privileged Access Management. Where CIS Control 5 “Account Management” deals specifically with account management and identity access management, CIS Control 6 focuses on managing what access these accounts have, ensuring users only have access to the data or enterprise assets appropriate for their role.

In terms of meeting this CIS Control, an organization should do the following:

1. 1.Establish an inventory of accounts and disable dormant accounts.
2. 2.Each account should have a unique and complex password with only the privileges needed to perform job duties.
3. 3.In the condition that centralized account management is possible, use a directory or identity service for accounts (e.g., Active Directory).
4. 4.Establish and maintain an inventory of service accounts.

Active Directory

Active Directory is the clear choice to meet the identity access management requirement. An organization can meet all four requirements or “safeguards” listed above using Active Directory.

Local Account Management

If a centralized account management solution such as Active Directory can’t be used, Local Group Policy can be used to meet these requirements, except for requirement 3 (reference CIS Critical Control version 8 document). Make the necessary security settings to one Windows host, export the local policy, and upload it on the other Windows hosts.

Local Security Policy > Security Settings

Overall Account Management Best Practices

1. 1.A “daily driver” lower privilege user account should be used for day-to-day tasks where admin account credentials are prompted when system changes occur.
• •Listed as one of the SL1 requirements from the ISA 62443 4-2 standard
2. 2.Limit who and where administrator accounts exist.
• •Meaning only users that need administrator privileges are granted these permissions.
• •Administrator accounts are only configured on machines they are needed and removed when they are no longer needed.
3. 3.Separate and Secure Credentials.
• •Administrator accounts have additional emphasis.
4. 4.Password Manager.
• •For PLC's and other systems where account management is improbable or not capable.

Active Directory Best Practices

Reference CAT 1 and CAT 2 findings from the Active Directory STIGs

1. 1.Membership to the Enterprise Admins group must be restricted to accounts used only to manage the Active Directory Forest.
2. 2.Membership to the Domain Admins group must be restricted to accounts used only to manage the Active Directory domain and domain controllers.
3. 3.Delegation of privileged accounts must be prohibited.
4. 4.Local administrator accounts on domain systems must not share the same password.
5. 5.Domain controllers must be blocked from Internet access.
6. 6.Usage of administrative accounts must be monitored for suspicious and anomalous activity.

Shared Active Directory between IT/OT?

There's a common question that gets circled around the OT space, which is do we have IT/OT under the same domain? Or do we have a separate domain for IT and a separate domain for OT. Most often, we'll recommend entirely separate. The reason is if an attacker gets access to the IT network the AD is a primary target. If it's targeted successfully and compromised, you will likely lose control of your IT environment and your OT environment. The risk is often too significant compared to the additional lift to simply manage two domains. Just manage two domains. Operational Technology - PLC/HMI Account Management You can configure both Rockwell FactoryTalk

Security and Siemens TIA Portal for account management.

1. 1.Local user accounts/groups/permissions
2. 2.Windows-linked user accounts/groups through Active Directory

Setting PLC Password. You can confirm a password for either Write or Write/Read protection within TIA Portal here.

For Additional Guidance:

• •Rockwell FactoryTalk Security
• •Siemens TIA Portal
• •NIST Digital Identity Guidelines
• •Top 16 Active Directory Vulnerabilities

Where CIS Control 5 “Account Management” deals specifically with account management and identity access management, CIS Control 6 focuses on managing what access these accounts have, ensuring users only have access to the data or enterprise assets appropriate for their role.

There should be a process where privileges are granted and revoked for user accounts.

Role-based access conceptuality is based on: need to know, least privilege, privacy requirements, and/or separation of duties. These solutions can be broken down into IAM (Identity and Access Management) and PAM (Privilege Access Management).

Identity and access solutions manage who is authorized to access organizational data and resources where privileged access management solutions help organizations provide secure privileged access to data and resources by managing and monitoring privileged access.

In terms of meeting this CIS Control, an organization should do the following:

1. 1. Establish an Access Granting and Revoking Process.
2. 2. Centralize Access Control through an SSO/MFA provider.
3. 3. Require MFA for External, Network, and Admin access minimally.
4. 4. Maintain Role-Based Access Control.

IAM:

To meet IAM, tools such as SSO / MFA are used in conjunction with Active Directory.

MFA Best Practices

1. 1. Implement for all users, including contractors and remote users.
2. 2. Use strong authentication methods such as mobile app auth instead of SMS.
3. 3. Secure MFA configuration. Limit who can configure MFA to prevent unauthorized changes.

PAM:

Role-based privileged access

Typically used for mature organizations. These will be a hacker for attackers since these solutions provide privileged access to organizational systems and data. There is typically a far greater reduction of risk when implementing AD best practices and MFA across the organization.

Chasing vulnerabilities in OT is a cat chasing its tail. Much like a cat's tail, vulnerabilities in OT systems endlessly appear and disappear, making it a perpetual pursuit. Patching the vulnerabilities is oftentimes very hard as it needs to be done during site downtime and/or sometimes voids vendor warranties or support contracts because it could compromise the system's availability. This counterproductive outcome stands in direct contrast to the overarching goal of safeguarding the system against potential hackers and ensuring its continued availability.

Instead of chasing CVEs, organizations should start by identifying real OT cyber risk by following cyber risk processes such as the ISA 62443 3-2 standard or the INLs CCE process. Some questions organizations should ask before bothering with a CVE-based vulnerability management solution:

• •Are your safety systems connected to the process DCS?
• •Is remote access controlled?
• •Is there a CSMS or cyber program in place to manage the OT environment?
• •Has basic hardening been implemented?
• •Has an architecture review been conducted that includes a 3rd party review of the firewall rules?
• •Is my IT/OT segmented with a DMZ for systems that need to talk between these zones?
• •Etc…

Addressing the above is addressing real OT cyber vulnerabilities. Chasing CVE's is oftentimes a lost cause and for small to medium organizations, a waste of time and resources.

For more mature organizations, vulnerability management solutions have their place.

Develop vulnerability management policies/procedures that include some of the following:

1. 1. What solution will be used to conduct vulnerability scanning
2. 2. What systems/applications will be scanned
3. 3. How often will the scanning occur
4. 4. Who will do the scanning
5. 5. Can the scanning be automated
6. 6. Do regulations applicable to the organization require vulnerability scanning
7. 7. Upon analyzing the results how do we organize, prioritize, and remediate detected vulnerabilities

So what does Vulnerability Management look like?

1. 1. Start with knowing your assets / resources. Typically a monthly scan makes sense.
2. 2. Start addressing the top risk assets. This isn't necessarily aligned to which asset has the highest CVSS score, but what assets present the most risk to the organization. Furthermore, even once you narrow these assets down, still don't just look at the CVSS score. Determine which exploits or CVEs are actually "weaponized" or exploitable. You can use something like CISA's known vulnerability list. Tools like Qualys provide this as a widget.
3. 3. Discuss with the asset owner on what vulnerabilities can be mitigated.
4. 4. Something either gets done or it doesn't. Negotiate and plan to mitigate over a maintenance period.
5. 5. Repeat

External Attack Surface Management (EASM) vs Vulnerability Scanning

Vulnerability Scanner: Find vulnerabilities based on a set of IP addresses that the user provides.

External Attack Surface Management (EASM): Discover and analyze internet-facing IT assets and risks without needing much input or values. EASM solutions incorporate features such as dark web password leaks, an inventory of internet-facing devices, or other exposed sensitive data.

A EASM tool is a great addition to vulnerability management as these tools discover external attack surfaces. All potential digital doorways into an enterprise, which includes, third-party suppliers, partners, cloud services, work from home setups, and more.

Vulnerability Prioritization Technology

To caveat, VPT solutions should not be used until the basic vulnerability management processes are in place. VPT solutions are typically leveraged by organizations that are higher in vulnerability management maturity. Furthermore, these platforms are still largely immature and are 2-5 years away from mainstream adoption.

All the network monitoring and defense tools mentioned in the Network Defense and Asset Inventory CIS controls will prioritize vulnerabilities primarily on CVSS scoring. The problem with CVSS scoring is that it still lacks context. It doesn't rank risk; it ranks severity. CVSS version 3 worked to add context into the scoring from version 2; however, risk scoring is still missing.

1. 1. The importance of the asset the organization is trying to protect
2. 2. Does the asset hold any sensitive information
3. 3. Is this a vulnerability or real risk? How is this risk weighed
4. 4. Are these exploits weaponized and actively used to target

Selection Guidance

• •Implement a risk-based approach that correlates asset value to calculate a risk rating leveraging VPT solutions. This reduces the risk of being breached when prioritizing remediation activities.
• •Augment VA tools with stand-alone VPT solutions for better prioritization or use existing VPT capabilities that assist with the effective methodology for real risk reduction. This enables vendor consolidation and places less effort on new training and tool deployment.
• •Identify vendors with patching capabilities and SOAR integrations. This puts the security team in control of workflows. Evaluate if this approach is appropriate. If so, leverage remediation workflow automation and avoid using two different tools.
• •Deploy VPT solutions that use the context of internal security controls to maximize existing security investments. This capability is immature across the market.
• •Choose VPT solutions that aggregate vulnerability data from multiple sources to present action-oriented metrics.

For Additional Guidance:

NIST 800-40v2 “Creating a Patch and Vulnerability Management Program.”

Develop logging requirements, policies, and procedures.

1. 1. What systems are capable of logging and how is this configured
2. 2. Where will the syslog/SIEM server sit in the environment
3. 3. Who or how do we review the logs
4. 4. How long will we retain audit logs
5. 5. Are there regulations that require a certain retaining period

Systems and Log Types

• •Windows: Event Logs, SNMP
• •Linux: Syslog, SNMP
• •Network Appliances: Syslog, Netflow, SNMP
• •ICS Systems: Syslog, SNMP

Windows Event Log Event ID Mapping to MITRE ATT&CK Framework

Windows Event Log ATT&CK Framework Mapping

Network Appliances Cisco Logging Starting Point

Cisco Logging Best Practices

Logs should be sent from all capable devices to a centralized Syslog server / SIEM. This includes Windows, Linux, network appliances, HMIs, and PLCs. The SIEM should be able to easily display the logs and alerts generated in a customizable UI (user interface). The ability to send alert notifications and generate reports should exist. Logs should be periodically reviewed, if not monitored 24/7 by the organization or 3rd party SOC depending on requirements, budget, and risk.

In summary:

You want to send logs from every machine that has the capability over to a SIEM. You want these logs to be reviewed by someone who is trained and knows what to look for.

Logging serves two purposes:

1. 1. Helps after an attack
• •If you have central logging, but no one looks at the logs at least you still have logs that can help paint a picture or speed up the incident response process.
2. 2. Helps to prevent an attack
• •If you have someone reviewing the logs that is trained, they may be able to spot an attack before it wreaks havoc in your environment.

For Additional Guidance:

NIST 800-92 “Guide to Computer Security Log Management.”

Email and Web security are typically things that OT don't have to focus on, however, it is a critical control, so we'll cover it.

Firstly, if your OT environment doesn't need email or web (they often don't), verify that no email or web traffic traverses your OT environment. You can verify this by running a packet capture at various places in your network. You can also verify this if you're logging at the network gateway level, which is typically done by a firewall. Second, remove any email or web applications that would be used to interface with these protocols. If you're not using the protocols, remove the applications that interact with them. This reduces your attack surface.

Some Overall Best Practices without Procuring any Tooling:

1. 1. Allow-listing only fully supported browsers and email clients
• •Most often Chrome or Edge
2. 2. Keep the browsers and email clients up-to-date
3. 3. Restrict Unnecessary or unauthorized browser and email client extensions
• •This can be pushed in GPO's (Group Policy Objects) by Active Directory.
4. 4. Ensure cybersecurity training covers email/web best practices and acceptable use

After policies and procedures are created look to implement an Email and Web security tool.

Email Protection:

Most of these solutions do the same thing and have very similar performance. Select the tool that is easiest to manage and integrates well with your other tooling.

Above is Cisco's ESA (Email Security Appliance). The graphic shows how the incoming mail policy provides the inbound security controls for incoming email processing. You can see the different layers of security control before the email is ultimately received.

Anti-Spoofing

3 Main Types of Email Spoofing:

1. 1. Envelope From Spoofing
2. 2. Header From Spoofing
3. 3. Display Name Spoofing

3 Main Email Spoofing Solutions:

1. 1. Sender Policy Framework (SPF) - RFC 7208
2. 2. DomainKeys Identified Mail (DKIM) - RFC 6376
3. 3. Domain Message Authentication Reporting & Conformance (DMARC) - RFC 7489

Email Spoofing Mitigation

1. 1. Envelope from spoofing: SPF
2. 2. Header from spoofing: SPF + DMARC + DKIN
3. 3. Display name spoofing: Advanced threat filter, transport rules, and user training
4. 4. Compromised mailboxes or “legitimate” senders: Advanced threat filters, transport rules, and user training

Web:

Refer to some of the best practices listed at the beginning of this section. A web security appliance such as the ones listed might be overkill for many organizations.

Other than what’s listed previously, consider an ad blocker such as Ublock Origin. This can be implemented through GPOs and limit the adware.

Data recovery has become a paramount concern for organizations. While the focus used to be primarily on preventing cyberattacks, there has been a recent shift in mindset. This shift is driven by the escalating frequency of attacks, particularly in critical infrastructure sectors that have historically lagged behind in robust cybersecurity measures. Now, organizations are advised to allocate significant attention to developing strategies for mitigating and remediating the consequences of cyber breaches. The emphasis is on being prepared for the eventuality of a successful hack.

Key to the mitigation and remediation strategy revolves around data recovery.

Consider the 3-2-1 Methodology:

• •Three: Keep three copies of data, the original data copy, and at least two backups
• •Two: Use two different storage types. For instance, if data is stored on an internal hard drive, use a secondary device such as an external drive or cloud source
• •One: Keep one copy of data offsite

Organizations should develop a data recovery process that covers the following:

1. 1. What systems/applications should be backed up (risk prioritize assets)
2. 2. Where will these backups be stored (if stored online or on the network, the storage should be properly segmented)
3. 3. How often will the backups occur
4. 4. Will we automate the backups
5. 5. How long will we keep the backups based upon regulation or storage capacity
6. 6. Who has access to the backups
7. 7. What backups will we encrypt
8. 8. In the event of a cyber attack, is operations aware of how to recover from the backups

Ensure you are not just backing up your Windows operator stations, engineer stations, or data historians, but also your network equipment, project files, and other ICS configurations. Project Files - PLCs/HMIs:

• •Low Maturity or small environment: Run a backup and store this logically (NAS, SharePoint, Fileserver) and physically (hard drive in fireproof safe as an example). Update backups minimally every time configuration changes occur. Put a date in the folder/file name to at least tell you when the configuration was taken.
• •For Higher Maturity or large environments with multiple engineers making configuration changes: Tools such as Version Dog or Copia can be used to pull configurations and for configuration change management. With Copia, DeviceLink used to pull configurations into its dashboard using an agent installed onto a PC at the site. Copia is Git-based version control. Under the dashboard, users can review the code and work together to make changes and keep track of versions.

Network Infrastructure management in the scope of CIS covers a lot. Within this critical control, safeguards are mentioned for building a secure architecture, ensuring network appliances are up-to-date, and implementing network hardening, including secure authentication to appliances.

Outside of the network management software, many of the CIS “Safeguards” listed to meet this control are procedures and tasks the asset owner needs to perform to ensure the proper and secure management of their infrastructure. So, in tooling, I'll recommend some NMS tools and provide guidance here, but other than those tools, other Safeguards mentioned such as maintaining network diagrams, ensuring infrastructure is up to date, securing managing network infrastructure isn't simply a tool, but more administrator tasks that need to be continuously performed.

Unlike IT, where defense in depth travels all the way to the end device, in OT, many end devices either aren't capable or aren't able to have the same security controls due to operational constraints. This means the network architecture, security, segmentation, least privilege, and availability, at minimum is paramount to providing comprehensive security posture.

Richard Bejtlich, strategist at Corelight, former senior director at Splunk, and former Chief Security Strategist at FireEye introduced the term defensible network architecture over 10 years ago.

The principals are the following:

1. 1. Monitored
2. 2. Inventoried
3. 3. Controlled
4. 4. Claimed
5. 5. Minimized
6. 6. Assessed
7. 7. Current

You can read more about these here.

Secure Network Architecture Design

Cisco has a repository of reference architecture of the OT space. https://www.cisco.com/c/en/us/solutions/design-zone/industries/manufacturing.html

When building a secure architecture, critical infrastructure organizations should reference the following documents.

1. 1. NIST 800-82 version 2
2. 2. On page 5-8 through 5-12 you’ll see the 4 architectures mentioned, with 5-12 being the most mature.
• •Compare and contrast your organization's architecture to these 4 architectures to get a baseline of where you're at and see where improvements can be made. They also have listed great best practices that include technical and procedural controls aligned to these architectures.
• •Like-devices or devices with similar security requirements should have their own VLAN. Those VLANS should then have a gateway on the firewall so that if those VLANs need to reach out to another network or talk to another VLAN, they are forced to talk through the firewall where rules should be present that enforce that communication.

Network STIGs

Look at network STIGs. 30% of the findings have to do with network design. Something that is HARD to tack on after the fact. Designing security and reliability into networks before they are built and commissioned is so crucial. This is partially why the term "security needs to be design from the start" exists. It is much harder to bolt on security. Easier to design it secure from the start.

Other common controls listed in network STIGs revolve around other common hardening practices such as using secure protocols, removal of services that aren’t used, backups, VLAN best practices, and access control such as secure authentication. This is covered in more depth in the "Secure Configuration of Enterprise Assets and Software" CIS Control.

Purdue Model

Take your current OT network architecture and align it to the Purdue model. This will standardize your architecture, make it much easier to digest when looking at IT/OT segmentation, entry points, access control, etc.

Network Hardening

Quick and Dirty network hardening guide from the NSA

1. 1. Search “Network Infrastructure Security Guide June 2022”
• •This pretty solid quick and dirty “Here’s how to secure networks” technical whitepaper.

Holistic approach

1. 1. CIS benchmark
2. 2. DoD STIG

Network Management Software

Network Management Software has the following functions.

• •Network Discovery
• •Real-Time Monitoring
• •Network Reporting and Dashboard
• •Network Performance
• •Configuration Management
• •Network Automation
• •Alerts, Reports, and Notifications

These solutions use a combination of protocols to meet these features. SNMP, Netflow, SOAP, WMI, etc. Sadly, there isn't one product that does all of these features listed. Standard NMS solutions usually meet all features except network configuration management and automation. You'll have to procure a different tool to meet these if that's a requirement. LibreNMS is a popular free choice, while PRTG in combination with Cacti is a popular paid approach.

When it comes to configuration management and automation Nikmo, Ansible, and Unimus are popular solutions.

When it comes to secure authentication to network appliances the AAA (authentication, authorization, accounting) model is used Radius or TACACS+

AAA is used for wireless authentication and authorization of users connecting to Wi-Fi, remote access, and network device authentication.

With AAA, you can centrally configure and manage user accounts from a single authentication server. This allows users to log into multiple switches, routers, or firewalls without the need to set up and manage their accounts separately on each network appliance. In essence, it streamlines user management by providing a centralized point of control, making it more efficient and less cumbersome to handle user access across multiple devices.

Radius and TACACS+ are the primary protocols used. Very simply, Radius is controlled access into the network. TACACS+ is controlled access to a network device. Radius is an open-source protocol, while TACACS+ is a Cisco proprietary protocol, although now many other devices support TACACS+. Radius encrypts just the password (unless you're using RadSec), while TACACS+ encrypts the whole packet. Finally, when you configure TACACS+ you can configure user authorization, what permissions they have and accounting what logging with be configured. Using Radius, you must configure authorization on the end device rather than assign the permissions per user. So, while Radius has more use cases and is vendor agnostic, there are two weaknesses. Per user authorization is not built in, and lack of logging per user. The good thing is these can be mitigated. Using Cisco as an example, we can configure syslog to log commands that users run using log config and then thePer-user logging enable command. Additionally, we can use the privilege command we can limit what users do on the network compliance.

More information about setting permissions and accounting with radius can be found here.

Network diagrams should be continuously maintained and securely stored by encrypting the files and/or limited where they are stored. Hackers look for these documents during attacks to greatly increase their knowledge of the environment and how systems are connected.

Personnel Cybersecurity Training

Personnel cybersecurity training isn't just phishing training. Building a comprehensive security awareness program includes minimally the following:

• •Personnel are trained to recognize social engineering attacks
• •On data handling best practices
• •On authentication best practices
• •On causes of unintentional data exposure
• •On recognizing and reporting security incidents
• •Identify and report if their enterprise assets are missing security updates
• •Dangers of connecting to and transmitting enterprise data over insecure networks
• •USB best practices
• •Constantly and are tested on their knowledge of cybersecurity concepts

Phishing:

Phishing training is pretty straight forward. Through one of the solution providers, quiz and test your users to ensure they are continuously training to spot phishing attempts.

• •Phishing training needs to not only include video based training, but also quizzes and simulation-based testing, sending test phishing emails to employees.
• •Phishing testing on employees should occur monthly.
• •Consider consequences for those that continually fail.

General and Role-Based Training:

General and role-based training should go hand in hand with cyber roles and responsibilities and align with other policies and procedures, such as incident response plans. Every personnel member should minimally contribute to preventing cyberattacks through the use of email, web, USB, and job-specific cyber best practices. However, employees also need to be proactive and able to understand how to spot a cyberattack when they encounter one, knowing how to escalate quickly and effectively.

Training your Cyber team:

Often missed throughout the “cybersecurity lifecycle” is training your cybersecurity team. While they may be experts in certain niches of IT or cyber you must make sure they’re trained in the tool they’re using on a day to day or new tools around the corner. Misconfiguration and mismanagement of systems is one of the biggest causes of hacks. Not a zero-day or Stuxnet scenario but simply a misconfigured firewall. Or a legacy VPN account. This everyday gap in responsibility, training, or procedures causes most of the hacks today. Pay extra attention to this.

One method is to create a RACI matrix for your team. This breaks down who is responsible, accountable, consulted, and informed about various cybersecurity functions whether that is vulnerability scanning, updating x policy, etc.

For Additional Guidance:

NIST 800-50 Building an Information Technology Security Awareness and Training Program

3rd party management is essential and often overlooked even in larger organizations. Ever increasingly 3rd party breaches are significantly impacting organizations.

3rd Party Management Policy Establish and Maintain a Service Provider Management Policy that includes:

1. 1. Identification of 3rd parties
2. 2. Data classification and volume
3. 3. Availability requirements
4. 4. Cybersecurity requirements
5. 5. Applicable regulations
6. 6. Inherent risk vs mitigated risk

3rd Party Management

1. 1. First, as always, risk assess any 3rd party access to identify if it's needed. Can you reduce the risk all together by getting rid of the access? Is it critical or needed? I.E. can the vendor come on-site instead?
2. 2. Draft your policies/standards for 3rd party access/management
3. 3. Create a list of questions for your vendors based on that.
4. 4. Include additional assurance controls such as background checks, SOC 2, ISA27001.
5. 5. Have a side channel with legal for reviewing security terms in contracts.

Organizations should identify which 3rd parties have connections to it. The purpose of the connection should be understood to determine if the connection could be eliminated all together or limited. Requirements around the connection should be established to meet regulation and limit risk. Finally, a risk assessment should be conducted to further identify security gaps and mitigations to reduce the risk.

To continue, when you're planning to use or work with a 3rd party outside of SOC 2 of other compliance-based analysis, organizations need to have their list of cyber requirements. This could be in the form of a questionnaire. Three rules when building this out. 1) Don't ask questions that are so fundamental; if they didn't have it, they wouldn't be in business. I.E 3rd party organization must have a firewall. 2) Don't ask questions that are already in the contract 3) Don't ask questions they're likely not to answer truthfully anyway. I.E. do you 3rd party have current & up-to-date data flows? Almost nobody does.

Secure Standards When Procuring Equipment or Considering Integration

You can use the following standards when procuring equipment to ensure that the vendor meets certain development and organizational cybersecurity standards. Of course, this isn't foolproof, but it's all about doing due diligence.

• •ISASecure
• •DODin
• •Common Criteria

Additionally, you should ask the vendor you’re buying ICS/IT equipment/software from or considering 3rd party management/integration to map their requirements to 800-53 or ask if they have a SOC 2 or ISO 27001 compliance report. This allows you to understand better the cyber capabilities of the system, software, and company you're purchasing from.

Additional Guidance:

NIST 800-53 (SCRM requirements) CISA Risk Considerations for Managed Service Provider Customers

For most critical infrastructure organizations (asset owners) reference Development Group 1.

The first step in developing an application security program is implementing a vulnerability management process. This process must integrate into the development life cycle and should be lightweight to insert into the standard bug-fixing progress. The process should include root cause analysis to fix underlying flaws so as to reduce future vulnerabilities, and a severity rating to prioritize remediation efforts.

SAFECode developed a three-tiered approach to help organizations identify which Development Group (DG) they fit in as a maturity scale for development programs. The three CIS IG levels used within the Safeguards inspired their approach for the DGs below:

Development Group 1 (Most Organizations)

Description: An organization that relies on off-the-shelf or open-source software. Very little to no additional coding done by the organization.

Security Focus: Applying basic operational and procedural best practices and managing the security of its vendor-supplied software. Follow overall security best practices mentioned in this website as well vendor application hardening guides.

1. 1. Create and Manage a Vulnerability Response Process
2. 2. Perform Root Cause Analysis
• •Rather than just fixing the reporting vulnerability, understand the nature of the defect. Is this something that is occurring repeatedly? Do we need new tools, training, or to update policies/procedures?
3. 3. Secure Third-Party Code
• •Select vendor software that aligns to best practice security practices.
• •Understand what third-party software is in your environment
• •Ask the vendor how they align to security requirements / standards
• •NIST 800-53, SOC 2, HIPPA, Common Criteria, ISASecure, and DODIN.
• •Understand the current CVE’s associated with that software. https://nvd.nist.gov/
• •Harden the third-party software using vendor hardening guides and following overall cybersecurity best practices.
4. 4. Have a Rating System
• •To prioritize vulnerabilities

Development Group 2

Description: The organization relies on some custom (in-house or contractor-developed) web and/or native code applications integrated with third-party components and runs on-premises or in the cloud.

Security Focus: Addressing common vulnerabilities, motivating the organization, training developers, using secure design, utilizing platform security features, and minimizing attack surface.

1. 1) Do the Easy Stuff
• •Address the most common vulnerabilities that incur the most risk.
• •OSWASP Top 10 and CWE Top 25 Most Dangerous Software Weaknesses
2. 2) Motivate the Organization
3. 3) Train the Developers
• •Security Engineering Training by SAFECode
• •Open Source Security Foundation (OpenSSF)
4. 4) Use a Secure Design
• •Principals of Secure Design
5. 5) Use Platform Security Features
• •Encryption
• •Identification, authentication, authorization
• •Auditing and Logging
6. 6) Minimize Attack Surface

Development Group 3

Description: The organization makes a major investment in custom software that it requires to run its business and serve its customers.

Security Focus: Avoiding code vulnerabilities, conducting threat modeling, and using various application security tools.

1. 1) Avoid Code Vulnerabilities
• •Root cause analysis
• •Integrate security into development
• •Select tools and enable tests cautiously
• •Run code analysis tools
• •Run dynamic testing tools
• •Use code-level penetration testing
• •Have a bug bounty program
2. 2) Threat Model
• •SAFECode's paper Tactical Threat Modeling

Application Security Tools

SCA (Software Composition Analysis)

When to use: Throughout the SDLC, especially during the dependency analysis phase. To identify known vulnerabilities in third-party libraries and open-source components.

Focuses on identifying, managing, and securing open-source and third-party components used in software applications. It plays a crucial role in assessing and mitigating security risks associated with the use of external libraries and components.

SAST (Static Application Security Testing)

When to use: During the development phase or early in the Software Development Life Cycle (SDLC). To find vulnerabilities in the source code before the application is compiled or run.

Conducted at the development stage and involves a tester who is fully knowledgeable about the program under test. At predetermined intervals, testers can examine their code to make sure security flaws are introduced early in the development process. Stated differently, this type of testing allows testers to identify and report vulnerabilities that may result in security problems.

DAST (Dynamic Application Security Testing)

When to use: After the tool is deployed to a testing or production environment. To identify vulnerabilities that can be exploited in a live environment.

DAST testing, which is carried out when the code is running, is akin to black-hat or black-box testing in which the tester is blind to the system. Through the detection of problems with scripting, sessions, interfaces, answers, and complicated patterns, it aids in simulating assaults on production systems.

IAST (Interactive Application Security Testing)

When to use: During the development and testing phases. To provide real-time feedback to developers about security issues.

This incorporates aspects of both dynamic and static testing. While the program is being run for dynamic testing, the IAST tools operate inside it to test security vulnerabilities, providing extra coverage and higher-quality test outcomes.

For Additional Guidance:

• •NIST 800-218: Secure Software Development Framework
• •SAFECode Application Security Addendum-SAFECode
• •The Software Alliance- The Software Alliance
• •OWASP®-OWASP®
• •OWASP Top Ten - OWASP Top Ten
• •CWE Top 25 Most Dangerous Software Weaknesses - CWE Top 25
• •Application Security Tool Map - AppSecMap

Penetration Testing is different from every other cyber assessment in the fact that the security controls of an organization are real-world tested. During the assessment, the hired or in house hackers will actively try to exploit weaknesses in the environment. It is a mature assessment that can grant real-world findings and uncover results beyond the scope of a typical risk, vulnerability, or compliance assessment.

While these assessments are typically carried out by professional cyber contractors, bigger organizations may have in-house internal penetration testers.

There are two core types of penetration testing assessment types.

Black Box: Mimics the perspective of an external attacker with no prior knowledge of the target system. The tester has no access to the internal architecture, source code, or infrastructure details.

White Box: Involves comprehensive knowledge of the internal workings of the system or application being tested. The tester has access to detailed information about the target, including source code, architecture, and infrastructure.

Conducting Penetration Testing in OT

Ensure that whether the penetration is done in-house or by external consultants, they have previous experience with critical infrastructure environments. Unlike IT, Critical infrastructure environments present the severe risk of health, safety, and environmental consequences.

OT organizations should consider black box tests on the external or IT zones. However, down in the Purdue Model Level 3.5 DMZ or OT zones, white box tests should really be the only types of attacks used, given the overwhelming risk to trip a system that can cause health, safety, or environment consequences. If possible, try and schedule penetration tests during operational downtime. Now this can be hard, given that a penetration testing project can last weeks, but try to time the active exploitation phase around these periods.

Also, there is a belief that penetration tests are farther in the OT/ICS security journey. However, I would argue that it should be far earlier. You see, the belief is that organizations should go through the Awareness, Program Development, Oh Wow Moment, Execution, Integration, and Optimization phases of their cybersecurity program and, towards the end, use penetration tests to validate their controls. What if organizations used penetration tests to drive the baseline of controls? To identify what is actually at risk, using these simulated attacks. That’s what I would argue. Not that penetration tests and the results that come out of the assessment should be the sole drivers for what cybersecurity controls to implement. However, don’t wait till the end. And continually do them throughout your security lifecycle.

Lastly, consider non-intrusive white box simulated attacks where the person carrying out the penetration has deep knowledge about the organization (to know what to stay away from) goes through the recondense phase, identifies initial access points, pivots to multiple parts of the network, finds vulnerabilities and matching exploits, but doesn't actually execute. Is, instead, at this step, aided by the organization to get access to that machine and then use non-intrusive living off the land techniques to see what else he/she can accomplish and so on and so forth. Sort of a hand-held white box penetration test.

To meet the intent of the CIS Critical Control:

1. 1. Organizations depending on requirements should look to have yearly penetration testing assessment completed
2. 2. Remediate the findings prioritizing the highest risk first
3. 3. Validate security measures after each penetration test
4. 4. Create a penetration testing program that includes policies/procedures to ensure this process is owned by someone internally; expectations, requirements, and previous results are documented

Tools to Perform Penetration Testing

Kali Linux is the primary operating system used to perform penetration tests. Within Kali Linux are a slew of pre-installed tools pertaining specifically to penetration testing. Of course, other external tools outside of Kali Linux exist to conduct penetration testing.

Penetration testing is not something a low to mid-level IT professional picks up and tries against a live environment. Unless an organization plans to hire a dedicated internal penetration tester, it is almost always advised to hire a penetration testing consulting firm.

Automated Penetration Testing Platforms

While still immature from a technology and development perspective, automated penetration testing tools are coming to market that in the next 5-10 years could bridge the gap on manual penetration testing.

Meaning, while it’s unlikely automated penetration testing platforms such as BASs will replace manual penetration testing done by humans. Breach and Attack simulation tools could be a cheaper alternative for smaller organizations, and allow organizations to test more frequently.

In the best-case scenario, both would work in harmony. Where penetration testing answers the question “can they get in?” Breach and attack simulation (BAS) tools help you to answer the question “do my security tools work?”

Incident Response Management

Today organizations can't simply prevent incidents with effective cybersecurity programs. Because of constantly increasing number of attacks, organizations must be proactive in creating an environment that is prepared to identify, contain, remove, and recover from cybersecurity incidents.

Incident Response Life Cycle

From NIST 800-61r2: Computer Security Incident Handling Guide Incident Response Team Structure From NIST 800-61r2: Computer Security Incident Handling Guide

Organization must minimally:

1. 1. Designate personnel to manage incident handling
2. 2. Establish and maintain contact information for reporting security incidents
3. 3. Establish and maintain an enterprise process for reporting incidents
4. 4. Establish and maintain an incident response process
5. 5. Assign key roles and responsibilities
6. 6. Define mechanisms for communicating during incident response
7. 7. Conduct routine incident response exercises or table-top-exercises
8. 8. Conduct post-incident reviews
9. 9. Establish and maintain security incident thresholds
10. 10. Build incident response policies/procedures that cover these items

Incident Response Must Haves:

1. 1. Define Severity Tiers
2. 2. Every security incident needs to be categorized and given a level of severity. This aids in assigning service-level agreements, directing incident escalations, and alerting stakeholders to the possible or actual effects of an incident on the company. Which playbook to convey, who gets notified, and the escalation path are all determined by the severity.
3. 3. Assign Roles and Responsibilities
4. 4. Reacting to incidents effectively is a team sport. Keep a RACI chart that lists every job and responsibility for incident response inside the company. Include the C-suite, legal, privacy, and HR departments as common stakeholders.
5. 5. Develop Detailed Response Playbooks
6. 6. The CSIR team should develop specific playbooks for common or high-impact incident types — such as ransomware, as shown in this example. Response playbooks are intended to offer comprehensive instructions and processes that extend beyond the typical incident response plan of security.
7. 7. Conduct Regular Tabletop Exercises
8. 8. Tabletop exercises for incident response should involve decision-makers and leaders from within the company. A well-structured tabletop involves clearly defined goals and prearranged scenarios to which participants must respond. Tabletop cybersecurity exercises work best when they start with a scenario (like malware), then move through a succession of scenes where participants are required to respond to fresh information added to the situation. The ambiguity and progression of actual situations are replicated in this structure. Tabletop exercises should imitate the difficult questions that participants would have to answer in a real attack.
9. 9. Report and know your government partners
10. 10. From Jen Easterly, head of CISA (Cybersecurity and Infrastructure Security Agency): Know your local CISA and FBI contacts and regional offices.
11. 11. They can help speed up the incident response process and help use this data to prevent similar attacks for other critical infrastructure organizations.
12. 12. Find Regional CISA Office
13. 13. Find Regional FBI Office

In critical infrastructure, there is more of an underpinned sense of community and fufillment in providing critical services that sustain our everyday life. Reporting any and all cybersecurity incidents allows CISA and the FBI to analyze attack methods, threats, help speed up that process, and prevent this to happening for other organizations. Please do your part and report.

Looking for somewhere to start?

Highly recommend PagerDuty's Incident Response Guidance wiki. Linked below. Covers every step in a lot of detail. Very actionable.

Incident Response Tools

Incident response tools are more about process management rather than a specific software solution that's the end all be all

Security Incident Response Example Policies

• •CMU Incident Response Plan
• •UCOP Incident Response Standard
• •Michigan Cyber Incident Response

Security Incident Policy Templates

• •SANS Incident Handling Policy Templates

For Additional Guidance:

• •NIST 800-61r2: Computer Security Incident Handling Guide
• •PagerDuty Incident Response Guidance

Incident Response Management

Today organizations can't simply prevent incidents with effective cybersecurity programs. Because of constantly increasing number of attacks, organizations must be proactive in creating an environment that is prepared to identify, contain, remove, and recover from cybersecurity incidents.

Incident Response Life Cycle

From NIST 800-61r2: Computer Security Incident Handling Guide Incident Response Team Structure From NIST 800-61r2: Computer Security Incident Handling Guide

Organization must minimally:

1. 1. Designate personnel to manage incident handling
2. 2. Establish and maintain contact information for reporting security incidents
3. 3. Establish and maintain an enterprise process for reporting incidents
4. 4. Establish and maintain an incident response process
5. 5. Assign key roles and responsibilities
6. 6. Define mechanisms for communicating during incident response
7. 7. Conduct routine incident response exercises or table-top-exercises
8. 8. Conduct post-incident reviews
9. 9. Establish and maintain security incident thresholds
10. 10. Build incident response policies/procedures that cover these items

Incident Response Must Haves:

1. 1. Define Severity Tiers
2. 2. Every security incident needs to be categorized and given a level of severity. This aids in assigning service-level agreements, directing incident escalations, and alerting stakeholders to the possible or actual effects of an incident on the company. Which playbook to convey, who gets notified, and the escalation path are all determined by the severity.
3. 3. Assign Roles and Responsibilities
4. 4. Reacting to incidents effectively is a team sport. Keep a RACI chart that lists every job and responsibility for incident response inside the company. Include the C-suite, legal, privacy, and HR departments as common stakeholders.
5. 5. Develop Detailed Response Playbooks
6. 6. The CSIR team should develop specific playbooks for common or high-impact incident types — such as ransomware, as shown in this example. Response playbooks are intended to offer comprehensive instructions and processes that extend beyond the typical incident response plan of security.
7. 7. Conduct Regular Tabletop Exercises
8. 8. Tabletop exercises for incident response should involve decision-makers and leaders from within the company. A well-structured tabletop involves clearly defined goals and prearranged scenarios to which participants must respond. Tabletop cybersecurity exercises work best when they start with a scenario (like malware), then move through a succession of scenes where participants are required to respond to fresh information added to the situation. The ambiguity and progression of actual situations are replicated in this structure. Tabletop exercises should imitate the difficult questions that participants would have to answer in a real attack.
9. 9. Report and know your government partners
10. 10. From Jen Easterly, head of CISA (Cybersecurity and Infrastructure Security Agency): Know your local CISA and FBI contacts and regional offices.
11. 11. They can help speed up the incident response process and help use this data to prevent similar attacks for other critical infrastructure organizations.
12. 12. Find Regional CISA Office
13. 13. Find Regional FBI Office

In critical infrastructure, there is more of an underpinned sense of community and fufillment in providing critical services that sustain our everyday life. Reporting any and all cybersecurity incidents allows CISA and the FBI to analyze attack methods, threats, help speed up that process, and prevent this to happening for other organizations. Please do your part and report.

Looking for somewhere to start?

Highly recommend PagerDuty's Incident Response Guidance wiki. Linked below. Covers every step in a lot of detail. Very actionable.

Incident Response Tools

Incident response tools are more about process management rather than a specific software solution that's the end all be all

Security Incident Response Example Policies

• •CMU Incident Response Plan
• •UCOP Incident Response Standard
• •Michigan Cyber Incident Response

Security Incident Policy Templates

• •SANS Incident Handling Policy Templates

For Additional Guidance:

• •NIST 800-61r2: Computer Security Incident Handling Guide
• •PagerDuty Incident Response Guidance

Incident Response Management

Today organizations can't simply prevent incidents with effective cybersecurity programs. Because of constantly increasing number of attacks, organizations must be proactive in creating an environment that is prepared to identify, contain, remove, and recover from cybersecurity incidents.

Incident Response Life Cycle

From NIST 800-61r2: Computer Security Incident Handling Guide Incident Response Team Structure From NIST 800-61r2: Computer Security Incident Handling Guide

Organization must minimally:

1. 1. Designate personnel to manage incident handling
2. 2. Establish and maintain contact information for reporting security incidents
3. 3. Establish and maintain an enterprise process for reporting incidents
4. 4. Establish and maintain an incident response process
5. 5. Assign key roles and responsibilities
6. 6. Define mechanisms for communicating during incident response
7. 7. Conduct routine incident response exercises or table-top-exercises
8. 8. Conduct post-incident reviews
9. 9. Establish and maintain security incident thresholds
10. 10. Build incident response policies/procedures that cover these items

Incident Response Must Haves:

1. 1. Define Severity Tiers
2. 2. Every security incident needs to be categorized and given a level of severity. This aids in assigning service-level agreements, directing incident escalations, and alerting stakeholders to the possible or actual effects of an incident on the company. Which playbook to convey, who gets notified, and the escalation path are all determined by the severity.
3. 3. Assign Roles and Responsibilities
4. 4. Reacting to incidents effectively is a team sport. Keep a RACI chart that lists every job and responsibility for incident response inside the company. Include the C-suite, legal, privacy, and HR departments as common stakeholders.
5. 5. Develop Detailed Response Playbooks
6. 6. The CSIR team should develop specific playbooks for common or high-impact incident types — such as ransomware, as shown in this example. Response playbooks are intended to offer comprehensive instructions and processes that extend beyond the typical incident response plan of security.
7. 7. Conduct Regular Tabletop Exercises
8. 8. Tabletop exercises for incident response should involve decision-makers and leaders from within the company. A well-structured tabletop involves clearly defined goals and prearranged scenarios to which participants must respond. Tabletop cybersecurity exercises work best when they start with a scenario (like malware), then move through a succession of scenes where participants are required to respond to fresh information added to the situation. The ambiguity and progression of actual situations are replicated in this structure. Tabletop exercises should imitate the difficult questions that participants would have to answer in a real attack.
9. 9. Report and know your government partners
10. 10. From Jen Easterly, head of CISA (Cybersecurity and Infrastructure Security Agency): Know your local CISA and FBI contacts and regional offices.
11. 11. They can help speed up the incident response process and help use this data to prevent similar attacks for other critical infrastructure organizations.
12. 12. Find Regional CISA Office
13. 13. Find Regional FBI Office

In critical infrastructure, there is more of an underpinned sense of community and fufillment in providing critical services that sustain our everyday life. Reporting any and all cybersecurity incidents allows CISA and the FBI to analyze attack methods, threats, help speed up that process, and prevent this to happening for other organizations. Please do your part and report.

Looking for somewhere to start?

Highly recommend PagerDuty's Incident Response Guidance wiki. Linked below. Covers every step in a lot of detail. Very actionable.

Incident Response Tools

Incident response tools are more about process management rather than a specific software solution that's the end all be all

Security Incident Response Example Policies

• •CMU Incident Response Plan
• •UCOP Incident Response Standard
• •Michigan Cyber Incident Response

Security Incident Policy Templates

• •SANS Incident Handling Policy Templates

For Additional Guidance:

• •NIST 800-61r2: Computer Security Incident Handling Guide
• •PagerDuty Incident Response Guidance

Incident Response Management

Today organizations can't simply prevent incidents with effective cybersecurity programs. Because of constantly increasing number of attacks, organizations must be proactive in creating an environment that is prepared to identify, contain, remove, and recover from cybersecurity incidents.

Incident Response Life Cycle

From NIST 800-61r2: Computer Security Incident Handling Guide Incident Response Team Structure From NIST 800-61r2: Computer Security Incident Handling Guide

Organization must minimally:

1. 1. Designate personnel to manage incident handling
2. 2. Establish and maintain contact information for reporting security incidents
3. 3. Establish and maintain an enterprise process for reporting incidents
4. 4. Establish and maintain an incident response process
5. 5. Assign key roles and responsibilities
6. 6. Define mechanisms for communicating during incident response
7. 7. Conduct routine incident response exercises or table-top-exercises
8. 8. Conduct post-incident reviews
9. 9. Establish and maintain security incident thresholds
10. 10. Build incident response policies/procedures that cover these items

Incident Response Must Haves:

1. 1. Define Severity Tiers
2. 2. Every security incident needs to be categorized and given a level of severity. This aids in assigning service-level agreements, directing incident escalations, and alerting stakeholders to the possible or actual effects of an incident on the company. Which playbook to convey, who gets notified, and the escalation path are all determined by the severity.
3. 3. Assign Roles and Responsibilities
4. 4. Reacting to incidents effectively is a team sport. Keep a RACI chart that lists every job and responsibility for incident response inside the company. Include the C-suite, legal, privacy, and HR departments as common stakeholders.
5. 5. Develop Detailed Response Playbooks
6. 6. The CSIR team should develop specific playbooks for common or high-impact incident types — such as ransomware, as shown in this example. Response playbooks are intended to offer comprehensive instructions and processes that extend beyond the typical incident response plan of security.
7. 7. Conduct Regular Tabletop Exercises
8. 8. Tabletop exercises for incident response should involve decision-makers and leaders from within the company. A well-structured tabletop involves clearly defined goals and prearranged scenarios to which participants must respond. Tabletop cybersecurity exercises work best when they start with a scenario (like malware), then move through a succession of scenes where participants are required to respond to fresh information added to the situation. The ambiguity and progression of actual situations are replicated in this structure. Tabletop exercises should imitate the difficult questions that participants would have to answer in a real attack.
9. 9. Report and know your government partners
10. 10. From Jen Easterly, head of CISA (Cybersecurity and Infrastructure Security Agency): Know your local CISA and FBI contacts and regional offices.
11. 11. They can help speed up the incident response process and help use this data to prevent similar attacks for other critical infrastructure organizations.
12. 12. Find Regional CISA Office
13. 13. Find Regional FBI Office

In critical infrastructure, there is more of an underpinned sense of community and fufillment in providing critical services that sustain our everyday life. Reporting any and all cybersecurity incidents allows CISA and the FBI to analyze attack methods, threats, help speed up that process, and prevent this to happening for other organizations. Please do your part and report.

Looking for somewhere to start?

Highly recommend PagerDuty's Incident Response Guidance wiki. Linked below. Covers every step in a lot of detail. Very actionable.

Incident Response Tools

Incident response tools are more about process management rather than a specific software solution that's the end all be all

Security Incident Response Example Policies

• •CMU Incident Response Plan
• •UCOP Incident Response Standard
• •Michigan Cyber Incident Response

Security Incident Policy Templates

• •SANS Incident Handling Policy Templates

For Additional Guidance:

• •NIST 800-61r2: Computer Security Incident Handling Guide
• •PagerDuty Incident Response Guidance

Incident Response Management

Today organizations can't simply prevent incidents with effective cybersecurity programs. Because of constantly increasing number of attacks, organizations must be proactive in creating an environment that is prepared to identify, contain, remove, and recover from cybersecurity incidents.

Incident Response Life Cycle

From NIST 800-61r2: Computer Security Incident Handling Guide Incident Response Team Structure From NIST 800-61r2: Computer Security Incident Handling Guide

Organization must minimally:

1. 1. Designate personnel to manage incident handling
2. 2. Establish and maintain contact information for reporting security incidents
3. 3. Establish and maintain an enterprise process for reporting incidents
4. 4. Establish and maintain an incident response process
5. 5. Assign key roles and responsibilities
6. 6. Define mechanisms for communicating during incident response
7. 7. Conduct routine incident response exercises or table-top-exercises
8. 8. Conduct post-incident reviews
9. 9. Establish and maintain security incident thresholds
10. 10. Build incident response policies/procedures that cover these items

Incident Response Must Haves:

1. 1. Define Severity Tiers
2. 2. Every security incident needs to be categorized and given a level of severity. This aids in assigning service-level agreements, directing incident escalations, and alerting stakeholders to the possible or actual effects of an incident on the company. Which playbook to convey, who gets notified, and the escalation path are all determined by the severity.
3. 3. Assign Roles and Responsibilities
4. 4. Reacting to incidents effectively is a team sport. Keep a RACI chart that lists every job and responsibility for incident response inside the company. Include the C-suite, legal, privacy, and HR departments as common stakeholders.
5. 5. Develop Detailed Response Playbooks
6. 6. The CSIR team should develop specific playbooks for common or high-impact incident types — such as ransomware, as shown in this example. Response playbooks are intended to offer comprehensive instructions and processes that extend beyond the typical incident response plan of security.
7. 7. Conduct Regular Tabletop Exercises
8. 8. Tabletop exercises for incident response should involve decision-makers and leaders from within the company. A well-structured tabletop involves clearly defined goals and prearranged scenarios to which participants must respond. Tabletop cybersecurity exercises work best when they start with a scenario (like malware), then move through a succession of scenes where participants are required to respond to fresh information added to the situation. The ambiguity and progression of actual situations are replicated in this structure. Tabletop exercises should imitate the difficult questions that participants would have to answer in a real attack.
9. 9. Report and know your government partners
10. 10. From Jen Easterly, head of CISA (Cybersecurity and Infrastructure Security Agency): Know your local CISA and FBI contacts and regional offices.
11. 11. They can help speed up the incident response process and help use this data to prevent similar attacks for other critical infrastructure organizations.
12. 12. Find Regional CISA Office
13. 13. Find Regional FBI Office

In critical infrastructure, there is more of an underpinned sense of community and fufillment in providing critical services that sustain our everyday life. Reporting any and all cybersecurity incidents allows CISA and the FBI to analyze attack methods, threats, help speed up that process, and prevent this to happening for other organizations. Please do your part and report.

Looking for somewhere to start?

Highly recommend PagerDuty's Incident Response Guidance wiki. Linked below. Covers every step in a lot of detail. Very actionable.

Incident Response Tools

Incident response tools are more about process management rather than a specific software solution that's the end all be all

Security Incident Response Example Policies

• •CMU Incident Response Plan
• •UCOP Incident Response Standard
• •Michigan Cyber Incident Response

Security Incident Policy Templates

• •SANS Incident Handling Policy Templates

For Additional Guidance:

• •NIST 800-61r2: Computer Security Incident Handling Guide
• •PagerDuty Incident Response Guidance

Incident Response Management

Today organizations can't simply prevent incidents with effective cybersecurity programs. Because of constantly increasing number of attacks, organizations must be proactive in creating an environment that is prepared to identify, contain, remove, and recover from cybersecurity incidents.

Incident Response Life Cycle

From NIST 800-61r2: Computer Security Incident Handling Guide Incident Response Team Structure From NIST 800-61r2: Computer Security Incident Handling Guide

Organization must minimally:

1. 1. Designate personnel to manage incident handling
2. 2. Establish and maintain contact information for reporting security incidents
3. 3. Establish and maintain an enterprise process for reporting incidents
4. 4. Establish and maintain an incident response process
5. 5. Assign key roles and responsibilities
6. 6. Define mechanisms for communicating during incident response
7. 7. Conduct routine incident response exercises or table-top-exercises
8. 8. Conduct post-incident reviews
9. 9. Establish and maintain security incident thresholds
10. 10. Build incident response policies/procedures that cover these items

Incident Response Must Haves:

1. 1. Define Severity Tiers
2. 2. Every security incident needs to be categorized and given a level of severity. This aids in assigning service-level agreements, directing incident escalations, and alerting stakeholders to the possible or actual effects of an incident on the company. Which playbook to convey, who gets notified, and the escalation path are all determined by the severity.
3. 3. Assign Roles and Responsibilities
4. 4. Reacting to incidents effectively is a team sport. Keep a RACI chart that lists every job and responsibility for incident response inside the company. Include the C-suite, legal, privacy, and HR departments as common stakeholders.
5. 5. Develop Detailed Response Playbooks
6. 6. The CSIR team should develop specific playbooks for common or high-impact incident types — such as ransomware, as shown in this example. Response playbooks are intended to offer comprehensive instructions and processes that extend beyond the typical incident response plan of security.
7. 7. Conduct Regular Tabletop Exercises
8. 8. Tabletop exercises for incident response should involve decision-makers and leaders from within the company. A well-structured tabletop involves clearly defined goals and prearranged scenarios to which participants must respond. Tabletop cybersecurity exercises work best when they start with a scenario (like malware), then move through a succession of scenes where participants are required to respond to fresh information added to the situation. The ambiguity and progression of actual situations are replicated in this structure. Tabletop exercises should imitate the difficult questions that participants would have to answer in a real attack.
9. 9. Report and know your government partners
10. 10. From Jen Easterly, head of CISA (Cybersecurity and Infrastructure Security Agency): Know your local CISA and FBI contacts and regional offices.
11. 11. They can help speed up the incident response process and help use this data to prevent similar attacks for other critical infrastructure organizations.
12. 12. Find Regional CISA Office
13. 13. Find Regional FBI Office

In critical infrastructure, there is more of an underpinned sense of community and fufillment in providing critical services that sustain our everyday life. Reporting any and all cybersecurity incidents allows CISA and the FBI to analyze attack methods, threats, help speed up that process, and prevent this to happening for other organizations. Please do your part and report.

Looking for somewhere to start?

Highly recommend PagerDuty's Incident Response Guidance wiki. Linked below. Covers every step in a lot of detail. Very actionable.

Incident Response Tools

Incident response tools are more about process management rather than a specific software solution that's the end all be all

Security Incident Response Example Policies

• •CMU Incident Response Plan
• •UCOP Incident Response Standard
• •Michigan Cyber Incident Response

Security Incident Policy Templates

• •SANS Incident Handling Policy Templates

For Additional Guidance:

• •NIST 800-61r2: Computer Security Incident Handling Guide
• •PagerDuty Incident Response Guidance

Data recovery has become a paramount concern for organizations. While the focus used to be primarily on preventing cyberattacks, there has been a recent shift in mindset. This shift is driven by the escalating frequency of attacks, particularly in critical infrastructure sectors that have historically lagged behind in robust cybersecurity measures. Now, organizations are advised to allocate significant attention to developing strategies for mitigating and remediating the consequences of cyber breaches. The emphasis is on being prepared for the eventuality of a successful hack.

Key to the mitigation and remediation strategy revolves around data recovery.

Consider the 3-2-1 Methodology:

• •Three: Keep three copies of data, the original data copy, and at least two backups
• •Two: Use two different storage types. For instance, if data is stored on an internal hard drive, use a secondary device such as an external drive or cloud source
• •One: Keep one copy of data offsite

Organizations should develop a data recovery process that covers the following:

• •What systems/applications should be backed up (risk prioritize assets)
• •Where will these backups be stored (if stored online or on the network, the storage should be properly segmented)
• •How often will the backups occur
• •Will we automate the backups
• •How long will we keep the backups based upon regulation or storage capacity
• •Who has access to the backups
• •What backups will we encrypt
• •In the event of a cyber attack, is operations aware of how to recover from the backups

Ensure you are not just backing up your Windows operator stations, engineer stations, or data historians, but also your network equipment, project files, and other ICS configurations.

Project Files - PLCs/HMIs:

• •Low Maturity or small environment: Run a backup and store this logically (NAS, SharePoint, Fileserver) and physically (hard drive in fireproof safe as an example). Update backups minimally every time configuration changes occur. Put a date in the folder/file name to at least tell you when the configuration was taken.
• •For Higher Maturity or large environments with multiple engineers making configuration changes: Tools such as Version Dog or Copia can be used to pull configurations and for configuration change management. With Copia, DeviceLink used to pull configurations into its dashboard using an agent installed onto a PC at the site. Copia is Git-based version control. Under the dashboard, users can review the code and work together to make changes and keep track of versions.

Personnel Cybersecurity Training

Personnel cybersecurity training isn't just phishing training. Building a comprehensive security awareness program includes minimally the following:

• •Personnel are trained to recognize social engineering attacks
• •On data handling best practices
• •On authentication best practices
• •On causes of unintentional data exposure
• •On recognizing and reporting security incidents
• •Identify and report if their enterprise assets are missing security updates
• •Dangers of connecting to and transmitting enterprise data over insecure networks
• •USB best practices
• •Constantly and are tested on their knowledge of cybersecurity concepts

Phishing:

Phishing training is pretty straight forward. Through one of the solution providers, quiz and test your users to ensure they are continuously training to spot phishing attempts.

• •Phishing training needs to not only include video based training, but also quizzes and simulation-based testing, sending test phishing emails to employees.
• •Phishing testing on employees should occur monthly.
• •Consider consequences for those that continually fail.

General and Role-Based Training:

General and role-based training should go hand in hand with cyber roles and responsibilities and align with other policies and procedures, such as incident response plans. Every personnel member should minimally contribute to preventing cyberattacks through the use of email, web, USB, and job-specific cyber best practices. However, employees also need to be proactive and able to understand how to spot a cyberattack when they encounter one, knowing how to escalate quickly and effectively.

Training your Cyber team:

Often missed throughout the “cybersecurity lifecycle” is training your cybersecurity team. While they may be experts in certain niches of IT or cyber you must make sure they’re trained in the tool they’re using on a day to day or new tools around the corner. Misconfiguration and mismanagement of systems is one of the biggest causes of hacks. Not a zero-day or Stuxnet scenario but simply a misconfigured firewall. Or a legacy VPN account. This everyday gap in responsibility, training, or procedures causes most of the hacks today. Pay extra attention to this.

One method is to create a RACI matrix for your team. This breaks down who is responsible, accountable, consulted, and informed about various cybersecurity functions whether that is vulnerability scanning, updating x policy, etc.

For Additional Guidance:

NIST 800-50 Building an Information Technology Security Awareness and Training Program