[{"content":"","date":"April 11, 2026","externalUrl":null,"permalink":"/blog/","section":"Blog","summary":"","title":"Blog","type":"blog"},{"content":"","date":"April 11, 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"April 11, 2026","externalUrl":null,"permalink":"/","section":"Cutaway Security","summary":"","title":"Cutaway Security","type":"page"},{"content":"","date":"April 11, 2026","externalUrl":null,"permalink":"/categories/ics/ot/scada/","section":"Categories","summary":"","title":"ICS/OT/SCADA","type":"categories"},{"content":" TL;DR # Setting up a proper Windows testing environment for ICS/OT security tool development goes beyond spinning up a single VM. You need multiple Windows versions, from legacy Windows 7 through Server 2022, templated, sysprepped, and network-isolated so you can rapidly deploy clean test systems and tear them down when you\u0026rsquo;re done. This post summarizes my experience building a Proxmox-based development lab with automated VM management for testing Sysmon configurations and security scripts across every supported Windows version. The complete setup guide is available as a PDF download. We document these projects to both remember what we have done and also help others with similar projects.\nAI-Assisted Planning # Like the Framework Desktop build, this entire lab was planned and troubleshot with assistance from Claude, Anthropic\u0026rsquo;s AI assistant. The build conversation covered Proxmox networking, Windows template creation, Sysprep quirks across multiple Windows versions, and debugging issues like TLS failures on Windows 7, Sysmon\u0026rsquo;s silent failure modes in PowerShell, and Win11\u0026rsquo;s EFI clone boot problems. When something didn\u0026rsquo;t work as expected, as they typically do, Claude helped diagnose the problem and propose solutions.\nThe resulting setup guide captures every workaround and lesson learned so you don\u0026rsquo;t have to discover them yourself.\nWhy a Multi-Version Windows Lab? # ICS/OT environments run everything. Windows 7 is still common in control system networks, Server 2016 runs plenty of historians and HMI servers, and newer deployments are moving to Server 2022 and Windows 11. When you\u0026rsquo;re developing security monitoring configurations or assessment scripts, you need to verify they work across all of these and not just the latest version on your laptop.\nA Proxmox-based lab with templates and full clones gives you repeatable, isolated test environments. Clone a template, test your Sysmon config, verify the results, halt the clone, and move to the next Windows version. The Proxmox API lets you script this entire cycle, and with SSH access to each VM, you can push configurations and collect results without touching the Proxmox or Windows system GUIs.\nLab Architecture # The lab runs on a two-node Proxmox cluster (Intel NUCs) with isolated virtual networking:\nPhysical LAN (192.168.1.0/24) — the home/office network where the Proxmox cluster and the development server live Dev Network (vmbr1, 192.168.100.0/24) — an isolated virtual bridge with NAT to the internet, hosting all development VMs Future Networks — additional bridges for Active Directory labs, AI workloads, and other pool types The development server on the physical LAN reaches the VMs via a static route through the Proxmox host, which acts as the router between networks. Each VM gets a static IP and SSH access with key-based authentication.\nThe resource constraint is real — the NUCs can\u0026rsquo;t run all VMs simultaneously. The test workflow starts one VM, runs the test via SSH, shuts it down, and moves to the next. The Proxmox API makes this scriptable.\nTemplate Build Process # Each Windows version gets a template VM built through a consistent process:\nInstall Windows with VirtIO drivers (SCSI driver loaded during setup) Install VirtIO guest tools and QEMU Guest Agent Run Windows Update Disable Windows Defender real-time protection (isolated test VMs only) Install OpenSSH Server and configure for automatic start Install Sysmon (service only, no configuration — configs are pushed during testing) Sysprep with /generalize /oobe /shutdown for unique SIDs on clones Convert to template (irreversible, read-only) Clones are created as full clones (not linked) and assigned to the appropriate pool. This keeps each clone independent — no dependency on the template\u0026rsquo;s disk.\nLessons Learned the Hard Way # Every Windows version had its own surprises. Here are the highlights:\nWindows 7 is the most labor-intensive. Fresh installs can\u0026rsquo;t reach Windows Update or browse the web because they default to TLS 1.0 and have expired root certificates. You have to manually bootstrap three KB updates (KB3020369, KB3125574, KB3140245) and apply TLS 1.2 registry keys before anything network-related works. The latest VirtIO drivers do not work and you need to manually install all VirtIO drivers from a very old version of these drivers. And the current Sysmon doesn\u0026rsquo;t support Win7 at all; you need v10.42, which is only available via the Wayback Machine. (Another good reason to update, if possible).\nWindows 11 requires proper configuration of TPM 2.0, Secure Boot (Pre-Enroll Keys), and UEFI. Miss any of these in the Proxmox VM settings and the installer refuses to proceed. BitLocker may silently encrypt the disk before you can Sysprep, making clones unbootable. Disable BitLocker immediately after reaching the desktop. And pre-installed apps can block Sysprep — you have to identify them from the log file and remove them one at a time.\nServer 2016 needs PowerShell configured for TLS 1.2 via .NET Framework registry keys, or you\u0026rsquo;ll get silent failures from Invoke-WebRequest, NuGet, and Windows Update.\nServer editions have a Shutdown Event Tracker that prompts for a reason on every shutdown, blocking remote and automated shutdowns. Disable it via Group Policy before Sysprep.\nDownloaded files from the internet are blocked by Windows by default. Sysmon, configuration files, and update packages all need Unblock-File before they\u0026rsquo;ll execute properly.\nAnd, more\u0026hellip; Much, Much, More\u0026hellip;.\nDownload # The complete setup guide with step-by-step instructions is available here: Proxmox Development Lab Setup Guide (PDF)\nGo forth and do good things, Don C. Weber\n","date":"April 11, 2026","externalUrl":null,"permalink":"/blog/proxmox-ai-development-lab/","section":"Blog","summary":"TL;DR # Setting up a proper Windows testing environment for ICS/OT security tool development goes beyond spinning up a single VM. You need multiple Windows versions, from legacy Windows 7 through Server 2022, templated, sysprepped, and network-isolated so you can rapidly deploy clean test systems and tear them down when you’re done. This post summarizes my experience building a Proxmox-based development lab with automated VM management for testing Sysmon configurations and security scripts across every supported Windows version. The complete setup guide is available as a PDF download. We document these projects to both remember what we have done and also help others with similar projects.\n","title":"Proxmox AI Development Lab","type":"blog"},{"content":"","date":"April 11, 2026","externalUrl":null,"permalink":"/categories/technical/","section":"Categories","summary":"","title":"Technical","type":"categories"},{"content":" TL;DR # Using AI/LLM goes beyond using ChatGPT, Gemini, and Claude. Running large language models (LLMs) locally eliminates cloud dependencies, keeps sensitive data on-premises, and provides the computational muscle needed for AI-assisted security research. This post summarizes my experience building a dedicated AI development server using the Framework Desktop with AMD\u0026rsquo;s Ryzen AI Max+ 395 processor — a system capable of running 70B parameter models entirely in local memory.\nThe complete installation guide is available as a PDF download. Future improvements and developed tools will be published to the CutSec GitHub repositories.\nAI-Assisted Planning # To manage and speed up the server deployment, this build was planned and troubleshot with assistance from Claude, Anthropic\u0026rsquo;s AI assistant. The build conversation spanned hardware selection, partition layouts, GPU memory configuration, and debugging issues like LUKS boot prompts and Qdrant API changes. When something didn\u0026rsquo;t work as expected, Claude helped diagnose the problem and propose solutions, significantly speeding up the process.\nAny capable AI assistant can fill this role, such as ChatGPT, Gemini, or others. The key benefit is having a knowledgeable collaborator available to work through technical decisions, generate configuration files, and troubleshoot errors in real-time. For complex builds like this one, AI assistance reduces the time spent searching documentation and forums, letting you focus on the actual work.\nFuture development efforts on this platform will continue using AI collaboration, and we\u0026rsquo;ll share tooling and improvements through the CutSec GitHub repositories.\nWhy Local LLMs for Cybersecurity? # Cloud-based AI services are convenient, but they come with trade-offs: data leaves your control, API costs accumulate, and internet connectivity becomes a dependency. For cybersecurity work, especially ICS/OT assessments where client data sensitivity is paramount, local inference offers significant advantages.\nThe Framework Desktop with its 128GB of unified memory provides enough headroom to run production-quality models locally. The AMD Radeon 8060S integrated GPU shares system memory, eliminating the traditional VRAM bottleneck that limits most local LLM setups.\nHardware Overview # The build centers on Framework\u0026rsquo;s Desktop system with the AMD Ryzen AI Max+ 395 processor. Key specifications:\nCPU/GPU: AMD Ryzen AI Max+ 395 with integrated Radeon 8060S Memory: 128GB DDR5 unified memory (shared between CPU and GPU) Storage: Dual 4TB NVMe drives — one for system/development, one for AI models and datasets GPU Memory Allocation: 96GB configured for GPU tasks via GTT Installation Summary # The installation follows eight phases, from hardware assembly through a working RAG (Retrieval-Augmented Generation) pipeline:\nPhase 1-2: Hardware and BIOS — Standard assembly with BIOS defaults suitable for the AMD platform. No special virtualization settings required.\nPhase 3: OS Installation — Kubuntu 24.04 LTS with the HWE (Hardware Enablement) stack for newer kernel support. LUKS encryption protects sensitive partitions while leaving the AI models partition unencrypted for performance.\nPhase 4: GPU Configuration — The Vulkan/Mesa stack works out of the box. GTT (Graphics Translation Table) memory is configured via kernel parameter to allow the GPU to utilize up to 96GB of system memory for model inference.\nPhase 5: Core Tools — Development essentials, security tools (nmap, netcat, tcpdump, SecLists), Docker, Tailscale for remote access, and pass for GPG-encrypted credential management that works over SSH.\nPhase 6: LLM Stack — Ollama provides the primary interface for model management and inference. Open WebUI delivers a browser-based chat interface. The system comfortably runs 7B models at 50+ tokens/second and 70B quantized models at usable speeds.\nPhase 7: Claude Code — Anthropic\u0026rsquo;s CLI tool for AI-assisted development, configured with secure API key storage via pass.\nPhase 8: RAG Pipeline — Qdrant vector database with local embeddings via Ollama\u0026rsquo;s nomic-embed-text model. This enables semantic search across ICS/OT documentation, PCAPs, and vendor manuals.\nKey Capabilities # The completed system provides:\nLocal inference of 70B+ parameter models with no cloud dependency RAG pipeline for searching technical documentation using natural language Secure remote development via Tailscale (SSH and RDP) Encrypted storage for sensitive assessment data Foundation for ICS/OT security tooling development Download # The complete installation guide with step-by-step instructions is available here:\nFramework Desktop AI Workstation Installation Guide\nFuture improvements and related security tools will be published to the CutSec GitHub repositories.\nGo forth and do good things, Don C. Weber\n","date":"February 7, 2026","externalUrl":null,"permalink":"/blog/building-a-local-ai-development-server-with-framework-desktop/","section":"Blog","summary":"TL;DR # Using AI/LLM goes beyond using ChatGPT, Gemini, and Claude. Running large language models (LLMs) locally eliminates cloud dependencies, keeps sensitive data on-premises, and provides the computational muscle needed for AI-assisted security research. This post summarizes my experience building a dedicated AI development server using the Framework Desktop with AMD’s Ryzen AI Max+ 395 processor — a system capable of running 70B parameter models entirely in local memory.\n","title":"Building a Local AI Development Server with Framework Desktop","type":"blog"},{"content":"This morning I was thinking about completing an article I was writing about KPIs and OKRs. The more I wrote, the more I realized I was just regurgitating research and making pity comments. Which means, it was crap. So, I refocused and turned to AI to help me. I ask Google\u0026rsquo;s Gemini the following question.\nConsidering the 5 ICS Cybersecurity Critical Controls, outline a quick win plan to achieve and measure success. The plan should be for a team that is leading a small administrative and operations team of 5 people. Each of the 5 areas should have three things to understand within the first month and set up timelines for the next four months to address the top issue in each.\nFeel free to check out Gemini\u0026rsquo;s response [Edited: link removed since it leaked other Gemini queries in addition to the original content.]\nAfter reading the results, I do not think it hit the mark. But, I do think it is usable with modifications. Here are my modifications. Jump on Linked In and tell me about what your team would change to this approach.\nAlright, let\u0026rsquo;s craft a quick win plan for a small ICS cybersecurity team (5 people) focusing on the SANS 5 ICS Cybersecurity Critical Controls. We\u0026rsquo;ll prioritize understanding within the first month the team can use to outline a four-month timeline of milestones for addressing the top issues in each control.\nThe 5 ICS Cybersecurity Critical Controls: # As usual, I will re-order these as I feel will provide the ICS / OT team with the best methods for ensuring availability and reliability of operation. For security assessments I typically start with remote access, but for a program, the ICS IR plan is more important as it goes to being prepared for recovery.\nICS Incident Response Plan Secure Remote Access Defensible Architecture ICS Network Visibility and Monitoring Risk-based Vulnerability Management SANS ICS Whitepaper on The Five ICS Cybersecurity Critical Controls: https://www.sans.org/white-papers/five-ics-cybersecurity-critical-controls/\nMonth 1: Understanding and Assessment # During the first month, the team will focus on understanding the current state of each control within their environment. This is crucial for identifying quick wins. The team should gather information but only spend a limited amount of time. Team members should not be required to update documentation or make it more complete, at this stage. Some of this effort might be discovering what the parent organization is requiring or getting a better understanding of current regulatory requirements.\nICS Incident Response Plan # Understand:\nContact list for key personnel to include team, vendors, and leadership.\nThe team\u0026rsquo;s roles and responsibilities during an incident.\nExisting incident response plans (if any) and their relevance to ICS.\nThe communication channels for reporting and responding to incidents.\nTop Issue: Team does not understand roles during events and incidents.\nMeasurement: Contact list with primary and secondary contacts and offline contact information. Initial table-top session with action items for next steps.\nCutSec Comment: Gemini recommended documenting an IR plan first. I recommend focusing on generating a contact list for key personnel. Then, sitting those key personnel down to discuss what THEIR understanding about the process. Let the team pick and drive next steps that benefits operations. Cybersecurity SMEs can help fill the gaps for the team when they do not understand a topic or requirements.\nSecure Remote Access # Understand:\nDocument all physical, wired, and wireless remote access to the operational environment.\nDocument the current method for managing authorized access to each method of remote access.\nReview the process for managing and auditing access to distinguish between authorized and unauthorized access.\nTop Issue: No method for business unit owners, responsible for operations, to review access to their area of responsibility.\nMeasurement: Inventory of all remote access techniques and documentation of how and who reviews access to determine authorized and unauthorized access.\nCutSec Comment: Gemini recommended improving authentication. That is actually a rookie mistake when it comes to protecting ICS/OT operations. The key is understanding ALL the methods for remote access, first. Then start looking at how these remote access methods are managed.\nDefensible Architecture # Understand:\nThe current network architecture and segmentation of the ICS environment.\nThe placement and configuration of firewalls and other security devices.\nThe physical security measures in place to protect ICS assets.\nTop Issue: Flat network architecture with minimal segmentation.\nMeasurement: Network diagram documentation, and a list of all installed firewalls and other security devices.\nCutSec Comment: Gemini\u0026rsquo;s recommends are not bad here. We\u0026rsquo;ll leave it alone for brevity. When considering ISA/IEC 62443 security programs the requirement here would be to conduct a High-Level Risk assessment, which is just gathering ALL of the documentation for the part of the operations being reviewed.\nICS Network Visibility and Monitoring # Understand:\nThe current monitoring tools and techniques used to detect security events.\nThe types of logs and alerts that are generated by ICS devices.\nThe process for analyzing and responding to security alerts.\nTop Issue: Limited or no real-time monitoring of ICS network traffic.\nMeasurement Documentation of current monitoring tools and logs, and a list of all security alerts currently generated.\nCutSec Comment: Gemini assessment here is correct. Logging and monitoring are still issues that plague ICS/OT organizations. Understanding what is currently being done is key. No need to buy products, configure and use what you currently have correctly.\nRisk-based Vulnerability Management # Understand:\nReview the CISA KEV to familiarize the team with the concept and the resource.\nReview current state of inventory of all ICS hardware and software and determine if operational criticality have been assigned.\nDetermine if inventory information can support CISA KEV process.\nTop Issue: Ineffective vulnerability management program focused on operations.\nMeasurement: Documentation of the current state for ICS asset inventory and a list hardware and software that are currently included on the CISA KEV list.\nCutSec Comment: A mixed back from Gemini on this one. Asset management is important but vulnerability scanning is NOT the way to start a program. Many organizations have used CISA Known Exploited Vulnerabilities Catalog to help focus their efforts. If they are saying it has protected their operations, perhaps the team should investigate what that process looks like.\nMonths 2-5: Implementation and Improvement # After the first month of results the team and leadership should now have a clear understanding of the current state. The team should set the direction for the next five months and express this to leadership. Leadership should accept this with simple modifications to help prioritize efforts and provide help through assistance from corporate teams, vendors, integrators, and third-party cybersecurity teams.\nThe following would be an example of possible, achievable, follow on efforts over the next month. Wash, rinse, repeat to achieve steady improvements and protections for operations.\nMonth 2 # ICS Incident Response Plan: Conduct a table-top exercise that reviews unauthorized access to the most likely avenue a threat actor will gain access to operational assets. Secure Remote Access: Implement a stronger password policy. Defensible Architecture: Create a plan to improve access, segmentation, and data flow to critical ICS operational assets. ICS Network Visibility and Monitoring: Configure basic network traffic monitoring. Risk-based Vulnerability Management: Perform an initial vulnerability scan. Measuring Success # Measuring success is different from organization to organization. Individual leadership should be guiding teams to what is affected measures of success. I am not going to lay those out here. After these initial successes the team should be able to set up milestone that are focused on preserving operations. Leadership\u0026rsquo;s inputs should be help the team remain focused on prevention, detection, response, and recovery. The 5 ICS cybersecurity critical controls can help drive this direction with more granular detail coming from industry standards, such as the guidance in the updated ISA/IEC 62443-2-1 standard.\nGo forth and do good things,\nDon C. Weber\n","date":"February 26, 2025","externalUrl":null,"permalink":"/blog/starting-cybersecurity-program-for-small-ics-ot-teams/","section":"Blog","summary":"This morning I was thinking about completing an article I was writing about KPIs and OKRs. The more I wrote, the more I realized I was just regurgitating research and making pity comments. Which means, it was crap. So, I refocused and turned to AI to help me. I ask Google’s Gemini the following question.\n","title":"Starting Cybersecurity Program for Small ICS / OT Teams","type":"blog"},{"content":"This last week was the week of Battery Energy Storage System (BESS). Joe Weiss released a blog post titled Cyber-vulnerable battery systems are catching fire and communicate directly to China where he discusses his concerns about threat actors from the People Republic of China (PRC) remotely accessing BESS deployments in the United States. While I share the concern I am not a fan of \u0026ldquo;reading between the lines\u0026rdquo; to correlate an event with threat actor activities.\nPerhaps a better and more accurate read is the research released by Dr. Emma Stewart\u0026rsquo;s team over at Idaho National Labs. This team conducted some serious research into the effects of BESS on the North American grid and businesses leveraging battery technologies. Their research gives a comprehensive background to understand the technologies, source of minerals, and the supply chain of supporting equipment. Like Joe, the research identifies significate issues with BESS implementations with more supporting details to help organizations make better decisions. The integration of the BESS research with Ginger Wright and the rest of the team\u0026rsquo;s expertise in Cyber-Informed Engineering (CIE) helps provide an excellent example of how to use the CIE process to gather information for a Detailed Risk Assessment that should proceed any BESS acquisition efforts.\nAs you know, I am obsessed with managing access to ICS mediums. The complexity of BESS technologies and the risks of lithium fires makes the consequences for not continuously monitoring the BESS\u0026rsquo; state a critical risk. Hence, at a minimum, condition monitoring by the vendor or manufacturer is necessary to reduce this risk. The report states:\n\u0026ldquo;To facilitate the data exchange, the BESS must communicate outside the firewall of its utility or integrator connection. While many large vendors—including Tesla, Fluence, and Flexgen— operate this way, the risk is mitigated via the separation of communications and control, along with other features to isolate it from other networks. \u0026quot;\nThis means that one or more of the BESS technologies will require remote connectivity to, at a minimum, each BESS unit. The number of components, and the different equipment sources, increases the risk that each BESS unit will have some type of radio (cellular or satellite) that allows remote access. Best case is that this connectivity does not provide access to the rest of the owner/operator network. Worst case is that this connectivity, via configuration or vulnerability, provides control access to the individual BESS units which can be leveraged by threat actors. The impact of this remote access is outlined in the report considering the role BESS units have when supporting the stability of different portions of the North American electrical grid.\nI would like to thank Dr. Emma Stewart for leading this team to outlining this valuable information. I would also like to emphasize the team work required to research all of this information to provide accurate details without hyperbole or conjecture. To ensure this information remains public, I have created the INL BESS Reports GitHub repository for these reports.\nReferences # Center for Securing Digital Energy Technology - Battery \u0026amp; Energy Storage Supply CIEBAT: Cyber-Informed Engineering (CIE) Tool for Battery Energy Storage System Analysis Securing Digital Energy Infrastructure: Procurement, Contracting, and Supply Chain Risk Management Guidance Application of Cyber-Informed Engineering for Protecting BESS Battery Energy Storage Systems Report Cyber-vulnerable battery systems are catching fire and communicate directly to China Image generated using MidJourney on 20250219 ","date":"February 19, 2025","externalUrl":null,"permalink":"/blog/remote-access-to-your-bess-and-you/","section":"Blog","summary":"This last week was the week of Battery Energy Storage System (BESS). Joe Weiss released a blog post titled Cyber-vulnerable battery systems are catching fire and communicate directly to China where he discusses his concerns about threat actors from the People Republic of China (PRC) remotely accessing BESS deployments in the United States. While I share the concern I am not a fan of “reading between the lines” to correlate an event with threat actor activities.\n","title":"Remote Access To Your BESS and You","type":"blog"},{"content":"The US Treasury Department is an industrial control environment integrated with an active business environment. This organization collects taxes, pays bills for the United States, produces coins and currency (ICS controllers, field devices, servers, and applications), manages government accounts, and enforces tax and finance laws. The recent access to access that has been provided to the Department of Government Efficiency (DOGE) team equates unmoderated administrative access to this control environment. The US Treasure Department one piece of the United States\u0026rsquo; critical infrastructure.\nCommon Control Network Access Requirements # Cybersecurity professionals that conduct penetration testing and security assessments of industrial control environments, to include the United States\u0026rsquo; critical infrastructure, are required to adhere to very specific conditions before, during, and after these assessments. Let\u0026rsquo;s count the requirements that critical infrastructure and industrial control teams have imposed on me and my colleagues when performing cybersecurity assessment activities. Note that most of these occur BEFORE interacting with any network, system, application, device, or communications.\nSafety Training - always first. I bring it up because I have not seen any details about if the DOGE team was required to access the systems and networks supporting the printing and processing of coins, bills, bonds and other items that comprise US currency. If so, a safety briefing would have been required, at a minimum. Transient Cyber Assets - these are mobile computers authorized to access the control environment at any level. A few clients have allowed me to use consulting company equipment on their non-sensitive networks. Most of my ICS clients require external and internal teams to use dedicated laptops, virtual machines, and jump hosts to access the sensitive networks. The clients that are subjected to nation-state threat actors control these systems VERY closely and require digital escorts at ALL times. The swiftness of DOGE activities leads me to believe that these capabilities were not considered. Data Restrictions - data collected during assessments typically have to remain in the client\u0026rsquo;s environment. Some clients do allow reporting on consulting company equipment. Most, however, require that data remains on the client\u0026rsquo;s file shares and deliverables are processed using their equipment, software, and services. The ones that are subjected to nation-state threat actors do NOT allow data or account information to leave their control. Reports indicate unfettered access for the DOGE team members without digital escorts. I\u0026rsquo;ve seen no indications if this includes physical access to data centers or the control environments. Background Checks - background checks have been required by all of my clients. The consulting company typically handles this, but clients that are subject to nation-state threat actors require their own background service check. Several articles have reported significant issues with the backgrounds of several DOGE team members. System and Account Changes - I have made small and monitored changes to ICS lab environments during penetration testing. I have NEVER asked or been authorized to make a change to a system, service, or account on ANY production system, business or ICS. To do so would have resulted in termination of the assessment and legal action. I would imagine that this activity would affect me personally as it would be viewed as malicious and I would be held to civil and criminal consequences. Reports indicate that administrators have been locked out of systems. There is no indication if this happed at the system level, application level, or both. Some portions of the report seem to indicate that other system changes may have been made. Coordination with Stakeholders - ICS clients requirement an understanding of all actions to be performed in the test and production environment prior to coming onsite. The actions are reviewed, restrictions and limitations are provided, the stakeholders discuss the risks, and then all the teams modify the plan to ensure safety to personnel and operations. Unfettered and unmonitored access is never provided. Administrators, or responsible stakeholders, review the functionality and integrity of the system or device if they feel there is an issue. The swiftness and details in reports indicates that the DOGE team members did not coordinate their activities. The Right Way Vs The Wrong Way # While systems do require audits and assessments there is a right way and a wrong way to do it. I am surprised that the DOGE team has no restrictions in these control and business environments. It goes against common practices and international standards, as outlined in ISA/IEC 62443, the DHS Sensitive Systems Policy Directive 4300A, and the DHS Handbook for Safeguarding Sensitive PII. My knowledge about the financial sector is limited but perhaps there are additional guidelines and requirements provided by the Financial Services - Information Sharing and Analysis Center (FS-ISAC) and the Financial Services Sector Coordinating Council (FSSCC) (\u0026ldquo;an industry-led, non-profit organization that coordinates critical infrastructure and homeland security activities within the financial services industry\u0026rdquo;).\nBrian Kreb\u0026rsquo;s article Teen on Musk’s DOGE Team Graduated from ‘The Com’ and Wired article A US Treasury Threat Intelligence Analysis Designates DOGE Staff as ‘Insider Threat’ have pointed out two, at the moment, individuals on the DOGE team that would not be allowed to conduct an assessment of ICS environments, including but not limited to critical infrastructure. The swiftness and lack of coordination with stakeholders would have prevented the beginning of the assessment. And the changing of systems and accounts, if true, would have ended the assessment all together and required a full check of integrity and operability. With the criminal and personal background of the current DOGE team in question, additional actions would be required, since they access the control and business environments.\nCall to Action # Considering these issues within a part of the United States\u0026rsquo; critical infrastructure, the integrity of the US. Treasury business and control environments need to be assessed before returning to production. Non-DOGE teams should analyze system and application access events, system and application configurations, and perform a physical review of all networks, data centers, and control environments. A review of external network communications should be conducted to determine if any data was exfiltrated from the environment (although this will not detect if the team exfiltrated data using cellular modems). Network traffic needs to be monitored very closely to determine if any rogue devices, services, or malware have been installed to maintain remote access to these business or control networks. While this may be expensive, it is the reality. These checks are required to ensure the integrity, reliability, availability, and safety of these process and business environments.\nIt is my hopes that the Secretary of Treasury Scott Bessent and my congressional representation (Congressman Michael Cloud of the U.S. House of Representatives , U.S. Senator Ted Cruz , and U.S. Senator John Cornyn) review this situation and take appropriate action. The DOGE team needs to be updated with personnel that meet basic background, skills, and a security clearance checks. The scope of work should be limited to information gathering about metrics necessary for the audit / assessment. Access should require physical and digital escorting by administrative personnel with the appropriate knowledge of the system and the audit\u0026rsquo;s information gathering techniques. All data should remain on U.S. Treasury systems and not leave the premises. Their Sphere of Influence is protecting these environments for the citizens of the United States.\nHonestly, if we restrict access to our critical infrastructure, such as electrical and water, and impose basic limitations for cybersecurity professionals then shouldn\u0026rsquo;t we do the same to the systems that are used to protect the finances of the United States and it\u0026rsquo;s citizenry? If this situation concerns you, please forward this onto your congressional representatives.\nLearn More About Assessing Critical Infrastructure # The SANS ICS authors and instructors discuss these in the SANS Institute course ICS410 ICS/SCADA Security Essentials and we will be teaching them in the ICS613 ICS Penetration Testing and Assessments when it goes live later this year.\nGo forth and do good things,\nDon C. Weber\nImage Source: Generated using MidJourney on February 8, 2025\n","date":"February 8, 2025","externalUrl":null,"permalink":"/blog/unrestricted-access-to-your-critical-infrastructure-the-u-s-treasury/","section":"Blog","summary":"The US Treasury Department is an industrial control environment integrated with an active business environment. This organization collects taxes, pays bills for the United States, produces coins and currency (ICS controllers, field devices, servers, and applications), manages government accounts, and enforces tax and finance laws. The recent access to access that has been provided to the Department of Government Efficiency (DOGE) team equates unmoderated administrative access to this control environment. The US Treasure Department one piece of the United States’ critical infrastructure.\n","title":"Unrestricted Access to Your Critical Infrastructure - The U.S. Treasury","type":"blog"},{"content":"Today I had to remind myself to tell a team leader about an IT cybersecurity team member that provides superior security assessment work for a utility client. The IACS and OT industry likes to say that IT administrators and cybersecurity professionals cannot provide good guidance or do active assessments safely in production environments. This individual\u0026rsquo;s contributions to the vulnerability assessment of complex production and test environments continues to be invaluable and has helped to improve the design and deployment of solutions affecting millions of people supported by the utility.\nHere is a snippet of the kudos I outlined about this individual. He was and is \u0026ldquo;always upbeat, professional, technical, fscking devious, careful, and accepting of direction. His background, and interests, are not related to IACS / OT technologies or solutions. But he participated on the IACS / OT assessment team and used his skills effectively.\u0026rdquo;\nLet\u0026rsquo;s break each of these down since I feel these key traits are critical for each team member working on production networks.\nKey Traits # Upbeat - working in ICAS/OT environments can be intimidating, particularly when some things are out-of-scope or fragile. He asked clarifying questions but never let himself get so frustrated that he could not focus, add value, or be safe.\nProfessional - hackers will be hackers, and there is a need for standards that let them flourish. But, IACS/OT environments have operational standards that include dress, safety, and technical actions. He always dressed to the location standards and respected limitations from the client, as imposed. He pushed on some technical requirements with clarifying, and challenging questions, but accepted with answers and even statements like \u0026lsquo;we have to do it this way.\u0026rsquo;\nTechnical - going in, he outlined that he did not have experience with utility communication protocols, vendor solutions, or even electricity. As the assessment was scoped and conducted, he focused on the technologies he was familiar with and reviewed their implementation. His security assessment skills involving Windows operating system, database configuration, web application implementations, and Kubernetes deployments were things required within the vendor\u0026rsquo;s solution but the owner / operator\u0026rsquo;s OT admin and OT cybersecurity team did not have skills.\nFscking Devious - Using his non-OT skills, he found issues with operating system configurations, credential and data leaks in application files, exposed encryption certificates that allowed unauthorized authenticated access to production data, wrote Windows executables that the vendors software executed via a scheduled task with SYSTEM level privileges, and more. His skills identified gaps where the vendor told the client \u0026lsquo;yes, we did that\u0026rsquo; but in actuality they had not achieved the cybersecurity requirements for the project as outlined by the owner / operator during selection of the solution. Most of the time people were amazed at how easily the issue was identified and taken advantage of.\nCareful - when he first started working on this client\u0026rsquo;s projects his approach followed normal IT security assessments: \u0026lsquo;go anywhere - get everything, that is within scope\u0026rsquo;. He accepted the initial guidance to \u0026lsquo;ask before you do\u0026rsquo; and \u0026lsquo;be careful with production data\u0026rsquo;. He realized being careful was an operational requirement and he defaulted to this approach for all his devious thoughts. Asking permission before doing.\nAccepting Direction - already explained, but I have seen plenty of cybersecurity professionals decide to do things anyways because \u0026lsquo;I know the client / vendor should account for this, and I am going to show them. Then they will understand.\u0026quot; This attitude breaks testing and production environments. In the worst case it can lead to safety issues. Accepting limitations and scope is a valuable, and required, skill in IACS / OT cybersecurity assessments.\nConclusion # The point I am trying to make here is that the IACS / OT side have a lot of challenges deploying and maintaining production environments. They are experts with production technologies and even may understand cybersecurity principles. However, they are not cybersecurity experts, nor do they have IT administrative experience defending against swift vulnerability exploitation. But the choices owners / operators are making and, more challenging, the choices that vendors and integrators are making, generate easy to exploit situations with real consequences. The identification of these issues, which leads to the prevention and detection of exploitation, can be improved by using skills from team members with limited and even no IACS / OT experience. Identifying team members with the right mentality and maturity can be more important than requiring years of OT implementation experience. Cause, do you / we really have time to wait for that?\nGo forth and do good things,\nDon C. Weber\nImage Source: Generated with Midjourney, 20250117\n","date":"January 17, 2025","externalUrl":null,"permalink":"/blog/accelerating-iacs-ot-cybersecurity-improvements/","section":"Blog","summary":"Today I had to remind myself to tell a team leader about an IT cybersecurity team member that provides superior security assessment work for a utility client. The IACS and OT industry likes to say that IT administrators and cybersecurity professionals cannot provide good guidance or do active assessments safely in production environments. This individual’s contributions to the vulnerability assessment of complex production and test environments continues to be invaluable and has helped to improve the design and deployment of solutions affecting millions of people supported by the utility.\n","title":"Accelerating IACS / OT Cybersecurity Improvements","type":"blog"},{"content":"In his recent article, titled Critical infrastructures cannot be secured because network security and engineering won’t work together, Joe Weiss has provided the IACS cybersecurity industry with an example of hyperbole and fear mongering what needs to be stamped out rather than perpetuated. The advancement and maturity of this field will not evolve effectively when build on, or supported by, this biased and bigoted vernacular. It is difficult to call out all the issues in his meandering post. So, I will focus on three important topics where he needs to take a hard look at his beliefs and the approach he is bringing to the security and safety of industrial and automation control environments.\nHyperbole Click-bait Article Title # The title of his post indicates that experts providing administration for corporate and control environment infrastructures will not work together, thus breeding insecurity. He is accurate in his depiction that there are challenges integrating administrators more familiar with corporate and internet service-based requirements than operational requirements, specifically at the process levels. This lack of familiarity has traditionally forced operational personnel and vendor / integrator teams to deploy supporting IT technologies (e.g. Windows / Linux systems, Active Directory, web / database applications, network devices) within the control environments, from Level 3 down to the process levels. This situation was acceptable prior to the integration / connection of the OT environments to the corporate network and the internet using Ethernet field bus technologies. This integration was done to improve monitoring and control which improved operations and safety while also advancing interactions with corporate business units.\nIn my experience, the real issue for this topic is the OT personnel, to include vendors / integrators, not accepting expert input from the IT administrative teams. The original basis was because the IT administrators did not understand operational requirements and their normal administrative practices and configurations broke the OT environments. The operating term there is \u0026lsquo;operational requirements\u0026rsquo;. The root cause of this issue is that the IT administrators are not being provided with the control technologies operational requirements. If you let someone loose without guidance or direction they will fall back to the techniques with which they are most familiar. However, if you provide them with guidance, restrictions, and parameters and follow up with them they will very often meet and exceed the goals. From the vendor / integrator perspective, the owner / operation is not providing them direction to work with these IT administrators when designing and deploying these technologies. In other words, the vendors / integrators need your cybersecurity requirements in addition to operational requirements for these technologies. The latter of which you already provide - so start including them.\nLook, the OT environment, particularly at Level 3, is deployed using network, server, and application technologies that are similar to the corporate environment. Threat actors use their skills and tools from the corporate environment to great success on the Level 3 assets. Your OT administrators have limited, if any, experience in defending against these tactics and techniques. Your IT administrators do have this experience. So, isn\u0026rsquo;t it more cost effective to select some of the IT administrators and teach them about operational requirements than it is to start training your OT administrators and wait for them to gain this experience over time? While also tasking those OT administrators with operational duties that take precedence over cybersecurity efforts. Start integrating your administrative teams, allow them to develop simple methods for implementation and auditing, and remove the \u0026lsquo;cannot\u0026rsquo; from your OT culture. Let them learn from and with each other.\nVulnerabilities of Field Devices # As a security researcher, I have a passion for ensuring the devices controlling the physical world are understood and protected. All my education involving hardware hacking, protocol analysis, attack surface exploitation, and input validation has helped me understand the consequences of allowing a threat actor physical and digital access to the process environment. I share Joe\u0026rsquo;s expectation that unnecessary applications, the attack surface, are reduced as much as possible to limit the functionality that can be used or exploited by threat actors. However, my research and knowledge acquired through years of security research, security assessments, and penetration testing helps me understand that these features cannot be exploited without physical or digital access to the device or field bus (yes, I consider Ethernet a field bus network, it just allows networks to be joined together). Physical or digital access are REQUIREMENTS for exploitation of vulnerabilities or features. When teaching I refer to this as understanding the medium, determining the adapter required to interact with the medium, and using protocols to communicate across the mediums to applications.\nVendors provide additional features in their products because they do not know how the solution will be deployed. Each situation is unique. More features means the product is more useful and is more cost effective to produce and makes it cheaper overall. Each device will have a standard implementation guide that outlines these capabilities to ensure operational requirements can be used across all their clients in a variety of different industries. So, yes, it is the owner / operator\u0026rsquo;s responsibility to understand the technologies that comprise the solutions they are purchasing / building so that a team can outline risk reduction techniques to prevent and detect unauthorized physical and digital access to devices and field buses. These capabilities can be your friend, if you understand them and manage them appropriately (like all friends). Should vendors have better hardening guides? Of course. But, again, they do not know every use case for their device, so any hardening / configuration guide is merely the starting point for the owner / operator.\nLook, if you understand the technologies and the vulnerabilities you are in a great place. This knowledge allows your team to prevent the use / exploitation of these applications using risk reduction techniques: terminate, tolerate, treat, and transfer. If you understand the medium and communication protocol then you know what an exploit looks like. With this knowledge you can monitor for this type of behavior and anything that identifies unauthorized, suspicious, and malicious activity. But you need to remember, if you start looking you will start finding. Your combined IT and OT team had better know how to respond. Hence, all this knowledge and experience should all feed into your operational requirements.\nConclusion (yes, this is my third issue) # The strongest part of Joe\u0026rsquo;s article can be found in part of his conclusion statement. Yes, organizations need to start forcing their OT and IT teams to coordinate and we need to improve the education of people in a variety of technical domains. Unfortunately, these thoughts are not supported very well by the rest of his article nor the inclusion of the sentence containing the statement \u0026ldquo;inappropriate advice being dispensed by \u0026lsquo;OT cybersecurity experts\u0026rsquo; who don’t understand control system field devices.\u0026rdquo; This dogmatic statement is maliciously speculative with the intent to bolster his own personal worth. It would be no big deal if he did not have an audience that respected his previous contributions to the field and who allow his \u0026ldquo;old school\u0026rdquo; (borderline “good ol’ boy”) biases try to drive the industry.\nLook, we do not have time for infighting, shenanigans, and personal vendettas. Adults need to start working as teams. The best, and more secure, environments that I have encountered have the OT administrators checking with and accepting help from the IT and cybersecurity administrators. They set and communicate operational requirements, employ the cybersecurity requirements where possible, and evaluate and prioritize next steps. Every one of the \u0026lsquo;OT cybersecurity experts\u0026rsquo; I know, which Joe knows and refers to, are presenting the approach I have outlined here. They are achieving success in securing industries and critical infrastructure around the world. THIS is why we CAN secure our OT and process environments. This approach is much more effective and affordable than wagging a finger and disrespecting educated, experienced, and dedicated professionals.\nGo forth and do good things,\nDon C. Weber\nReferences: # Critical infrastructures cannot be secured because network security and engineering won’t work together\nJoe Weiss Linked In Post\nImage Source: AI generated on MidJourney on January 10, 2025\n","date":"January 10, 2025","externalUrl":null,"permalink":"/blog/finger-wagging-and-disrespecting-professionals-will-not-secure-critical-infrastructure/","section":"Blog","summary":"In his recent article, titled Critical infrastructures cannot be secured because network security and engineering won’t work together, Joe Weiss has provided the IACS cybersecurity industry with an example of hyperbole and fear mongering what needs to be stamped out rather than perpetuated. The advancement and maturity of this field will not evolve effectively when build on, or supported by, this biased and bigoted vernacular. It is difficult to call out all the issues in his meandering post. So, I will focus on three important topics where he needs to take a hard look at his beliefs and the approach he is bringing to the security and safety of industrial and automation control environments.\n","title":"Finger Wagging and Disrespecting Professionals Will Not Secure Critical Infrastructure","type":"blog"},{"content":"Originally posted at Claroty NexusConnect on May 9, 2024\nThe Cybersecurity Safety Challenge # I started thinking about the safety issues for security assessments when I was asked to attend a conference for amusement rides and parks. Safety has always been paramount in this industry and their teams are working hard to understand and improve how cybersecurity fits into the phases of a ride\u0026rsquo;s lifecycle.\nUnsafe conditions in this industry imperil park and ride visitors in the same manner as safety issues impact workers or public safety in other industrial sectors. However, the nature of ride development, deployment, maintenance, operations, and overall ownership has made cybersecurity in this industry an intricate dance between owners/operators, integrators, and vendors—even more than in other industrial sectors.\nMy personal experience with process safety equipment is limited to the review of an isolated Safety Instrumented System (SIS) that is the central component of a dual-process cabinet configured to manage two jet-turbine-powered compressors. The SIS devices were deployed in the central part of the cabinet and manual inspection of the wiring confirmed there was no ethernet network connectivity. This configuration is what would be expected by many IT and cybersecurity experts not familiar with safety equipment directly integrated into process operations—including myself. My personal lack of experience with safety equipment highlighted to me that other cybersecurity team members may not have this experience either. This, in turn, makes me extremely concerned that the process stakeholders will default to leaving these systems and devices out of scope for vulnerability assessments.\nThe industry (e.g. OT, IT, and cybersecurity) needs to understand that safety devices are indeed within scope for cybersecurity risk assessments. This includes conducting high-level risk assessments to assemble documentation for specific Systems-under-Consideration (SuC) of the safety solution, performing a vulnerability assessment of the SuC, feeding the results into the detailed risk assessment to allow the risk management team to identify and address residual risks. Most of the time these assessments will be conducted on air-gapped zones with their own individual evaluation that does not include the process the safety solution is protecting. Integrated safety solutions will make the vulnerability assessment a bit more complex to address the increased complexity brought by the safety considerations.\nStarting the Architecture Conversation # Considerations for SuC that contain integrated safety devices or are safety zones are detailed in different international standards. I tend to focus on the ISA/IEC 62443 for its general approach that can be used in most industrial sectors. Considerations for safety-related equipment are outlined specifically in the ISA Technical Report (TR) 84.00.09, Cybersecurity Related to the Functional Safety Lifecycle which was approved April 10, 2017. This TR outlines specific details for cybersecurity vulnerability assessments in these areas. This input was leveraged in an excellent book titled \u0026ldquo;Managing Cybersecurity in the Process Industries: A Risk-based Approach\u0026rdquo; by the Center for Chemical Process Safety.\nThe cybersecurity assessments outlined by these references follow the normal ISA/IEC 62443 risk assessment methodology. The use of standard Reference Models and Reference Architectures should be used to start defining the roles of equipment and communications while also detailing their specific deployments on the appropriate communications mediums. These techniques allow the designation of the SuC and the associated zones and conduits. ISA/IEC 62443-3-2 provides specific details about this documentation in section ZCR 3.3: Separate Safety-Related Assets. This section specifies the need to ensure safety and related assets are isolated from other assets in the SuC to ensure the segregation of safety and operations related assets.\nISA TR 84.00.09 provides additional guidance for the cyber security assessments (CSA) of safety zones and conduits. The document details that two primary concerns drive cybersecurity safety considerations. The first concern is about a safety function\u0026rsquo;s failure-to-perform when needed. The second concern is spurious operations that cause unauthorized activation, cause business interruption, or damage equipment. Hence, to evaluate cybersecurity risks for process safety, a series of CSA must be scheduled and performed throughout the lifecycle of the process. The TR specifically designates the different stages of the SuC from development through decommissioning.\nStarting the Assessment Conversation # As with all CSA, the evaluation of a safety-related SuC starts with conducting the high-level risk assessment. This process, also known as the gap assessment, involves gathering all the information necessary to scope, identify stakeholders, gather hardware and software asset details, and other risk assessment documentation. The goal of the gap assessment is to provide the risk assessment team with the information required to determine the state of the seven foundational requirements for the SuC. The risk assessment team uses this information to determine the SuC\u0026rsquo;s current security level associated with the intended and known capabilities of the process.\nA CSA should be used to evaluate the implementation of the SuC to validate the information obtained during the gap assessment while also reviewing the SuC for unanticipated conditions. While the risk assessment team will eventually want answers about the seven foundational requirements for each device and its communications, a faster and more manageable approach to the assessment could be achieved by considering the SANS ICS Five Critical Controls for ICS Cybersecurity. This approach focuses on the current state of the SuC by reviewing secure remote access, defensible architecture, ICS network visibility monitoring, risk-based vulnerability management, and ICS incident response.\nThe CSA process is too complicated to completely outline in this article, but here are some considerations for each. Consider each of the following in the context of the safety devices in the SuC.\nSecure Remote Access: Determine who can access the safety devices and communications, and how. Be sure to consider third-party vendors / integrators / consultants, employees, and any cloud-based assets. Defensible Architecture: Review the technical implementation of the SuC by analyzing network segmentation and isolation, the attack surface of each device, and the configuration of all communications. Risk-Based Vulnerability Management: Confirm the documentation of hardware and software asset inventory, review configuration management documentation and compare to remote access, and consider the list of CISA KEVs as applied to devices and communications within the SuC. ICS Network Monitoring: Evaluate logging configurations, centralization of logs, log analysis and alerting, and determine if countermeasure efficacy testing can be implemented to validate alerting and responses. ICS Incident Response: Verbally review consequence-analysis scenarios and use cases to ensure your team understands the realization of exploited vulnerabilities related to the SuC. Takeaways # Understanding cybersecurity risks to safety-related ICS devices and processes is ultimately the responsibility of the owner/operator. Implementation and operations of these specialized assets by vendors and integrators can result in a gray area that results in unsafe operations. I feel the Center for Chemical Process Safety outlined this situation appropriately when it described cybersecurity\u0026rsquo;s affect on safety equipment.\n\u0026ldquo;… cybersecurity driven common cause failures have the potential to occur even more frequently, because they are the result of an intentional action taken by an attacker.\u0026rdquo;\nTeams must be proactive and prioritize the CSA of safety-related systems. Initial analysis using the SANS ICS Five Critical Controls can be used to effectively gather enough detail for an ISA/IEC 62443 detailed risk assessment of the process. The risk assessment team can use this information to identify systemic issues while also generating effective countermeasures to address gaps in SuC\u0026rsquo;s deployment and operations. These details will also provide process stakeholders with the information needed to implement specific operational updates to address and critical issues that could lead to the realization of safety-related consequences in the process.\nDon C. Weber\nGo forth and do good things.\n","date":"May 18, 2024","externalUrl":null,"permalink":"/blog/architecting-safety-using-cybersecurity-requirements-and-assessments/","section":"Blog","summary":"Originally posted at Claroty NexusConnect on May 9, 2024\nThe Cybersecurity Safety Challenge # I started thinking about the safety issues for security assessments when I was asked to attend a conference for amusement rides and parks. Safety has always been paramount in this industry and their teams are working hard to understand and improve how cybersecurity fits into the phases of a ride’s lifecycle.\n","title":"Architecting Safety Using Cybersecurity Requirements and Assessments","type":"blog"},{"content":"","date":"May 18, 2024","externalUrl":null,"permalink":"/tags/ics/","section":"Tags","summary":"","title":"ICS","type":"tags"},{"content":"","date":"May 18, 2024","externalUrl":null,"permalink":"/tags/ics-security/","section":"Tags","summary":"","title":"ICS Security","type":"tags"},{"content":"","date":"May 18, 2024","externalUrl":null,"permalink":"/tags/icscybersecurity/","section":"Tags","summary":"","title":"Icscybersecurity","type":"tags"},{"content":"","date":"May 18, 2024","externalUrl":null,"permalink":"/tags/industrialcybersecurity/","section":"Tags","summary":"","title":"Industrialcybersecurity","type":"tags"},{"content":"","date":"May 18, 2024","externalUrl":null,"permalink":"/tags/otcybersecurity/","section":"Tags","summary":"","title":"Otcybersecurity","type":"tags"},{"content":"","date":"May 18, 2024","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"Recently, I have noticed people emphasizing the name of certifications and personally attacking the people who obtain them. This is unfortunate as it is shining light on the wrong subject. The value of a certification is not in the name. The value of the certification is that it is an indication that an individual has received a level of instruction and demonstrated the ability to retain, reference, and recall that information. It is this foundation of knowledge that the individual can be held accountable for using during decision making.\nThe purpose of certifications is to provide a level of instruction that exposes the student to new concepts. Typically, the concepts are a collection of details about individual data points that combine into a specific domain. Some education is designed to initiate individuals into concepts the student has not been exposed to or that require a new way of considering the concept\u0026rsquo;s implementation. Other educational experiences expose the student to the actual implementation of these concepts. Most students benefit more by receiving the former before the latter. In the case of industrial and automation concepts this is extremely important as the implementation of technologies within control environments has a combination of new technologies and known technologies that are implemented with a different purpose.\nIt is widely known that I am an instructor for the SANS-ICS ICS410: ICS/SCADA Security Essentials class. The name of the GIAC certification for this course, which I personally certify every four years, is the Global Industrial Cyber Security Professional (GICSP). I have also, recently, taken the courses and received a certification in the ISA/IEC 62443 program and received the ISASecure certification named ISA/IEC 62443 Cybersecurity Expert certification. My knowledge from both experiences demonstrates that none of the teams involved with teaching and supporting these efforts care one bit about the name of the certification. They understand that it is the distribution of the information in a manner that can be applied by the individual receiving the training, regardless of them obtaining the certification. The intent is to make the world a safer place through this education and allow them to succeed in their career efforts.\nThere is a lot to argue about any education, from content to cost. Personally, I am proud to be a part of both programs. I have found that I can apply information from both in the application of my skills and my interactions with people that are new OR experienced in this field. I have never, in any professional or education interactions, portrayed my role as more or less than I am bringing to the table as an information security professional with experience helping engineers, operators, vendors, and integrators secure their process environments. I have expressed this to my students, people attending my talks, clients, partners, and during discussions on these topics. The people I choose to surround myself with are people who manage themselves in a similar manner.\nThe belittling behavior of people experienced in the implementation of industrial and automation environments is not a new experience. For the past ten years it has been referred to by the name \u0026lsquo;gatekeeping.\u0026rsquo; The misguided initial intent for this behavior was tied to safety. The concept was that people with no experience in industrial and control environments will, through their actions and recommendations, create a safety issue that is more likely to be realized. Only people with experience in these fields can properly deploy technologies to support the process while also ensuring the safety of people, the environment, and the process. Ten years ago, I could understand this argument even when I was being thrust, by my own choice, into this fray.\nOver the past ten years I, along with you, have seen connectivity into the industrial and control environments grow. In the past ten years I have seen professionals from various industrial and automation sectors deploy technologies with limited knowledge of the actual technology. Let’s use a simple example from an organization with a very experienced Windows Domain administration team. A new control environment was being stood up by the engineering team with the assistance of an experienced integrator team. They deployed all the technologies, ensured that all the process flows worked, and then asked our team to evaluate the solutions for any security-related gaps. Our analysis determined that everything, and I mean everything, had been deployed and was running as Domain Administrator. All user accounts - Domain Administrator. All service accounts - Domain Administrator. All applications - Domain Administrator. When we asked them about it their response was \u0026ldquo;when we go live next week, we will change everything to the correct user.\u0026rdquo; While this is just one situation, my experiences in industrial and automation environments are that engineers, operators, vendors, and integrators will not accept the help from individuals or teams that understand these technologies better than they do. Not realizing that, by not accepting this help, they are creating situations that will have a negative impact on safety.\nOf course, some people will argue the fact that I am not talking about the actual process. They will argue that processes are built to be resilient to unexpected and unsafe situations and inputs. They will argue that I am proving their point and that I, as an information security professional with ten years of experience securing control environments, should not be allowed anywhere near a process. To that point I would argue that these individuals have shallow experiences. They are pulling their flimsy and ineffective arguments tighter around themselves because they are scared that they are not the most important and knowledgeable person. I would argue that the processes can be impacted by these situations in a manner that is difficult to predict but can lead to losses or denial of view, control, and safety. ISA/IEC 62443 requires that ALL technologies are reviewed for this impact on the process and that they are configured (hardened) appropriately according to their Security Target Level (SL-T). This includes supporting technologies as well as the configuration, deployment, and programming of process level devices. To do this ISA/IEC 62443 recommends a TEAM of stakeholders with the appropriate skill levels to understand the technologies. Some team members will come from the operations side but the team should also includes individuals with experience from the information technology and information security teams.\nAs I mentioned, remote connectivity into industrial and automation control environment is expanding rapidly. We cannot continue denying that these environments require an infusion of talent of information technology and information security professionals. These new skills are needed to allow the personnel experienced with the implementation of industrial and automation technologies to do their jobs deploying operationally sound and safe processes. We cannot expect people to know everything. We can expect that individuals will operate as adults within a team of experts in their chosen fields. To this end, all individuals need training in initial and in-depth concepts. To use a saying I\u0026rsquo;ve been hearing a lot lately, \u0026ldquo;This is a marathon, not a sprint.\u0026rdquo; But if people keep locking the gate nobody can run the marathon or the sprint.\nGo forth and do good things,\nDon C. Weber (cutaway)\n","date":"September 8, 2023","externalUrl":null,"permalink":"/blog/bashing-education-and-certifications-reduces-safety-of-industrial-and-automation-control-environments/","section":"Blog","summary":"Recently, I have noticed people emphasizing the name of certifications and personally attacking the people who obtain them. This is unfortunate as it is shining light on the wrong subject. The value of a certification is not in the name. The value of the certification is that it is an indication that an individual has received a level of instruction and demonstrated the ability to retain, reference, and recall that information. It is this foundation of knowledge that the individual can be held accountable for using during decision making.\n","title":"Bashing Education and Certifications Reduces Safety of Industrial and Automation Control Environments","type":"blog"},{"content":"Originally posted on the Claroty NexusConnect Blog.\nThe advancement of remote access technologies, machine learning, and artificial intelligence solutions is moving the industrial and automation industry toward cloud technologies faster and faster.\nSome current examples of automation AI/ML platforms include:\nABB Ability Genix Industrial Analytics and AI Suite, Siemens Machine Learning Platforms Schneider Electric AI Hub Some examples of cloud-based industrial and automation solutions include:\nGE Digital\u0026rsquo;s Proficy Smart Factory MES Phoenix Contact\u0026rsquo;s Cloud computing Inductive Automation\u0026rsquo;s Ignition Cloud Edition Organizations that are not prepared to understand these solutions are going to rely exclusively on their vendor and integrator teams to design, deploy, and maintain them. These solutions typically address security concerns in their deployment documentation. However, the ISA-62443 series of standards specifies that the owner/operator is responsible for the risks incurred by each of these solutions. These respective responsibilities are important to grasp and document.\nTo address these challenges each owner/operator requires a new set of skills. These skills start with personnel that understand cloud technologies. Unfortunately, the industry has a history of accepting new technologies and using their current personnel to implement them. The trust placed in vendors and integrators is not unfounded. But these vendor/integrator teams will implement the technologies following the requirements outlined by the owner/operator\u0026rsquo;s project team. To do this correctly the appropriate stakeholders need to be identified and tasked. This is required to ensure business continuity, reliability, and safety of the solution.\nTo understand these risks, we should review some of the cloud service challenges companies have experienced. The following is a list of compromised cloud credentials and exploited services that have impacted corporate and industrial organizations. These incidents have leaked data and negatively impacted operations.\nIn March 2021 a hacker accessed the online platform of Verkada Inc., a cloud-based physical security platform. The threat actor accessed client customer data, video/image data, account credentials, and client site WiFi credentials. This compromise occurred because of an issue with an exposed customer support server. This breach is an example of how the management of a cloud service can have consequences across multiple clients and the solution’s online services and onsite resources. In July 2019 a company terminated an employee, but failed to disable their access to their AWS environment. After being fired, the terminated employee used their administrative credentials to retaliate. The former employee used their credentials to turn off all the company\u0026rsquo;s cloud services, then changed the email address and password for the root account of the AWS subscription. AWS was initially unable to recover the services. Fortunately, the former employee provided the new credentials and the services were restored. Had the employee selected a random password without saving it, the results would have been completely different. On May 11, 2023 CISA released an ICS Advisory for multiple vulnerabilities in the Siemens SIMATIC Cloud Connect 7 solution. This product is an industrial Internet-of-Things (IoT) gateway that provides owners/operators with the ability to connect their control environments with a wide variety of cloud platforms. The advisory describes device vulnerabilities that include hard-coded passwords, denial-of-service, and exposure of sensitive information vulnerabilities. The severity of these vulnerabilities earned them a CVSSv3.0 score of 7.2. Understanding these and similar implementation risks is required when adding cloud services to an organization\u0026rsquo;s Cyber Security Management System (CSMS) program. Cloud-based risk management requires updating policies and procedures, assignment of organization responsibilities, planning and implementation of awareness training, and selection of countermeasures to be implemented by the owner / operator.\nAccording to ISA/IEC 62443, the CSMS risk assessment process starts with an initial high-level risk assessment, also referred to as a gap assessment. The gap assessment requires gathering information about the cloud service, some of which must be provided by the product/service provider and the rest will be gathered by the project stakeholders.\nHere is a breakdown of responsibilities for providing information for the gap assessment. Overall, the owner/operator is responsible for ensuring all the information collected is complete. The owner/operator’s project owner should review the data and ask clarifying questions until each section is completed. Stakeholders for this project include:\nProject Overview – Owner / Operator Cloud Service Description – Product / Service Provider Product / Service Foundational Requirements – Product / Service Provider Zone and Conduit Characteristics – Owner / Operator These stakeholders will outline the full details about the project to include the cloud services and resources. The high-level data collected includes a description of the project, timelines and milestones, team leaders and administrators, and a list of components. Details about the cloud environments include identification of the cloud service providers, type and model of services, regions assets will be deployed, container services selected, and known countermeasures. The team will also have to identify regulatory requirements along with the capability and target security levels of the solution.\nWhile it may seem like a lot of details, this list is just the starting point to completely understand the cloud-based solution. The vendor/integrator providing the solution needs to include additional details about how their cloud services and accounts are managed. This includes access management, roles and responsibilities, data flow, and other information to help understand the maturity of the solution. This task can seem daunting and there are a lot of details that can get lost in the mix. Thus, the project team needs to organize these efforts and there should be preparation before starting the task.\nTo aid in conducting a gap assessment for a cloud project the CloudSec-IACS project was started by the Cutaway Security team. This project provides a template that can be used to designate stakeholders and guide them through the information collection process.\nThe template provides a list of topics the team should collect to fully understand the solution and conduct a full gap assessment. Once completed, the gap assessment can be used to select the appropriate solution and countermeasures while providing the appropriate implementation requirements to vendors / integrators. Hopefully this helps your team secure your new cloud-based solutions.\nIf you have suggestions to improve the CloudSec-IACS project, please add an issue to the Github project.\nGo forth and do good things,\nDon C. Weber\n","date":"August 23, 2023","externalUrl":null,"permalink":"/blog/conducting-gap-assessments-to-secure-control-environments-cloud-based-solutions/","section":"Blog","summary":"Originally posted on the Claroty NexusConnect Blog.\nThe advancement of remote access technologies, machine learning, and artificial intelligence solutions is moving the industrial and automation industry toward cloud technologies faster and faster.\n","title":"Conducting Gap Assessments to Secure Control Environments’ Cloud-based Solutions","type":"blog"},{"content":"In February 2023 I was attending a conference for safety. I was introduced to many new people with roles that involved safe implementation of processes, equipment, and manual procedures that support the entertainment and safety of people all around the world. During one of my conversations, I was told that people purchasing services from large industrial control and automation vendors are not asking for people that have achieved the GIAC GICSP certification. They are specifically asking for people that have achieved the ISA/IEC 62443 Cybersecurity certifications. That was the moment I decided I was going to achieve the ISA/IEC 62443 Cybersecurity Expert certification before the end of 2023.\nMy journey started simple enough. I logged into my ISA account and signed up for the ISA/IEC 62443 Cybersecurity Fundamentals Specialist. The program allows students three methods to study: in person, online, or self-paced training. Due to my schedule and timeline goal I decided to take the self-paced training. This means that I would miss out on the valuable instructor influence and experiences which I do regret. A fair tradeoff since I have some experience in cybersecurity of industrial and automation control systems (IACS) but I do value others experiences since there are some many diverse sectors in this field. NOTE: As I am a member of ISA I did save approximately $1600 for all certifications attempts, so my membership did pay for itself.\nOnce I started taking the ICS/IEC 62443 Cybersecurity Fundamentals Specialist class I knew this process was the right decision. As a certified SANS instructor teaching the ICS410: ICS/SCADA Security Essentials class I have a lot of experience in the security of IACS. What I do not (did not) have a lot of experience in was the actual contents of the ISA/IEC 62443 series of standards. During the self-paced course, I learned about how these standards outline the Cyber Security Management Systems (CSMS) which is the equivalent of a cyber security program for the IACS environment. I learned about the concepts of Zones, Conduits, Security Levels, and other IACS concepts. It provided me an appreciation of the standard and the hard work that the standard committees have put into its development.\nAfter achieving the ISA/IEC 62443 Cybersecurity Fundamentals Specialist certification I had a choice of the next three certifications on my way to expert. Because my role in cybersecurity is related to assessments, I decided to take the ISA/IEC 62443 Cybersecurity Risk Assessment Specialist certification next. Again, I was pleasantly surprised by the content. This class outlined how to do a risk assessment to identify and prioritize efforts as a part of the CSMS. I realized that I have been thinking about my typical role incorrectly. When I help organizations review their environments, I thought I was doing a risk assessment. In fact, according to the standard, I was conducting a vulnerability assessment. The results of the vulnerability assessment feed valuable information into the risk assessment, but the leadership of the organization I am working for needs to evaluate that information, determine where they want to be (as in Target Security Levels), the consequences of the vulnerabilities identified, and document the unmitigated risk. All of which will ultimately identify how they will manage the risk through the different risk reduction techniques.\nWith my ISA/IEC 62443 Cybersecurity Risk Assessment Specialist certification in hand I tackled the final two certifications in order: Design Specialist and Maintenance Specialist. I am combining these certifications as these two were a bit repetitive to me. These certifications are specifically designed for individuals that are going to fulfill the role of design specialist or maintenance specialist. These individuals may only be allowed to take one certification after the fundamental specialist certification. Each of these courses covered the topics and equipment that are necessary for these roles. But, because of my previous experience, the material felt like more of a refresher. That said, the target audience for this training are people with less experience in cybersecurity, the techniques, and the countermeasures. For these, each course did help to re-enforce all the primary concepts and ensure that I have been exposed and tested to this knowledge repeatedly. In the end, since I passed each of the exams, I do feel I have demonstrated an understanding of all the standard\u0026rsquo;s cybersecurity concepts.\nNow, I am not going to conclude with a comparison between the GIAC GICSP and the ISA/IEC 62443 Cybersecurity certifications. I will note that while the GIAC GICSP test is an open book test the ISA/IEC62443 certification tests were not. Thus, there was a LOT of memorization and use of my test taking talents (thank you scantron tests during the 1970\u0026rsquo;s and 1980\u0026rsquo;s). I will say that I am proud of my GIAC GICSP certification, and I am waiting impatiently for my ISA/IEC 62443 Cybersecurity Expert black badge. I think it was an extremely valuable and potentially necessary experience. Both certifications augment each other, and I recommend them both. Whether the industry thinks that I am more valuable as a cybersecurity expert in the IACS fields is yet to be seen. Only time will tell.\nGo forth and do good things,\nDon C. Weber\n","date":"July 11, 2023","externalUrl":null,"permalink":"/blog/achieving-the-isa-iec-62443-cybersecurity-expert-certification/","section":"Blog","summary":"In February 2023 I was attending a conference for safety. I was introduced to many new people with roles that involved safe implementation of processes, equipment, and manual procedures that support the entertainment and safety of people all around the world. During one of my conversations, I was told that people purchasing services from large industrial control and automation vendors are not asking for people that have achieved the GIAC GICSP certification. They are specifically asking for people that have achieved the ISA/IEC 62443 Cybersecurity certifications. That was the moment I decided I was going to achieve the ISA/IEC 62443 Cybersecurity Expert certification before the end of 2023.\n","title":"Achieving the ISA/IEC 62443 Cybersecurity Expert Certification","type":"blog"},{"content":"Initially, I ignored the YouTube video, Flipper Zero attacking Smart Power Meters. I watched it. I thought it was “interesting.” But, I did not want to spend a lot of time on it. After all, it has been over ten years since my Black Hat / DEFCON 20 talk, Looking into the Eye of the Meter. I do not have the time, resources, or permission to do any more work on smart meters. So, I figured I would leave it to others to address the findings in this video and the person involved.\nFlipper Zero Sending Commands to A1RL+ Meter\nIt became a little more interesting when Peter Fairlie (the apparent owner of the YouTube channel) released the next two videos titled Flipper Zero Disconnecting Smart Meter Power to House and Flipper Zero Smokes Smart Meter ! and they started getting more media attention. In these videos the Flipper Zero is used to run two commands. For the first command, the Flipper Zero is set to operate in the 902 - 928 MHz range and to send a file “D” (changes slightly in different videos) which appears to start the communications with the meter. It can be presumed that this file contains packetized commands which are modulated and transmitted to the meter. Once these bytes are received by the meter, an A1RL+ in the first and second videos and a A3TL in the third video, the meter appears to go into a test mode and cycles through multiple displays on the meter’s Liquid Crystal Display (LCD). The second script run by Peter, titled “sudo SHUTDOWN NOW”, is represented to have “disconnected” the meter resulting in a power outage for the home. This “disconnect” condition is a lie.\nIn truth, as explained to me by Dr. Emma Stewart, an expert in electrical and smart grid technologies, neither of these meters have a disconnect feature built into them. It is physically impossible for them to “disconnect” and permanently deenergize the home. She pointed me to the technical manuals for the ALPHA Plus Meter (A1RL+) Technical Manual and ALPHA A3 ALPHA Meter (A3TL) Technical Manual which explain the meter’s base functionality with no description of a disconnect feature.\nThe result of the Flipper radio transmission on the meter appears to cycle the operating mode of the meter resulting in loud physical clicking from the meter and the house deenergizing and reenergizing in a cycle until the meter stops the cycle or resets. The documentation for the A3TL and A1RL+ does not specifically explain a test mode that would cause this behavior. It is possible that there is an undocumented test. It is also possible that the data received by the meter, from the Flipper Zero, resulted in this cycle. As to why the A3TL meter started smoking during one of these operations it cannot be determined without a more detailed physical inspection of the meter.\nSmoke Coming Out of Meter\nTo understand this situation better it is important to understand the equipment that is being “attacked” in these videos. The Elster A3TL and A1RL+ are electric meters that are a bit more advanced than the old meters with spinning dials. While more advanced than these older models, the A3TL and A1RL+ are not considered Smart Meters. Smart meters are devices that are deployed as a part of an Advanced Metering Infrastructure (AMI) project that provide significantly more capabilities and communications with the utility’s remote management infrastructure. The A3TL and A1RL+ meters were designed to operate on their own or, if configured with a communication module like the Elster ALPHA STARS Wide Area Network (WAN) option board, as a member of an Automated Meter Reading (AMR) deployment. The primary difference between the AMI and AMR technologies is that the AMI meters communicate back to the utility through radio gateways and can be programmed to respond to different conditions when these communications are not available. AMR meters, like the ones in the videos, require utility personnel to collect the information from the meter by driving a radio near the meter. The AMR meters have very limited programmed functionality primarily limited to self-tests to provide information to operators without the need to connect external analysis tools making maintenance safer and faster.\nNow that we understand the meters a little bit better, the next question is why Peter is testing the meters on the side of his home (and, presumably, a neighbor’s house). The answer is he is not testing the smart meter installed on his home. He wants the viewers to think he is testing a smart meter but he is using the old ‘bait-n-switch’ trick. The meters, used in each video, can be easily purchased on eBay for $25.00 as shown in the following image. The meter in this image is a “non-AMR” meter meaning that it most likely does not come with a communications radio. It is very likely that Peter purchased one of these meters, possibly with a communication module. Then, after conducting some research, Peter replaced his home’s meter (or smart meter) with the purchased meter.\nMeter for Sale on eBay\nThe electric meter seals on the meters in the videos make it seem like the meters have not been removed and are in the original condition as installed by the local utility. However, like the meters, these seals can be purchased online. The following image shows yellow electric meter seals, like those on the meters in the videos, can be purchased on Amazon for $25.00.\nElectric Meter Seals on Amazon\nPeter appears to have purchased several of these meters and is using them to test meter communications by connecting them to his home in Canada (deduced from OSINT taken from his other videos in his YouTube channel). This is not surprising as Peter appears to have a passion for hacking technologies with radios and in his job as the Chief Technology Officer (CTO) for First Mile Technologies which provides radio communication in many of their solutions.\nThe problem I have with the information presented in these videos is that it is purely Fear Uncertainty and Doubt (FUD). Peter obtained decommissioned and irrelevant meter technology and purposely represented his research as destructive and a threat to societies deploying smart meters. Worse, it rekindles the arguments of smart meter conspiracy theorists and politicians which forces smart meter researchers, industry professionals, and vendors to waste valuable cycles on disproving his claims. These professionals have more important tasks defending Canada’s and the United States’ critical infrastructure. They should not be wasting their time on someone grubbing for YouTube subscriptions and ‘for the LULZ.’ The testing shown in these videos can also lead other people to think that testing the meters on their homes is acceptable. The unauthorized testing of meters is illegal and people testing meters owned by a utility will most likely be subject to prosecution.\nMy recommendation to people conducting authorized meter and radio research is to avoid creating controversial videos and blog posts to attract attention. I encourage all of you to create technical content that explains what you are doing and how you are doing it. Open source research is extremely important for all industries but the research steps and results should stand on their own merits without sensationalistic claims. Additionally, when issues with critical infrastructure technologies are found I recommend that you follow responsible disclosure recommendations using vulnerability disclosure services provided in the Canada authorities and US CISA. These teams have the means to notify vendors in a manner that allows them to understand the situation and produce remediations that prevent and detect attacks. This is how your hard work can help protect your society and ensure you get the electricity you need to continue your research, jobs, and hobbies.\nFinally, I MUST say something about the dangers of doing research on meters. Meters are very dangerous devices that can, and will, kill you. The internal components of these devices contain capacitors that store enough energy to stop your heart several minutes after they have been unplugged. Do not open these devices without the proper training on the internal electrical components. The best way to test these types of devices is to get a job with one of the many vendors that produce smart grid technologies or with a utility. These organizations are looking to hire and train people to improve the security of industrial solutions and their implementation. A quick search on Google or Linked In will provide you with a long list of opportunities for new and experienced positions.\nGo forth and do good things,\nDon C. Weber\nSpecial Thanks # I would like to give a special thank you to the following people who helped review this situation and blog post with me. Their support was invaluable.\nDr. Emma Stewart Danielle Jablanski Matt Carpenter KF Resources # Meter on eBay $25.00: https://www.ebay.com/itm/234964453806?hash=item36b4f909ae:g:h54AAOSwRCJkMZtl Electric Meter Seal on Amazon $25.00: https://www.amazon.com/LeadSeals-Padlocks-Disposable-Anti-Tamper-Sequentially/dp/B0BZ71M57J Elster Form 16S A3 ALPHA Meter / Collector Emissions Test Report: https://device.report/m/9acaec0d1022c1b1fe5cfcfa356ad2221c9ccf61bd3467c97982db7542fecb98.pdf Elster Form 4S REX Meter Emissions Test Report: https://device.report/m/58a891a0a6b0a4f310030dd2af1a53f5452ea9f8af50b9f8a6cd9034bba5751a.pdf Flipper Zero attacking Smart Power Meters: https://www.youtube.com/watch?v=K3_0XHlCEQg Flipper Zero Disconnecting Smart Meter Power to House: https://www.youtube.com/watch?v=lwR02fkLfhU\u0026amp;t=2s Flipper Zero Smokes Smart Meter!: https://www.youtube.com/watch?v=kF6o9Ec4k_o\u0026amp;t=210s ALPHA Plus Meter Technical Manual: https://www.guggenmossales.com/documents/PowerPlus-TM42-2182C.pdf ALPHA A3 ALPHA Meter Technical Manual: https://guggenmossales.com/documents/A3MeterTM42-2190BUSVersion.pdf ","date":"June 14, 2023","externalUrl":null,"permalink":"/blog/radio-expert-staged-the-flipper-zero-meter-attack/","section":"Blog","summary":"Initially, I ignored the YouTube video, Flipper Zero attacking Smart Power Meters. I watched it. I thought it was “interesting.” But, I did not want to spend a lot of time on it. After all, it has been over ten years since my Black Hat / DEFCON 20 talk, Looking into the Eye of the Meter. I do not have the time, resources, or permission to do any more work on smart meters. So, I figured I would leave it to others to address the findings in this video and the person involved.\n","title":"Radio Expert Staged the Flipper Zero Meter Attack?","type":"blog"},{"content":"Blog Post Originally Published on Claroty Nexus Blog\nIllicit remote access to industrial control systems and devices provides threat actors with access to process information, user and service account credentials, and the ability to remotely interact with attack surfaces. These attack vectors are the current security focus of most organizations in critical infrastructure and production, distribution, and service industrial sectors.\nThis reprioritization has relegated physical security, once an essential defense ensuring the safety of operational technology, to the backseat. The reasons for this vary from organization to organization and site to site. My experience is that legacy site physical security components change at such a slow rate that weaknesses are likely to go undetected or are easily overlooked. One example would be gaps between doors and door frames occurring when building foundations shift over time. These weaknesses may allow exploitation using simple techniques such as latch jimmying or under-the-door tools, below.\nSource: Cutaway Security\nSource: Cutaway Security\nTo offset these weaknesses, most organizations fall back to enhanced closed-circuit television (CCTV) and digital building/room access techniques. However, these same organizations lack an organized response process to explain what happened on the insides of these buildings. Thus, these expensive digital countermeasures merely provide a false sense of security.\nIt is difficult to predict the motivation of a threat actor or which threat actor group will target an organization at a specific time. Threat intelligence can help focus efforts and reduce costs but, at the end of the day, we must be good at evaluating our countermeasures and reducing gaps little-by-little. Threat intelligence that helps us understand that the ingenuity of each threat actor group should not be underestimated. Threat actors with time to evaluate implemented countermeasures and then react will identify weaknesses and use them to their advantage.\nSource: http://redd.it/1pn1xi\nPhysical security has always been a consideration for the implementation of Industrial Automation and Control Systems (IACS) due to the potential consequences of unauthorized access. Despite these safety standbys, the Cybersecurity and Infrastructure Security Agency (CISA) has continued to release updates for organizations to review and improve their physical security efforts. In 2021, CISA released an update to the Cybersecurity and Physical Security Convergence guide.\nThis guide outlines the separate management of physical security and cybersecurity in all industrial sectors. They highlight the typical siloed management of these efforts and how it provides threat actors with the opportunities to exploit these situations to their advantage. Organization leadership needs to realize that these silos are not intentional. The missions of physical security teams typically never included considerations for digital threats and therefore they lack communication, coordination, and collaboration with the cyber security teams.\nFortunately for the IACS industry, the CISA Cybersecurity and Physical Security Convergence guide outlines a methodology for improving the partnership of these teams to employ a \u0026ldquo;converged security operations\u0026rdquo; effort. The implementation of these recommendations will improve the effectiveness of physical security countermeasures and the responses to unauthorized physical access. These recommendations will result in the establishment of a well-rounded strategy to obtain strategic improvements while moving to improve your team\u0026rsquo;s current physical security compliance efforts.\nSource: CISA, image linked\nWhile leadership is working to improve strategic efforts, OT team leaders responsible for remote sites or a plant\u0026rsquo;s operations should gather a team consisting of persons from the physical security team, the cybersecurity team, and the OT team. This team should conduct a physical walk through of each location to review the ingress points to the location, all external control cabinets, entrances to each building, and the physical control cabinets and network racks within the buildings.\nThe team should discuss the current conditions and exchange ideas about how threat actors could take advantage of current conditions to access the facilities and digital assets. The cybersecurity team member can provide educational information about common tools threat actors might deploy to access and persist within the control network, such as dropboxes and wireless access points. The OT team member can provide details about critical areas and assets at the location. The physical security team member can review the conditions of doors, fence lines, and CCTV cameras to understand their current effectiveness in preventing and alerting to unauthorized access.\nThese are the starting points to address the lack of communication, coordination, and collaboration that exists between these teams. These efforts are also useful in predicting the actions threat actors could take to attack the physical process at that location or gain access to the location’s network infrastructure and, potentially, access to the organizations core digital assets, such as SCADA control centers.\nConducting a review of physical security countermeasures is necessary to get an organization’s siloed physical and cyber security teams working together with the OT team. This collaboration will improve the safe and reliable operations of any control environment.\nI encourage all teams to review the CISA SECTOR SPOTLIGHT: Electricity Substation Physical Security guide to understand some of the challenges of physical security, how threat actors are currently targeting remote locations, and how to implement effective countermeasures. Ultimately, organizations must begin to integrate their physical and cyber security efforts before physical access is used against them.\nGo forth and do good things,\nDon C. Weber\n","date":"June 9, 2023","externalUrl":null,"permalink":"/blog/overlook-physical-security-risks-at-your-own-peril/","section":"Blog","summary":"Blog Post Originally Published on Claroty Nexus Blog\nIllicit remote access to industrial control systems and devices provides threat actors with access to process information, user and service account credentials, and the ability to remotely interact with attack surfaces. These attack vectors are the current security focus of most organizations in critical infrastructure and production, distribution, and service industrial sectors.\n","title":"Overlook Physical Security Risks at Your Own Peril","type":"blog"},{"content":"Originally posted on the Cutaway Security Linked In on March 22, 2023.\nLet\u0026rsquo;s consider some practical steps for a ICS/OT Cybersecurity Self Analysis. Today, let\u0026rsquo;s cover physical security at your substation, pumping station, or compressor station. We feel this checklist is a good start. Do you have items to add? Let us know in the comments on Linked In.\nVerify all cameras are working and cover each gate and building doors. Identify if cameras are connected via coaxial cable, ethernet, or wireless. For ethernet, check if it can be unplugged and used. For wireless, confirm it is a secure network and not on the process network. Confirm camera recordings can be exported and saved. Walk fence line and review if gates are locked. Check for low points where erosion makes it easy to move under the fence. Check for exterior objects (e.g. trees, walls) that help get over the fence. Check if gate exit mechanisms can be used to easily unlock the gate from outside the fence line. Review each external control cabinet (watch out for bees / wasps nests) and confirm each cabinet is locked. Review each external control cabinet for tamper tape or sensors that indicate the door has been opened. Review each external cabinet for network and process documentation (these should not be in external cabinets). Review the devices in external cabinets to ensure their physical security mechanisms are enabled (e.g. PLC keys). Check each door into buildings to ensure they lock. Check each door frame to ensure the throw is protected (e.g. shifted foundations can expose throws to tampering) and prevents under-the-door / over-the-door tools. Check doors for tamper tape or sensors that indicate the door has been opened. Check buildings for ladders that lead to roof access. Verify these accesses are locked and determine if tamper tape or sensors are used to indicate the door / hatch has been opened. Review buildings for unexpected wireless antennas (e.g. cellular modems on generators for vendor / integrator maintenance). Check control cabinets, network racks, and server racks inside each building to ensure doors are on, locks are available and used, and to determine if tamper tape or sensors are used to indicate the door has been opened. Review site personnel and physical security team\u0026rsquo;s unauthorized access checklists to determine if the cybersecurity team is notified when these events occur. For critical cabinets or closets, determine if cameras are used to monitor and record access. Determine if physical walkthroughs are regularly conducted to review site, control cabinets, network racks, and server racks for unauthorized devices and network connections. The information obtained from this review is to be used for risk analysis. Not everything needs to be \u0026ldquo;fixed.\u0026rdquo; For instance, lack of tamper detection is a vulnerability but the team / leadership may accept the risk due to cost or other compensating controls.\nGo forth and do good things,\nDon C. Weber\n#otcybersecurity #itcybersecurity #industrialcybersecurity #physicalsecurity #criticalinfrastructure\n","date":"March 22, 2023","externalUrl":null,"permalink":"/blog/ics-ot-cybersecurity-self-analysis-physical-security/","section":"Blog","summary":"Originally posted on the Cutaway Security Linked In on March 22, 2023.\nLet’s consider some practical steps for a ICS/OT Cybersecurity Self Analysis. Today, let’s cover physical security at your substation, pumping station, or compressor station. We feel this checklist is a good start. Do you have items to add? Let us know in the comments on Linked In.\n","title":"ICS/OT Cybersecurity Self Analysis - Physical Security","type":"blog"},{"content":"","date":"March 12, 2023","externalUrl":null,"permalink":"/tags/cybersecurity/","section":"Tags","summary":"","title":"Cybersecurity","type":"tags"},{"content":"Originally posted on the Claroty Nexus Community as \u0026ldquo;Managing Cyber Risk in Industrial, Automated Environments\u0026rdquo; on February 23, 2023.\nEnvironments with industrial or automation control systems are built to ensure process availability and resilience. Availability is defined as \u0026ldquo;the quality of being able to be used or obtained\u0026rdquo; and resilience as \u0026ldquo;the capacity to recover quickly from difficulties; toughness.\u0026rdquo; These days, these definitions do not necessarily take into consideration the rampant connectivity happening today within automation environments.\nSo, what happens to availability and resilience when process control technologies are connected to an ethernet network and become digital, cyber assets? Organizations must immediately change their perception of threats and risk and ask: How do control environments achieve \u0026ldquo;cyber availability\u0026rdquo; and \u0026ldquo;cyber resilience?\u0026rdquo; The answer is as complex as the multitude of different types of industrial and automation control system environments.\nSteps to Ensure Availability, Resilience # For complex systems, the best road to availability and resilience is to break the system down into simpler parts and manage each as a part of the whole. For example, an electric utility may have separate electrical substations and natural gas compressor stations with a central control center that receives information from all remote locations. The approach to addressing these parts depends on your role in the organization and whether you will provide systemic change (strategic efforts) or tactical change (technical implementation). Tactical changes provide rapid risk reduction at a specific location while systemic changes address an organization’s cultural behavior.\nFor environments rushing to address the rapid deployment of control environments that are remotely accessible from the internet, the efforts of strategic and tactical teams must be coordinated to ensure these systems are resilient to attack and remain available. A plan that focuses on defense-in-depth, process recovery plans, and network service reduction is one approach to consider.\nRisk reduction requires knowledge of deployed assets and current operational procedures at each location. This information is necessary to implement a defense-in-depth methodology that prepares for process recovery while reducing risk from external threat actors. You cannot protect what you do not know; a list of hardware and software assets, categorized by criticality, will provide a team with the starting point for evaluating the current implementation.\nProcess recovery plans need to be regularly reviewed and updated to address a prioritized list of digital network and fieldbus communications that include remote access, critical server and application unavailability, compromised credentials, and protection of device configurations. Many processes can be run manually for specific time periods. However, safe operations these days have heavy reliance on information from remote assets, require management from a central control center, or depend on administration by integrator-provided subject matter experts (SMEs).\nReduce Risk by Reducing Attack Surface # Attacks on a process’ availability will generally be conducted against network services that accept data. The network services of Human Machine Interfaces (HMIs), Programmable Logic Controllers (PLC), Remote Terminal Units (RTUs), Universal Power Supplies (UPS), servers, and workstations are considered the process’ attack surface.\nReduction of this attack surface is necessary to improve availability. Asset management and process recovery plans provide details about the network services that are required for operations. Detailing necessary communications allows for the configuration and management of enforcement boundary technologies, implementing centralized logging for network devices and authentication servers, and improving system, device, and software configurations.\nTo achieve rapid risk reduction, these efforts must concentrate on identifying and prioritizing efforts for quick and noticeable improvements. As each effort is implemented, strategic and tactical teams will have more actionable intelligence to feed into the next effort. Agile development strategies can be followed to achieve quick wins while also distributing lessons learned to each team. This model will ensure that all team members are working toward the same focused goal of improving process availability and resilience. After a few passes, the team will become more adept at the process and move quickly to improve the effort for continuous risk identification and mitigation.\nGo forth and do good things,\nDon C. Weber\nCutaway Security, LLC.\nWebsite: https://www.cutawaysecurity.com\nLinked In: https://www.linkedin.com/in/cutaway/\nSANS Instructor: https://www.sans.org/instructors/don-c-weber\n","date":"March 12, 2023","externalUrl":null,"permalink":"/blog/managing-cyber-risk-in-industrial-automated-environments/","section":"Blog","summary":"Originally posted on the Claroty Nexus Community as “Managing Cyber Risk in Industrial, Automated Environments” on February 23, 2023.\nEnvironments with industrial or automation control systems are built to ensure process availability and resilience. Availability is defined as “the quality of being able to be used or obtained” and resilience as “the capacity to recover quickly from difficulties; toughness.” These days, these definitions do not necessarily take into consideration the rampant connectivity happening today within automation environments.\n","title":"Managing Cyber Risk in Industrial, Automated Environments","type":"blog"},{"content":"","date":"March 12, 2023","externalUrl":null,"permalink":"/tags/ot/","section":"Tags","summary":"","title":"OT","type":"tags"},{"content":"","date":"March 6, 2020","externalUrl":null,"permalink":"/tags/ghidra/","section":"Tags","summary":"","title":"Ghidra","type":"tags"},{"content":" Introduction # It has been a while since I have analyzed any program or firmware. The majority of my previous experiences were mostly analyzing Capture The Flag (CTF) binaries with the help and instruction from my good friend Matt Carpenter of Grimm Security. While extremely helpful, I always knew I was looking for a vulnerability that should be easy to find since I mainly stuck with the easy to medium difficulty challenges. Analyzing actual firmware for a vulnerability is much different. While most programs \u0026ldquo;should” have vulnerabilities, there is no guarantee of a flag at the end, like in CTF binaries, that can be verified by submitting a string of bytes for points.\nReversing programs or firmware was never a priority in my daily duties. When I was reviewing binaries I often found myself looking at firmware based on the ARM or MSP430 architecture. Since the free version of Hex-Rays IDA does not work with ARM or MSP430 binaries, I found myself gravitating to the tool Vivisect. Vivisect was useful to me because it is written in Python and Matt uses it on a regular basis. But, I have always wondered if using a tool like IDA Pro would make reverse engineering easier for me. Thus, when Ghidra was released, I knew I needed to find a project to help me learn how to use it.\nNext, I needed to find a good target firmware with known vulnerabilities. I often thought that looking at the firmware for the Moxa 5610 Serial-to-Ethernet converter would be interesting, but I put it off. Then I ran into Jason Larsen of IOActive during an assessment. Over dinner we talked about the attack on the Ukrainian power grid and the fact that the attackers bricked the Moxa devices. That\u0026rsquo;s when he told me about his BSides Idaho Falls talk titled \u0026ldquo;14 Hours and an Electric Grid\u0026rdquo; where he broke down his analysis process using the Moxa 5610 as an example.\nWith Jason and Matt in on my side, how could I not take a look at the Moxa firmware. I decided that I needed to record my effort to help me remember my steps. After banging my head on a few issues, I realized this might be helpful to others who are starting out reversing firmware and using Ghidra. The following is an outline of some of the issues I had to overcome while analyzing the Moxa firmware with Ghidra. I definitely had help during this journey and I\u0026rsquo;ll include references to Jason and Matt throughout. This project would have taken much longer, and would have been much more frustrating, without their input.\nSpoiler, I don’t identify any vulnerabilities during this write-up. It is just an outline of the steps I used to begin the analysis and learning process.\nObtaining Firmware for Analysis # First I needed to get the actual firmware to analyze. Moxa provides firmware online to download and update their devices. Several months ago the site provided older versions of the firmware. Thus, firmware versions with vulnerabilities could be obtained for analysis. I downloaded older versions of firmware for the 5600 devices. Since then, Moxa has updated their site so that only the latest version of the firmware can be downloaded. Good for them.\nInitially, I tried to analyze the downloaded files by importing it directly into Ghidra. This did not work very well and I came to realize that Moxa bundles firmware updates in a proprietary binary file format (ROM). To analyze the device\u0026rsquo;s functionality the firmware must be extracted from the ROM. The ROM contains a file header with bytes that detail the size of the firmware and pointers to the offset of the starting byte of the firmware. With a little deductive reasoning these values can be located. Fortunately for me, Jason had already performed this analysis and shared his insight. He also informed me that the Moxa devices use ARM-based firmware that is compiled in little endian byte order, a condition I had not accounted for during my initial analysis.\nFirmware Disassembly with Ghidra # Ghidra needs to understand a few things about the firmware to analyze it correctly. As Matt has pointed out to me many times (paraphrased), \u0026ldquo;Nearly every four byte chunk can be disassembled into an ARM instruction, but it doesn’t mean it’s actually an instruction. It is important to understand how it was compiled, and where it starts, to analyze it correctly.\u0026rdquo;\nTo begin, I imported the extracted firmware file from the ‘File’ menu.\nOnce selected, Ghidra needs to understand how the firmware was compiled. For this example, I set the \u0026ldquo;Format:\u0026rdquo; option to \u0026ldquo;Raw Binary.\u0026rdquo; Next I set the processor and orientation (endianness) of the data by selecting the \u0026ldquo;ARM:LE:32:Cortex:default\u0026rdquo; option which represents ARM Cortex Little Endian, as shown in the following image. Additionally, depending on where the firmware was obtained, the base address of the code needs to be specified. If so, click on the options button and update those settings. For this example, modifying the settings in the \u0026ldquo;Options\u0026hellip;\u0026rdquo; window are not necessary and I just clicked the \u0026ldquo;OK\u0026rdquo; button.\nOnce imported, Ghidra asked to analyze the file for opcodes and other values. I clicked the \u0026ldquo;Yes\u0026rdquo; button to initiate the analysis.\nGhidra has many options to help analyze a file. The default settings are typically enough to get started. There are a few unselected items that I found are useful when troubleshooting these analysis steps. The \u0026ldquo;ARM Aggressive Instruction Finder\u0026rdquo; appears to take an extra pass or apply some more advanced analysis of the bytes in the file. This extra effort helps to identify ARM instructions (opcodes) that may not have been recognized on the initial analysis of the file. This extra analysis has the benefit of reducing some manual instruction analysis (which will be covered in a moment) but can also result in the incorrect assignment of opcodes to a series of bytes. I feel the benefits outweigh the risks for this option. The second useful option is the \u0026ldquo;Decompiler Parameter ID\u0026rdquo;. While analyzing the file, Ghidra will attempt to decompile functions into higher level language, C. This option adds additional information to the decompiled function that can help with manual analysis of the code. Both of these options will add time to the initial analysis while, I feel, helping to reduce follow-on manual analysis steps. I added both of these options and clicked the “Analyze” button to begin the analysis.\nOnce completed Ghidra will display the disassembled representation of the firmware. The image below shows the display areas that represent the byte offset, the actual bytes, and the disassembled instructions.\nMost of the firmware should be disassembled as Arm instructions. To confirm, manual review must be performed. The image below shows a series of bytes where Ghidra interpreted the bytes as Thumb instructions. Some firmware may contain Thumb instructions. In this case, there should be no Thumb instructions and this is a mistake.\nTo correct this mistake the instruction must be cleared. I right clicked on the instruction (although I could have clicked on the bytes or the offset, as well). Ghidra popped up a menu that allowed me to “Clear Code Bytes.” I selected this option to reset the bytes.\nOnce cleared, I right clicked again, this time on the first byte. Ghidra popped up a menu and I selected “Disassemble - Arm.” Selecting this option forces Ghidra to analyze the bytes as Arm instructions.\nThe result was a series of bytes updated as Arm instructions. Fortunately, Ghidra did not just stop at the four-byte chunk I clicked on. It continued to analyze the following bytes resulting in a new series of Arm instructions. I repeated all of these steps from the beginning to the end of the binary.\nTowards the end of the firmware the Arm instructions stop and the firmware’s data section begins. This data area contains structures and strings that are referenced throughout the firmware. Most of the strings had been automatically identified by Ghidra during the analysis of the firmware. However, like the Arm instructions, Ghidra had issues identifying all of the strings. Manual analysis was necessary to interpret all of the strings missed during Ghidra’s analysis. Identifying strings in the firmware is necessary because Ghidra will automatically update any references from the Arm instructions to these strings. Reversing the functionality of each function is easier when these strings are identified and referenced correctly.\nThe steps for updating string references is similar to updating Arm instructions. I right clicked on the first byte of the string and selected the “Data” reference in the pop-up menu. A submenu was displayed and I selected the “string” option. I continued this from the beginning of the data section to the end of the firmware for all strings I could manually identify.\nManually updating the Arm instructions and string references may seem tedious. But, for accurate analysis, these steps are necessary because it updates many of the references and jumps within the analyzed code. Running through each of the Moxa firmwares I analyzed took me about an hour to complete these steps. Matt assured me these are necessary actions that must be performed when starting to analyze a new program or firmware (I may have bitched at him about it, a little). He also points out that this process makes the analyst more familiar with the firmware. Interesting things definitely jumped out at me, like references to passwords, while I was taking these manual steps.\nReviewing the Analyzed Firmware # Once Ghidra has disassembled all of the ARM instructions it was time to figure out what the firmware is doing. Finding a starting point can sometimes be difficult. There are many strategies for reverse-engineering firmware. Jason had mentioned to me that there are plenty of debugging strings to help identify where the firmware accepts input. I decided to try and find the function where the firmware managed updates. Starting with the \u0026ldquo;Search\u0026rdquo; option, from the Ghidra menu, I selected \u0026ldquo;Program Text\u0026hellip;\u0026rdquo; and searched for the term \u0026ldquo;update\u0026rdquo; across \u0026ldquo;All Fields.\u0026rdquo; This detected the string \u0026ldquo;s_flashrom_update\u0026rdquo; at offset 0x022d74.\nFrom here I attempted to understand what this function is doing by reviewing both the Arm instructions and the decompiled code. The decompiled code is displayed in the “Decompile” windows which typically opens on the right side of the Ghida tool. The decompiled code is an interpretation of the Arm instructions in this function. The Ghidra analyzer outlines incoming parameters, local variables, actions taken within the function, and what the function returns. All of this information can be reclassified or renamed by the analyst to get a better understanding of the code. When parameters, variables, or pointers are renamed all of the references to that object are updated throughout the program.\nFor instance, I reviewed the decompiled code for the function containing the \u0026ldquo;update\u0026rdquo; string. The string is passed into another function with the original name of \u0026ldquo;FUN_00022e5c\u0026rdquo;. (Ghidra named this function according to the offset of the function within the code base.) My analysis determined that this function is a print or logging statement. Therefore, I updated the function name from \u0026ldquo;FUN_00022e5c\u0026rdquo; to \u0026ldquo;print_log_message-???\u0026rdquo;. I included the \u0026ldquo;???\u0026rdquo; at Matt\u0026rsquo;s recommendation because I was initially unsure if my assumption about the function\u0026rsquo;s purpose was correct. This also helps others, reviewing the code with me, understand when I am certain about a function\u0026rsquo;s purpose or if I\u0026rsquo;m taking a Wild Ass Guess (WAG) at it.\nConclusion # As I mentioned, this is a description of how I started familiarizing myself with Ghidra and analyzing firmware. Nothing special here, just the learning process. Hopefully you found something you can use or that you can see I’m doing fundamentally wrong. If you have questions or input just ping me on Twitter using @cutaway. You can direct message me, we can exchange emails, or we can jump on a Slack channel. Just reach out.\nDepending on the interest in this topic, I’ll generate a follow on post where I identify some familiar functions such as strcpy. I have also generated a few Ghidra scripts to help analyze firmware from different devices and identify interesting and similar functionality. Those can be found on the Cutaway Security Github in the Ghidra section of CutSec_Tools.\nAdditional Note: After I completed this post the Ghidra Ninja posted an excellent video about this topic. Be sure to check out Bare-metal ARM firmware reverse engineering with Ghidra and SVD-Loader. It has helped me understand some of the things I could have done better with this. The SVD-Loader option is excellent and I\u0026rsquo;m hoping it will help with some of the pointers that are necessary to understand functionality and ensure the code references and disassembly is correct. But sure to subscribe to the channel for great tutorials about Ghidra and reversing.\nGo forth and do good things,\nDon C. Weber\nCutaway Security, LLC.\nEmail: don@cutawaysecurity.com\nWebsite: https://www.cutawaysecurity.com\nTwitter: https://twitter.com/cutaway\nSANS Instructor: https://www.sans.org/instructors/don-c-weber\n","date":"March 6, 2020","externalUrl":null,"permalink":"/blog/learning-ghidra-basics-analyzing-firmware/","section":"Blog","summary":"Introduction # It has been a while since I have analyzed any program or firmware. The majority of my previous experiences were mostly analyzing Capture The Flag (CTF) binaries with the help and instruction from my good friend Matt Carpenter of Grimm Security. While extremely helpful, I always knew I was looking for a vulnerability that should be easy to find since I mainly stuck with the easy to medium difficulty challenges. Analyzing actual firmware for a vulnerability is much different. While most programs “should” have vulnerabilities, there is no guarantee of a flag at the end, like in CTF binaries, that can be verified by submitting a string of bytes for points.\n","title":"Learning Ghidra Basics Analyzing Firmware","type":"blog"},{"content":"","date":"March 6, 2020","externalUrl":null,"permalink":"/tags/reverse-engineering/","section":"Tags","summary":"","title":"Reverse Engineering","type":"tags"},{"content":"","date":"November 21, 2019","externalUrl":null,"permalink":"/tags/infosec/","section":"Tags","summary":"","title":"InfoSec","type":"tags"},{"content":"","date":"November 21, 2019","externalUrl":null,"permalink":"/tags/pen-testing/","section":"Tags","summary":"","title":"Pen Testing","type":"tags"},{"content":"","date":"November 21, 2019","externalUrl":null,"permalink":"/categories/presentations/","section":"Categories","summary":"","title":"Presentations","type":"categories"},{"content":"This week I had the pleasure of speaking twice at the SANS Pen Test Hackfest Summit 2019. I had an excellent time and got to meet up with some old friends and make new acquittances. That is one of the most important things about these events. Attending pulls us from behind our virtual cubicles and gets us in front of human beings with common interests. It allows us to participate in conversations and, hopefully, have interactions where the communications include body language, facial expressions, and vocal inflections.\nThree-Person Panel # The first talk was a panel with Steven Sims (@Steph3nSims) and Kevin Tyers (@waronshrugs) titled: “Break it ‘Til You Make it: How Playing with Fire Levels Up Your Offensive Skills.” We were asked to describe ourselves and some of our experiences. Steven and Kevin gave some excellent input that I’m not going to paraphrase here, as I would not them justice. For me, I spoke about the challenges I experienced getting started in the field of information security. I discussed my early blogging and podcast efforts that helped me educate myself and introduced me to so many like-minded individuals. I also talked about my struggles with fighting through the learning process and accepting my initial “failures” as me learning and getting better. Yes, I still struggle with this. I’m just quicker to remind myself to be nice to myself.\nPenetration Testing ICS Presentation # My second talk was about “Pen Testing ICS and Other Highly Restricted Environments.” It contained a condensed message about how to approach and be successful at conducting assessments where the testing steps could have a negative impact on safety and the process. The slides for the talk are up if you would like to take a look at my approach. What was great is that Lesley Carhart (@hacks4pancakes) also spoke on penetration testing ICS environments. She gave an excellent introduction of the concepts and technologies associated with processes. She raised many of the points that I continued in my own talk. Her introduction allowed me to take a deeper dive into how information security professionals are imposing roadblocks by harping on the fragility of process technologies rather than understanding the requirements that lead to their architecture.\nInteresting Questions # My previous posts and talks have a similar message, so I won’t expand it any further here. I would rather focus on some of the questions I received while I was at the conference.\nFirst Question # At the end of my presentation, Jake Williams (@malwarejake), asked. “What do you do if you come across industrial control systems or devices, that you didn’t know where there, during a penetration test?” He intended this as a slow pitch softball for me to hit out of the park. I fumbled with it a bit (things I need to work on). The easy and best answer is “stop.” Stop what you are doing, communicate with your point-of-contact, and determine if this was expected, and decide if you need to avoid specific systems or subnets or continue testing.\nSecond Question # At the end of the conference I was approached by a person and asked (paraphrased), “Aren’t manufacturers doing something about the insecurity and vulnerabilities in their products?” I explained that they are making headway. Their customers are requesting that they make it easier to understand vulnerabilities and implement updates. Customers are also asking that, where appropriate, the vendors and integrators provide security settings and produce documentation that helps their team implement and maintain secure configurations. However, in my opinion, vendors and integrators are not doing enough to educate the clients that are not asking. I gave the example of a recent experience I had discussing vendor-provided guidance during an assessment. My client, the primary IT lead for the OT environment, did not know if there were resources for being informed of vulnerabilities and understanding what needed to be patched. He just figured all risks needed to be accepted unless the integrator reached out. Interestingly, when we spoke with the POC for their integrator, we were informed that they had a subscription-based mailing list that provided this information. He was more than happy to discuss the impact of vendor and OS patches and how it would impact the processes when the customer reached out. He also identified that they have a virtual environment where they test application and OS patches when they are released. And, most importantly, he stated that they could build a virtual representation of the customer\u0026rsquo;s process (for a cost) where things could be tested. So, vendors and integrators are making headway, but their clients need to be requesting and looking for those resources. Communications is a two-way street, everybody can to a little better.\nThird Question # The last question that comes to mind was from young lady from Canada. She is considering joining the Canadian air force and my background as a US Marine lead her to ask about US Marines and information security. She has noticed a trend of US Marines moving towards the information security field and she was wondering why. While I cannot be completely sure, I mentioned that Marines consider everything a weapons platform, defensive and offensive. It is easy for us to think of technologies in this way and, I extrapolate, that a lot of Marines are experiencing technologies more and more on the battlefield (actually in the field or in garrison). Additionally, information security is about defending something from adversaries. This definitely appealed to me and could be why she is experiencing this in the Marines she has run across. Lastly, there is also an excellent program sponsored by Microsoft called Microsoft Software and Systems Academy. This program provides transitioning military veterans with training in technology careers. One of this program’s tracks is in information security. They are doing an excellent job at training our veterans and I highly recommend it. If you know a veteran who wants training or needs to refocus themselves, please point them in this direction.\nConclusion # I’m hoping that SANS publishes both talks to the Summit website in the near future. In the case that they do not, I’ll do my best to get the raw footage and post it here. So, check back soon.\nI had a great time during the conference. I would like to thank Ed Skoudis (@edskoudis) and Steven Sims (@Steph3nSims) for inviting me. Although, it was Jennifer Santiago (@SANSJen) that truly paved the way for me and I am extremely appreciative.\nGo forth and do good things,\nDon C. Weber\nCutaway Security, LLC.\nEmail: don@cutawaysecurity.com\nWebsite: https://www.cutawaysecurity.com\nTwitter: https://twitter.com/cutaway\nSANS Instructor: https://www.sans.org/instructors/don-c-weber\n","date":"November 21, 2019","externalUrl":null,"permalink":"/blog/questions-from-sans-pen-test-hackfest-2019/","section":"Blog","summary":"This week I had the pleasure of speaking twice at the SANS Pen Test Hackfest Summit 2019. I had an excellent time and got to meet up with some old friends and make new acquittances. That is one of the most important things about these events. Attending pulls us from behind our virtual cubicles and gets us in front of human beings with common interests. It allows us to participate in conversations and, hopefully, have interactions where the communications include body language, facial expressions, and vocal inflections.\n","title":"Questions from SANS Pen Test Hackfest 2019","type":"blog"},{"content":"Update: Architecting Secure ICS Environments Slide Deck\nOn October 24, 2019 I delivered a talk at the Wild West Hackin\u0026rsquo; Fest in Deadwood, South Dakota. This conference is primarily attended by information security professionals and businesses with information security teams interested in a hands-on experience. I felt it was an excellent opportunity to provide information about the challenges they will face when implementing and testing security in environments that contain Industrial Control System (ICS) technologies.\nWhen I first started working within ICS environments people were talking about clear text protocols, insecure applications, and devices with a plethora of vulnerabilities. Over time I learned that this situation was common to ICS environments and that the issues were not going to be fixed overnight. In fact, these issues will generally persist until the process or implementation is replaced by a new solution. Even then, there will be instances of all of them in the new solution, depending on business and safety requirements. This might be a bit subjective as everything depends on the goals of the organization; but it is consistent across multiple ICS sectors. To make a difference in this field, I had to learn different ways to talk about these issues and provide constructive solutions that the teams I was working with would be comfortable considering and implementing.\nAfter all, the worst-case scenario for an organization with business models dependent on ICS devices is not a clear text protocol or a vulnerable device. The worst-case scenario is that these devices are directly accessible from the corporate network.\nI have been to several locations where the control networks were deployed in a manner that allowed any system on the enterprise network to directly communicate with control network resources: program logic controllers (PLC), human-machine interface (HMI) systems, and the master servers that support them. I have also been to locations where they thought there was isolation but there were holes in the implementation or there was no protection at all.\nImproving security within these environments is not going to start by pointing out clear text protocols, insecure applications, or the vulnerable devices. The conversations need to start with how these resources are deployed and protected from interactions with assets that are not associated with the specific process. Process environments already have guidance for implementing process environments so that they are robust and safe. This was originally outlined in the ISA-95 standard. This standard defines levels to help implementers organize the deployment of the process\u0026rsquo; devices and the supporting infrastructure. These levels are known as the Purdue Enterprise Reference Architecture, also referred to as the Purdue Model.\nWhile ISA-95 provided guidance for effective process implementation it did not include security guidance. This situation was improved with the initiation of the ISA-99 standard, recently renamed to IEC/ISA 62443. This standard took the Purdue Model and leveraged the natural process boundaries, defined in each Purdue level, to implement security boundaries. Businesses implementing process environments understand this model and they are beginning to wrap their heads around how these things apply to the legacy and future processes. It is here that information security professionals need to focus as these are the techniques these businesses will use to address the clear text protocols, insecure applications, and vulnerable devices.\nTo help teams understand and plan new environments, or remediate current issues, the SANS team has developed the ICS410: ICS/SCADA Security Essentials course, of which I am an instructor. Within the course, to help students understand the Purdue model we use the following graphic: ICS410 Reference Architecture Model.\nThis graphic outlines each Purdue level and provides a brief description of the resource that will be deployed at that level. It also details the different enforcement zones and addresses issues such as remote access from the corporate network to the control network. The explanation of each level and enforcement boundaries is too long of a discussion for a simple blog post. But, I\u0026rsquo;m hoping security professionals and teams can see the approach outlined in the ISA/IEC 62443 a bit better. Using the “worst case” network as an example, here is how I see it updated using the ICS410 Reference Architecture Model.\nThe ultimate goal being an environment that reduces the impact of clear text protocols, insecure applications, and vulnerable devices to very specific areas. Each being protected from each other and thereby improving their robustness and availability.\nGo forth and do good things,\nDon C. Weber\nCutaway Security, LLC.\nEmail: don@cutawaysecurity.com\nWebsite: https://www.cutawaysecurity.com\nTwitter: https://twitter.com/cutaway\nSANS Instructor: https://www.sans.org/instructors/don-c-weber\n","date":"October 25, 2019","externalUrl":null,"permalink":"/blog/wwhf2019-architecting-secure-ics-environments/","section":"Blog","summary":"Update: Architecting Secure ICS Environments Slide Deck\nOn October 24, 2019 I delivered a talk at the Wild West Hackin’ Fest in Deadwood, South Dakota. This conference is primarily attended by information security professionals and businesses with information security teams interested in a hands-on experience. I felt it was an excellent opportunity to provide information about the challenges they will face when implementing and testing security in environments that contain Industrial Control System (ICS) technologies.\n","title":"WWHF2019: Architecting Secure ICS Environments","type":"blog"},{"content":"This article was originally published on Linked In on July 29, 2019.\nICS Security Programs # The implementation and security of Industrial Control Systems (ICS) in business environments is challenging. Most organizations start with legacy environments or build new solutions with process effectiveness as their priority. Once an organization realizes they need to secure the environment they quickly come to the conclusion that their enterprise security program does not easily fit into the primary goals and requirements of the ICS environment. Thus, they need a method to evaluate their current security posture and identify a path forward that is prioritized to the goals of the process(es).\nMost teams start from scratch because their teams have limited experience in conducting this type of assessment. They begin their effort by Googling and asking friends for their experiences. Their research identifies a plethora of methods and models. Mostly of these models relate to complex solutions for critical infrastructure. It is at this point the effort bogs down. The selection process itself is complex and prone to hesitancies born from inexperience.\nSelecting a Maturity Model # I personally feel that evaluating maturity is similar to threat modeling. By this I mean that there are a lot of approaches, each equally confusing as the next. As mentioned, there are several models: Department of Energy (DOE) Cybersecurity Capability Maturity Model (C2M2), Center for Internet Security (CIS) 20 Controls, Industrial Internet Consortium (IIC) Internet of Things (IoT) Security Maturity Model, North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP), National Institute of Science and Technology (NIST) Cybersecurity Framework (CSF), etc. The best an organization or individual can do is to select a method, modify it to what the team can accomplish, and then get buy-in from direct leadership.\nBuy-in is essential because most people are not going to see the need or value in dedicating time to doing these efforts. Also, the people that are going to provide the most value to these efforts are the implementors, or at least their direct leadership. Most of the questions they are asked about their program are asking that they honestly rate their team\u0026rsquo;s effectiveness. Honest ratings are not something that people find easy and are always subjective. Rating their programs naturally leads to embellishment (on purpose or unintentionally) in the positive direction. I\u0026rsquo;ve actually experienced grading fatigue. Evaluating a security program is not something that can be done in one 60-minute meeting. This pulls people away from their normal duties and adds to frustration about the effort. This fatigue and frustration results in quick, positively, slanted ratings. Hence the value of a third-party evaluation.\nReviewing an ICS Security Program # I recently conducted a security assessment of an organization. I asked a lot of questions during the threat modeling phase. This, in a sense, turned the threat modeling into architecture review (no worries, two birds with one stone). The technical teams were extremely honest, and I was able to use their responses to conduct an honest review of their enterprise and control security programs. To guide my information gathering I used the basic concept outlined by the CIS 20 Controls. This helped because the controls are well organized, technical, and kept me on track.\nBecause the technical teams were very capable, I knew that I would need to select a maturity model they would understand and could use to guide technical implementation. Even if the report was more for the leadership of the company. I felt that detailing everything using the CIS 20 Controls breakdown would be confusing (to write and review) and significantly increase the subjectivity. So, I turned to the NIST CSF. The Core Functions and categories are easy to understand and gain agreement to their importance to the processes. I used the information I gathered to grade the subcategories. The subcategories provide a more granular reference point for the technical implementors that do not have backgrounds in IT security.\nOf course, the implementation tier model outlined in the NIST CSF is good for demonstrating the basic maturity of a program. However, from an assessment stand point, I didn\u0026rsquo;t feel it really resonated as to why a subcategory\u0026rsquo;s tier rating was selected or what the organization can specifically do to improve. So, for the assessment, I generated a A thru D grading system which align, as well as I could do it, with the tiers.\n=== A === # Policies are in place, distributed, and implemented. Team members are trained and augment each other\u0026rsquo;s skill sets. Regular reviews are conducted to improve policies and procedures in line with business and security requirements. === B === # Policies are in place, distributed, and implementation has started. Team has some trained relating to their responsibilities. No or inconsistent after actions / lessons learn efforts to improve policies and procedures. === C === # Team has some expertise in security responsibilities. Team understands the concern and attempts to manage on case-by-case basis. No policies in place or are inconsistently implemented. Team has not been trained. === D === # Team has experience to keep things running and address issues on catch-as-catch-can basis. No policies. Team has not been trained. Team does not have expertise in security-related responsibilities. Using this I was able to take the NIST CSF spreadsheet and grade each subcategory using the data I had collected. At first, I felt like I was not getting very far. Each grade is subjective, and you always feel that you do not have enough information. But, the beauty of this method is that it IS prone to argument. Arguments are conversation about the security program. So, I stopped worrying about my subjective grade assignments and concentrated on getting the grades as honest (in my eyes) as possible.\nAdding Value to the Organization # My final report helped to provide the organization with my frame of mind for selecting the model and grades. While I hope that I was as accurate as possible, I know that the team will have to conduct a self-assessment to adjust the grades to make them a bit more accurate. They do need to do this so that they have a good starting point to compare the gaps to their business goals and prioritize their efforts.\nThus, if your organization is working to understand the maturity of your ICS security program, my recommendation is that you come up with a hybrid model for gathering information and grading methodology that fits your organization and your team. Then, get buy-in from your direct leadership. You do not want buy-in from everyone as that will drag out forever. But, with buy-in from your direct leadership you have someone that will go-to-bat for you and say, \u0026ldquo;This is our approach, please play along.\u0026rdquo; Leaving you to gather information rather than selling the approach to other teams.\nWrap-up # I\u0026rsquo;m open to any improvement on my grades and this approach. Please reach out here or directly.\nFor ICS team members that need help understanding these concepts, I recommend your organization considers sending team members to the SANS ICS410: ICS/SCADA Security Essentials course. I am an instructor of this course and I feel that ICS team members do gain enough knowledge from the course content to effectively participate in an honest evaluation of the security programs within their ICS environments.\nGo forth and do good things,\nDon C. Weber\nCutaway Security, LLC.\nEmail: don@cutawaysecurity.com\nWebsite: http://www.cutawaysecurity.com\nTwitter: https://twitter.com/cutaway\nSANS Instructor: https://www.sans.org/instructors/don-c-weber\nReferences # [0] https://www.energy.gov/ceser/activities/cybersecurity-critical-energy-infrastructure/energy-sector-cybersecurity-0-0\n[1] https://www.energy.gov/sites/prod/files/2014/03/f13/C2M2-v1-1_cor.pdf\n[2] https://www.cisecurity.org/controls/\n[3] https://www.iiconsortium.org/pdf/IoT_SMM_Practitioner_Guide_2019-02-25.pdf\n[4] https://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx\n[5] https://www.nist.gov/cyberframework\n[6] https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx\n[7] https://www.sans.org/course/ics-scada-cyber-security-essentials\n[8] https://www.sans.org/instructors/don-c-weber\n","date":"August 29, 2019","externalUrl":null,"permalink":"/blog/conducting-security-program-maturity-evaluations-of-ics-environments/","section":"Blog","summary":"This article was originally published on Linked In on July 29, 2019.\nICS Security Programs # The implementation and security of Industrial Control Systems (ICS) in business environments is challenging. Most organizations start with legacy environments or build new solutions with process effectiveness as their priority. Once an organization realizes they need to secure the environment they quickly come to the conclusion that their enterprise security program does not easily fit into the primary goals and requirements of the ICS environment. Thus, they need a method to evaluate their current security posture and identify a path forward that is prioritized to the goals of the process(es).\n","title":"Conducting Security Program Maturity Evaluations of ICS Environments","type":"blog"},{"content":" About Cutaway Security # Cutaway Security, a veteran-owned company, delivers comprehensive ICS/OT cybersecurity program evaluations and vulnerability assessments. Our seasoned industrial cybersecurity professionals specialize in OT risk management and ICS vulnerability assessments, establishing a solid foundation by understanding your critical assets, personnel, and business objectives. We leverage real-world experience in active production environments to accurately scope and execute your OT security program initiatives. Our services include ICS architecture reviews, OT security program maturity assessments, control environment security assessments, ICS penetration testing, SCADA security assessments, detailed analysis of critical infrastructure cybersecurity needs, and cybersecurity program evaluation using the NIST Cybersecurity Framework (CSF). Whether you require ISA/IEC 62443 gap analysis, focused ICS threat detection strategies, or OT network penetration testing, Cutaway Security is ready to strengthen your industrial automation and control systems (IACS) security posture.\nOur Mission # Our mission is to \u0026ldquo;Go forth and do good things.\u0026rdquo; We want to make a positive difference in every friendship and relationship we develop. We are all in this together and we are stronger when we communicate well and take care of each other. We will strive to take care of our team, our families, and to grow our relationships to broaden our circle and set the example. - Don C. Weber\n","externalUrl":null,"permalink":"/about/","section":"About","summary":"About Cutaway Security # Cutaway Security, a veteran-owned company, delivers comprehensive ICS/OT cybersecurity program evaluations and vulnerability assessments. Our seasoned industrial cybersecurity professionals specialize in OT risk management and ICS vulnerability assessments, establishing a solid foundation by understanding your critical assets, personnel, and business objectives. We leverage real-world experience in active production environments to accurately scope and execute your OT security program initiatives. Our services include ICS architecture reviews, OT security program maturity assessments, control environment security assessments, ICS penetration testing, SCADA security assessments, detailed analysis of critical infrastructure cybersecurity needs, and cybersecurity program evaluation using the NIST Cybersecurity Framework (CSF). Whether you require ISA/IEC 62443 gap analysis, focused ICS threat detection strategies, or OT network penetration testing, Cutaway Security is ready to strengthen your industrial automation and control systems (IACS) security posture.\n","title":"About","type":"about"},{"content":"For inquiries about cybersecurity consulting, training, or other services, please reach out:\nEmail: info@cutawaysecurity.com\nGitHub: cutaway-security\nLinkedIn: Cutaway Security\nYouTube: Cutaway Security\n","externalUrl":null,"permalink":"/contact/","section":"Contact","summary":"For inquiries about cybersecurity consulting, training, or other services, please reach out:\nEmail: info@cutawaysecurity.com\nGitHub: cutaway-security\nLinkedIn: Cutaway Security\nYouTube: Cutaway Security\n","title":"Contact","type":"contact"},{"content":"Welcome to the CutSec SANS ICS410 resources page. These are just a few extra online resources and items that didn\u0026rsquo;t make it into the class. We hope these help your ICS / OT cybersecurity journey. Contact us if you have something to add or a suggestion.\nQuick Reference Links # Dragos 2025 Year In Review Report - an extremely important representation of the state of many sectors related to ICS/OT cybersecurity. Updated BP Texas City Animation on the 15th Anniversary of the Explosion 1947: Texas City Disaster Part 1 55 gallon steel drum can crush using atmospheric pressure Social Engineering - Reporter Gets Mobile Account Hacked S4 Conference Videos: S4Events Youtube SANS ICS Videos: YouTube Op de Schouders van Reuzen (On the Shoulders of Giants - The six storm surge barriers of Rijkswaterstaat) - In Dutch CISA Known Exploited Vulnerabilities (KEV) ICS Advisory Project - CVE-CPEs Dashboard Free 8 hour Linux Basics Course Industrial Control Systems - Understanding ICS Architectures by Chris Sistrunk A microsecond is 1/1000th of a millisecond (1000 us = 1 ms) Certification Study Links # Leslie Carhart guide to taking SANS test: Better GIAC Testing with Pancakes Matthew Toussain - Get Certified! All You Need to Know to Rock GIAC Exams Matthew Toussain - Wargaming GIAC Certifications Matthew Toussain - Rocking the GIAC Exam with Voltaire Matthew Toussain - Voltaire (Index building App) Anki Powerful Flash Cards Develop Technical Recall Skills: Spaced Repetition with Anki Ron Hamann - Are You Certifiable? | SANS@MIC Talk Books # The Cuckoo\u0026rsquo;s Egg by Cliff Stoll Countdown to Zero Day by Kim Zetter Stuxnet Documentary \u0026ldquo;Zero Days\u0026rdquo; - this movie has been moved to pay-per-view Sandworm by Andy Greenberg Important OT Podcasts, Talks, and Interviews # OT Under Threat: Dragos\u0026rsquo; Robert M. Lee on Navigating Cyber-Physical Risks Water Sector Cyber Risk with Gus Serino Killing Time - SANS ICS Security Summit 2021 with Jeff Shearer Triton - A Report From The Trenches with Julian Gutmanis FuxNet: The New ICS Malware that Targets Critical Infrastructure Sensors with Noam Moshe General Topic Links # Differences between SCAP and STIGs Wireshark OUI Lookup Tool CISA Network Architecture Verification and Validation (NAVV) INL Consequence-driven Cyber-informed Engineering (CCE) Google Learn Computer Networking Free Course CISA ICS Training Resources Information Trust Institute (ITI) ICS Security Tools GitHub Original Sheep-Dip Project Equipment Links # Remote / Onsite Security Assessment Jumpkit - I started documenting my equipment in 2019. I\u0026rsquo;ll try to keep this up-to-date. Feel free to submit a Community Case to the project. Essentials for Your ICS Incident Response Jump Bag - Dean Parson\u0026rsquo;s brief on essential items for your ICS IR jump bag. Purdue Level 0/1 Links # Image of an old relay setup to help understand where Ladder Logic came from. Modernizing Hardwired Relay Logic With PLCs Forescout OT:ICEFALL Report Velocio Datasheet Industrial Protocols and Ports More Industrial Protocols and Ports Top 20 Secure PLC Coding Practices Comparison of Real-Time Operating Systems (RTOS) Simply Modbus How to Analyze I2C - Saleae Support Remote Terminal Units (RTUs) based on SIMATIC Introduction to Yokogawa DCS DNP3 vs IEC104 vs IEC61850 Choosing the Best Communication Protocol: DNP3 vs IEC 61850 Hardware Hacking Class: ControlThings.io Accessing and Exploiting Control Systems and IIoT Riverloop Hardware Hacking Dumping EMMC Flash Introduction to JTAG Communicating with JTAG via OpenOCD Hacking The Xbox Wireshark and Fieldbus Protocols OPC DA DCOM Port Range Restrictions Microsoft Tech Blog - RPC/DCOM port ranges are more limited after win2008 (49152-65535) OPC Expert OPC Training Institute How Relays Work - Basic working principle SEL RTAC Security - Leveraging Security \u0026ndash; Using the SEL RTAC\u0026rsquo;s Built-In Security Features IAEI Blog describing Timing Considerations for Arc Flash Protections - Key Considerations for Selecting an Arc-Flash Relay Attack Consequence Videos # United States Chemical Safety and Hazard Investigation Board YouTube Awareness Videos Hydrocarbon Release Hazard Awareness Animation of Bayer CropScience Pesticide Waste Tank Explosion Attacks on Remote Sites # General # Aurora Attack - Staged cyber attack reveals vulnerability in power grid Repository of Industrial Security Incidents Database - last updated on January 28, 2015 Dallas Emergency Sirens Activated in 2017 via UHF 450MHz radio signal. Water # US Moves to Shield Drinking Water Maroochy Water Services Attack (Insider Threat) MITRE Malicious Control Systems Cyber Security Attack Case Study - Maroochy Water Services, Australia Maroochy Water Breach YouTube Video Maroochy Shire Sewage Spill CISA Exploitation of Unitronics PLCs used in Water and Wastewater Systems Hackers breach US water facility via exposed Unitronics PLCs Iran-Backed Cyber Av3ngers Escalates Campaigns Against U.S. Critical Infrastructure Norwegian police say pro-Russian hackers were likely behind suspected sabotage at a dam Electrical # Sektor CERT - The attack against Danish critical infrastructure Watch How Hackers Took Over a Ukrainian Power Station - HMI attack on power substation The story of Jason Woodring, the Arkansas power grid vandal Why the US Power Grid Is Under Attack California Man Arrested for Transformer Bombings Smart Meters in Puerto Rico Hacked Nuclear # Can you HEAR Stuxnet damaging centrifuges at Natanz? Rail # Polish Teen Hacks Tram in 2008 The Cheap Radio Hack That Disrupted Poland\u0026rsquo;s Railway System Ports # Inside Job: How a Hacker Helped Cocaine Traffickers Infiltrate Europe\u0026rsquo;s Biggest Ports (Insider Threat) Food/Beverage # Caught in the cyber crosshairs: A candy manufacturer\u0026rsquo;s 2025 ransomware ordeal - Ganong Bros. ICS Vendor # Sensata Technologies\u0026rsquo; operations disrupted by ransomware attack Physical Security Links # The White House: National Strategy for Physical Protection of Critical Infrastructure CISA Cybersecurity and Physical Security Convergence Action Guide CISA SECTOR SPOTLIGHT: Electricity Substation Physical Security CutSec Blog: ICS/OT Cybersecurity Self Analysis \u0026ndash; Physical Security Light Water Reactor Sustainability (LWRS) INL Risked Informed Physical Security Physical Security Resources Public Health Emergency (PHE): Physical Security Managing Your IR Efforts # What are your goals? What questions help you achieve your goals? What data would answer those questions? How do you acquire that data? Incident Response Table Top Links # CISA Tabletop Exercise Packages (CTEPs) CISA ICS Training Dean Parson\u0026rsquo;s ICS Incident Response Tabletops Lenny Zeltser Cheat Sheets and Presentations NERC\u0026rsquo;s Grid Security Exercise (GridEx) MITRE Cyber Exercise Playbook Black Hills Information Security (BHIS) Backdoors and Breaches BHIS ICS/OT Backdoors and Breaches Center for Internet Security: Tabletop Exercises - Six Scenarios Red Canary: Are You Using Tabletop Simulations to Improve Your Information Security Program? Dragos Preparing for Industrial Cyber Response Dragos Preparing for Incident Handling and Response in ICS Dragos Tabletop Exercise ICS4ICS Incident Command System for Industrial Control Systems European Network for Cyber security (ENCS) Red Team - Blue Team Training Ron Hammond Presentation: You want ME to run a tabletop?: Slides STOic TTX Youtube Playlist: Videos Velocio and PLC Links # Velocio PLC Teardown/Review Velocio Youtube Channel Velocio Tutorials Learning PLCs on a Budget CLICK PLC Hardware: The Best PLC for Everyday Control Systems Needs Virtual Cyber Ranges: Thomas Van Norman Network Links # Wireshark OUI Private VLANs Multicast Addresses IANA Multicast Address Space Radio Links # GRC Transmission Analysis: Getting To the Bytes - how-to use Gnu-Radio to get data out of transmissions. Software Defined Radio with HackRF Lessons - free radio courses that take a deep dive into radio theory. MouseJack - CrazyRadio PA - keyboard and mouse interception and injection project. Flipper Zero Great Scott Gadgets HackRF PortaPack Versions Hak5 WiFi Pentesting - Lots of wireless tools Field Expedient SDR - book about Gnu Radio Companion and radio theory basics. LoRa and LoRaWAN Project PowerUp \u0026ndash; Helping to keep the lights on in Ukraine in the face of electronic warfare (GPS related) Satellite attack write-ups A Wake-up Call for SATCOM Security (April 2014) Last Call for SATCOM Security (Aug 2018) Missed Calls for SATCOM Cybersecurity (March 2022) VIASAT incident: from speculation to technical details (March 2022) Update on SATCOM Terminal Attacks During the War in Ukraine (May 2022) Remote Access Links # Just a few solutions to help start research into remote access solutions. These are not a recommendation, just links to the solutions.\nBeyond Trust Privileged Access Management Zscalar Secure Remote Access NBAD / Asset Management Links # Just a few solutions to help start research into asset management and Network Behavior Anomaly Detection (NBAD) solutions. These are not a recommendation, just links to the solutions.\nPAS Automation Asset Management Hexagon Asset Lifecycle Information Management Claroty Integrated and Comprehensive IoT-OT Security Dragos Industrial Cybersecurity Platform Nozomi Automating My Asset Inventory Otorio RAM^2 Asset Inventory Management Armis Cybersecurity Asset Management Tenable Tenable.OT Software Bill of Materials (SBOM) Links # Just a few solutions to help start research into Software Bill of Materials (SBOM) solutions. These are not a recommendation, just links to the solutions.\nAdolus Technology OT and IoT Supply Chain Security NetRise Firmware Security Cybeats SBOM Studio Finite State End-to-end SBOM Solutions Security Risk Advisors Cyber Physical Systems Security Josh Wright Links # Will Hack For SUSHI Essential Crypto for Pen Testers (Without the Math!) PcapHistogram Python Version Jason Larsen Videos # 14 Hours and a Power Grid: BSides Track 2 14 Hours and a Power Grid: S4Events Rocking the Pocket Book: Hacking Chem Plants: DEFCON 23 - Krotofil, Larsen Remote Physical Damage from Jason Larsen of IOActive - 55 gallon barrel implosion Monta Elkins # Hackers in your power tools and other unexpected places - news article about hacking hardware to demonstrate control of the device. Hacking firmware where you least expect it: in your tools - presentation about hardware hacking Justin Searle Videos # Dealing with Remote Access to Critical ICS Infrastructure Paul Piotrowski Links # ICS 410 Supplementary Practice Slides Duke fined $10M for cybersecurity lapses since 2015 MIT-HACK: Tetris at the MIT Green building Mike Hoffman Videos # Gaining Endpoint Log Visibility in ICS Environments Don C. Weber Videos # SANS Instructor Spotlight - Don C. Weber SANS ICS Videos: YouTube SANS@MIC - Pen Testing ICS and Other Highly Restricted Environments SANS Webcast (registration required) - Securing ICS Using the NIST Cybersecurity Framework and Fortinet: Best Practices for the Real World SANS Webcast (registration required) - Yes, IT and OT Are Converging So How Does This Affect Compliance DEF CON 20 - Cutaway - Looking Into The Eye Of The Meter Black Hat USA 2012 - Looking into the Eye of the Meter Podcasts # @BEERISAC - a consolidation of ICS / OT podcasts Unsolicited Response Podcast The CyberWire Darknet Diaries Malicious Life TShark Commands # Industrial Control Protocols # Purpose:\nIdentify master servers and client / slaves Identify common protocols in use by master servers Also want to identify proprietary protocols in use, but this will be more difficult as Wireshark / Tshark may not have protocol dissectors for their identification and analysis. # Modbus ## Masters tshark -n -Y \u0026#34;mbtcp \u0026amp;\u0026amp; tcp.dstport == 502\u0026#34; -T fields -e ip.src -r \u0026lt;file.pcap\u0026gt; | sort | uniq ## Masters with function codes tshark -n -Y \u0026#34;mbtcp \u0026amp;\u0026amp; tcp.dstport == 502\u0026#34; -T fields -e ip.src -e modbus.func_code -r \u0026lt;file.pcap\u0026gt; | sort | uniq ## Slaves tshark -Y \u0026#34;mbtcp \u0026amp;\u0026amp; tcp.dstport == 502\u0026#34; -T fields -e ip.dst -e eth.dst -r \u0026lt;file.pcap\u0026gt; | sort | uniq ### Note: The OUI hardware address does not resolve for field outputs. You have to check them yourself. tshark -Y \u0026#34;mbtcp \u0026amp;\u0026amp; tcp.dstport == 502\u0026#34; -T fields -e ip.dst -r \u0026lt;file.pcap\u0026gt; | sort | uniq | wc -l # Aveva / WonderWare SuiteLink ## Servers tshark -Y \u0026#34;tcp.dstport == 5413\u0026#34; -T fields -e ip.dst -r \u0026lt;file.pcap\u0026gt; | sort | uniq ## Clients tshark -Y \u0026#34;tcp.dstport == 5413\u0026#34; -T fields -e ip.src -r \u0026lt;file.pcap\u0026gt; | sort | uniq # Aveva / WonderWare InBatch ## Servers tshark -Y \u0026#34;tcp.dstport \u0026gt;= 9000 \u0026amp;\u0026amp; tcp.dstport \u0026gt;= 9015\u0026#34; -T fields -e ip.dst -r \u0026lt;file.pcap\u0026gt; | sort | uniq # Clients tshark -Y \u0026#34;tcp.dstport \u0026gt;= 9000 \u0026amp;\u0026amp; tcp.dstport \u0026gt;= 9015\u0026#34; -T fields -e ip.src -r \u0026lt;file.pcap\u0026gt; | sort | uniq # BACnet ## I-Am responses to Who-Is - sorted by source IP address tshark -d udp.port==47809,bvlc -Y \u0026#39;bacapp.unconfirmed_service == 0\u0026#39; -T fields -e ip.src -e bacapp.instance_number -e bacnet.sadr_mstp -e bacnet.snet -E separator=, -r \u0026lt;file.pcap\u0026gt; | sort | uniq | sort -g -t. -k 1,1 -k 2,2 -k 3,3 -k 4,4 ## Device Count BACnet source tshark -d udp.port==47809,bvlc -Y \u0026#39;bacnet\u0026#39; -T fields -e ip.src -e ip.dst -r \u0026lt;file.pcap\u0026gt; | grep -v \u0026#39;,\u0026#39; | sort | uniq \u0026gt; \u0026lt;file.pcap\u0026gt; ### NOTE: The resulting file still needs to be counted. Probably best to export Wireshark filtered communications to an MS Excel file and do a pivot table. ","externalUrl":null,"permalink":"/ics410/","section":"ICS410","summary":"Welcome to the CutSec SANS ICS410 resources page. These are just a few extra online resources and items that didn’t make it into the class. We hope these help your ICS / OT cybersecurity journey. Contact us if you have something to add or a suggestion.\n","title":"ICS410","type":"ics410"},{"content":"Getting started in cybersecurity is a challenge. Starting your journey in ICS / OT cybersecurity can be a bigger challenge. In both cases your education and journey are yours to define.\nAI Help # Getting information about reading lists and setting up training programs are an excellent use of AI resources. Here are two simple queries I did about mentoring. Update queries these to set your path and manage your journey.\nChatGPT Mentor Resources Conversation Gemini Career Gem ICS/OT Cybersecurity Training Schedule General Cybersecurity Resources # Communities # BHIS Discord Red Siege Discord VetSec Training # SANS Training SANS University - following the degree path is MUCH more cost effective Chris Sanders Training Secure Ideas Training - Free for veterans, tell them you are a vet. Pico CTF HackTheBox Holiday Hack Challenge Past Challenges Network Analysis Challenges ICS/OT Cybersecurity Resources # Reading # Cutaway Security ICS410 Page Rob M. Lee\u0026rsquo;s Reading List Dragos\u0026rsquo; Reading List Mike Holcomb\u0026rsquo;s Reading List: 2024 LinkedIn Post 2025 LinkedIn Post Mike\u0026rsquo;s GitHub with more resources SANS ICS Whitepapers Information Trust Institute (ITI) ICS-Security-Tools Communities # CutSec Discord ControlThings Discord Friends of Beer-ISAC PLC Discord Training # SANS ICS Courses ControlThings.io Courses Mike Holcomb\u0026rsquo;s YouTube Training Series NOTE: if the Discord links are not active (some have 7-day time limits) then locate someone on LinkedIn that is a member of that community and ask them for an updated link.\n","externalUrl":null,"permalink":"/mentoring/","section":"Mentoring","summary":"Getting started in cybersecurity is a challenge. Starting your journey in ICS / OT cybersecurity can be a bigger challenge. In both cases your education and journey are yours to define.\n","title":"Mentoring","type":"mentoring"},{"content":"Open-source tools and research from Cutaway Security, built to help operational teams solve real problems in industrial and control system environments. All projects are freely available on our GitHub organization.\n","externalUrl":null,"permalink":"/projects/","section":"Projects","summary":"Open-source tools and research from Cutaway Security, built to help operational teams solve real problems in industrial and control system environments. All projects are freely available on our GitHub organization.\n","title":"Projects","type":"projects"},{"content":" Presentations and White Papers # SANS White Paper: Effective Implementation of the NIST Cybersecurity Framework with Fortinet # Cutaway Security has teamed up with the SANS Vendor: Analyst Program and Fortinet to produce the white paper \u0026ldquo;Effective Implementation of the NIST Cybersecurity Framework with Fortinet.\u0026rdquo; This paper, written by Don C. Weber, is a product overview that looks at one approach to updating an ICS network by leveraging a combination of the National Institute of Standards and Technology (NIST) Cyber Security Framework (CSF), the SANS ICS410 Reference Architecture model, and Fortinet Security Fabric technologies. It examines some of the tactical choices a team can make when addressing security concerns within an ICS environment and explores how some of Fortinet\u0026rsquo;s product line could assist with these tactical decisions.\nThis paper is a companion piece to the implementation guide \u0026ldquo;Security by Design: A Systems Road Map Approach,\u0026rdquo; written by Barbara Filkins.\nSecuring ICS Using the NIST Cybersecurity Framework and Fortinet: Best Practices for the Real World # Cutaway Security teamed with the SANS Analyst Program and Fortinet to discuss \u0026ldquo;Securing ICS Using the NIST Cybersecurity Framework and Fortinet: Best Practices for the Real World.\u0026rdquo; This webcast featured Barbara Filkins, Don C. Weber, and Peter Newton.\nConference Presentations # Wild West Hacking Fest 2019: Architecting Secure ICS Environments # Presented at Wild West Hacking Fest 2019 in Deadwood, SD on Oct 24, 2019.\nCriminals are hacking Industrial Control Systems (ICS). Their motivations are as diverse as the environments where ICS solutions and devices are found. Businesses are taking notice and asking the hard question: \u0026ldquo;how do we secure systems that are intended to run continuously?\u0026rdquo; The personnel operating these environments need to understand IT security as much as IT security professionals need to understand the concepts and requirements of an ICS implementation. The purpose of this presentation will be to, briefly, introduce the concepts and security considerations for ICS devices and solutions.\nPen Test HackFest 2019: Pen Testing ICS and Other Highly Restricted Environments # Presented at Pen Test HackFest Summit 2019 in Bethesda, MD on Nov 18-19, 2019.\n\u0026ldquo;Congratulations, you have been selected to conduct a penetration test of our industrial control system (ICS) environment. Please remember, you cannot scan anything, you cannot install anything, and you cannot break anything.\u0026rdquo; This is not a joke. More and more companies are requesting penetration tests of their ICS assets. This presentation discusses how to scope and conduct this type of assessment.\nSlide Decks # CutSec WWHF 2019 - Architecting Secure ICS Environments SANS @Night - Assessments in Active ICS Environments CutSec Hackfest November 2019 WWHF 2020 - Analyzing Radio Transmissions Using URH ","externalUrl":null,"permalink":"/publications/","section":"Publications","summary":"Presentations and White Papers # SANS White Paper: Effective Implementation of the NIST Cybersecurity Framework with Fortinet # Cutaway Security has teamed up with the SANS Vendor: Analyst Program and Fortinet to produce the white paper “Effective Implementation of the NIST Cybersecurity Framework with Fortinet.” This paper, written by Don C. Weber, is a product overview that looks at one approach to updating an ICS network by leveraging a combination of the National Institute of Standards and Technology (NIST) Cyber Security Framework (CSF), the SANS ICS410 Reference Architecture model, and Fortinet Security Fabric technologies. It examines some of the tactical choices a team can make when addressing security concerns within an ICS environment and explores how some of Fortinet’s product line could assist with these tactical decisions.\n","title":"Publications","type":"publications"},{"content":"Cutaway Security specializes in scoping and leading cybersecurity engagements for industrial and operational technology environments. Every engagement is tailored to your operational constraints, safety requirements, and business objectives.\nSecurity Assessments # Comprehensive evaluations of your ICS/OT environment, delivered with respect for continuous operations and operational safety. Engagements are aligned with industry standards including ISA/IEC 62443, NIST CSF, and the SANS ICS Five Critical Controls. We specialize in scoping and leading these engagements \u0026ndash; ensuring they produce findings that feed directly into your vulnerability management and risk analysis programs.\nArchitecture ReviewsEvaluation of network segmentation, data flow, trust boundaries, and defensive posture. We identify gaps and recommend improvements aligned with your business needs and operational realities.\nPenetration TestingAuthorized offensive testing conducted with careful scope, continuous coordination, and respect for operational safety. Includes assumed breach assessments, M\u0026amp;A analysis, and ICS-specific techniques.\nMaturity AssessmentsStructured evaluation of your security program to identify gaps, measure progress, and prioritize strategic improvements. We bring the perspective and time your team needs.\nBench TestingHands-on analysis of specific devices, firmware, and protocols in a controlled lab environment. Draws from the methodologies taught in SANS ICS613.\nSecurity Research # We conduct targeted research into device capabilities and the protocols used in industrial environments \u0026ndash; both open standards and proprietary implementations. This research serves two purposes:\nDiscovering vulnerabilities and documenting detection methods. Findings feed directly back into assessment engagements, training, and the broader ICS/OT community. Developing specialized open-source tools that help operational teams solve real problems. Our tools are designed to save cost, reduce manual effort, and improve visibility. All projects are freely available on our GitHub organization. See our Projects page for the full catalog.\nTraining # Knowledge starts with exposure to information and consistent application over time. We participate in SANS, ControlThings.io, and ICS Village training programs to educate and empower your team. We also provide specialized training to meet your team\u0026rsquo;s information security goals.\nICS410SANS ICS/SCADA Security Essentials course resources and supplementary materials.\nWorkshopsHands-on workshops on OT OSINT and industrial AI programming, delivered at SANS Summits and ICS Village.\nPublicationsPress, presentations, slide decks, and white papers from Cutaway Security engagements.\n","externalUrl":null,"permalink":"/services/","section":"Services","summary":"Cutaway Security specializes in scoping and leading cybersecurity engagements for industrial and operational technology environments. Every engagement is tailored to your operational constraints, safety requirements, and business objectives.\nSecurity Assessments # Comprehensive evaluations of your ICS/OT environment, delivered with respect for continuous operations and operational safety. Engagements are aligned with industry standards including ISA/IEC 62443, NIST CSF, and the SANS ICS Five Critical Controls. We specialize in scoping and leading these engagements – ensuring they produce findings that feed directly into your vulnerability management and risk analysis programs.\n","title":"Services","type":"services"},{"content":" SANS Courses # Cutaway Security participates in SANS training programs. Our primary course is ICS410: ICS/SCADA Security Essentials. Visit the SANS website for current schedules and registration, and see the ICS410 resources page for supplementary course materials.\nWorkshops # Hands-on workshops delivered at industry events including the SANS ICS Security Summit and ICS Village at DEF CON.\nOT OSINT WorkshopOpen Source Intelligence techniques applied to OT and industrial environments. Discover exposed assets, identify vendor indicators, and understand what adversaries can gather before touching the network.\nOT OSINT Program WorkshopProgram-building workshop for organizations establishing an internal OSINT capability for OT. Covers scoping, tooling, process design, and integration with security operations.\nIndustrial AI ProgrammingUsing AI coding techniques to accelerate PLC analysis, protocol research, and ICS/OT security tool development within industrial environment constraints.\nTo bring a workshop to your event or team, contact us.\nUpcoming Events # Check LinkedIn for the latest schedule of upcoming training events and workshop appearances.\n","externalUrl":null,"permalink":"/training/","section":"Training","summary":"SANS Courses # Cutaway Security participates in SANS training programs. Our primary course is ICS410: ICS/SCADA Security Essentials. Visit the SANS website for current schedules and registration, and see the ICS410 resources page for supplementary course materials.\n","title":"Training","type":"training"}]