All posts by Isiah Jones, MPS, CISSP, GICSP, C|CISO, VP, Global ICS Security Service Delivery

Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.

Security Practices for IEC 61131-3 PLC Programming Languages Part 5: ST

By Isiah Jones VP, Global ICS Security Service Delivery & Brian Foster Sr ICS Cybersecurity Engineer

Within the industrial control systems (ICS), automation, operational technology (OT), cyber-physical systems (CPS), industrial internet of things (IIoT) and instrumentation communities many of the devices with some form of computing and logical capabilities rely on 5 primary programming languages specific to programmable logic controllers (PLCs) that are defined in IEC 61131-3 as Sequential Function Chart (SFC), Ladder Diagram aka Ladder Logic (LD), Function Block Diagram (FBD), Instruction List (IL) and Structure Text (ST). In the IT community OWASP, NIST, SANS, CMMI, ISC2 and EC-Council, among others, have already created secure coding and secure development guidelines, best practices, testing tools and tips for higher level languages such as C, C++, Java, Python, JSON, HTML, XML, SQL and others. Some could argue that Structure Text includes several of these high-level languages. However, there has not been much focus by international standards organizations or industry experts on implementing security within the other 4 primary PLC focused languages in ICS. As a result, we wanted to share some of our recommendations for each of the IEC 61131-3 PLC languages in a 5-part blog series and aggregated white paper. In part 1 of our series we focused on Sequential Function Chart (SFC), part 2 focused on Ladder Diagram or Ladder Logic (LD), part 3 focused on Function Block Diagram (FBD) and in part 4 we focused on Instruction List (IL). Here in part 5 we will finish off the series with Structure Text (ST).

Structure Text

If you are used to standard higher-level computer programming languages than you will already understand Structure Text (ST). ST is generally a C based programming language, but you can use languages such as python as well to create code for structure text. ST in some programming environments ST has built in objects that you can call the same way you would in LD or FBD. In some environments you can have ST called within function blocks and steps within SFC as well. With ST comes some of the more traditional programming attack surface such as buffer threats, input validation, logic threats and code processing overhead.

Recommended Practices

Within ST we believe the below recommended practices would improve the secure design and usage of ST within ICS devices by adding security, safety and resilience supportive concepts within the ST logic for all devices and operations that operate using ST. These recommended practices are in no particular order and this is not an all-inclusive list.

  • Keep operational PLCs in run mode. This prohibits changes to the logic. It is often only changeable with physical access to the PLC. While this cannot prevent flaws in the code from being exploited it will stop the changing of the code by anyone who does not have physical access to the PLC.
  • Keep all logic well documented and commented. This makes identifying rouge code easier, but also helps with day to day troubleshooting. The next person to work on the logic should always be able to understand what the last person did.
  • Implement a code reuse library of fuzzed and regression tested clean code. This is especially important for creating reusable functions, classes, methods, variables, data dictionaries etc that can be leveraged on new projects.
  • Implement OWASP, NIST and CMMI secure coding practices such as escaping unnecessary characters, buffer management, session management, lifecycle design principles etc. Ensure these principles are also documented and tested by a separate person than the person who wrote the original code.
  • Leverage the prebuilt functions and tag types in the programming platform of your choice such as RSLogix 5000. This enforces a consistent programming format rather than each developer creating their own from scratch such as one shots, timers, counters, PID etc
  • Create documented programming standards to ensure third parties and internal programmers follow same formats, code reuse library repository of tags, functions, variable nomenclature etc.
  • Create custom alarming, notification and input validation and alerting program files that capture unwanted, unexpected and unauthorized inputs, outputs, logic modifications etc. Have your main program call or point to the custom alarms, notification and events program.
  • Ensure you include thorough acceptance testing and user testing in your project timeline. This should include changes to code and integration of multiple languages such as calls between ST, LD, FBD, SFC, IL etc.
  • Create and enforce a check-in and check-out of code process. Leverage such features in products such as Rockwell Automation’s FactoryTalk suite integration with RSLogix.
  • Be sure to keep ST as simple as possible. Do not create more code and attack surface than necessary to execute tasks. Leverage built in objects and functions as much as possible rather than creating all custom ST when not necessary. Use the built in C syntax and libraries within the programming tools you are using that are compatible with the PLC, RTU, programmable relay etc. as much as possible before deviating to create your own custom code to perform the same actions.

Conclusion

We know there are many more possible best practices and recommendations that experienced individuals within the community can come up with. We wanted to be part of increasing the conversation for the creation of some formalized and well documented best practices guidelines for each of the 5 IEC 61131-3 PLC languages. Now that we are at the end of this series we will work to consolidate this 5-part series into a future PLC programming whitepaper for the community.  We hope the community enjoyed this series and continue to encourage others to contribute as well.

Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.

Security Practices for IEC 61131-3 PLC Programming Languages Part 3: FBD

By Isiah Jones VP, Global ICS Security Service Delivery & Brian Foster Sr ICS Cybersecurity Engineer

Within the industrial control systems (ICS), automation, operational technology (OT), cyber-physical systems (CPS), industrial internet of things (IIoT) and instrumentation communities many of the devices with some form of computing and logical capabilities rely on 5 primary programming languages specific to programmable logic controllers (PLCs) that are defined in IEC 61131-3 as Sequential Function Chart (SFC), Ladder Diagram aka Ladder Logic (LD), Function Block Diagram (FBD), Instruction List (IL) and Structure Text (ST). In the IT community OWASP, NIST, SANS, CMMI, ISC2 and EC-Council, among others, have already created secure coding and secure development guidelines, best practices, testing tools and tips for higher level languages such as C, C++, Java, Python, JSON, HTML, XML, SQL and others. Some could argue that Structure Text includes several of these high-level languages. However, there has not been much focus by international standards organizations or industry experts on implementing security within the other 4 primary PLC focused languages in ICS. As a result, we wanted to share some of our recommendations for each of the IEC 61131-3 PLC languages in a 5-part blog series and aggregated white paper. In part 1 of our series we focused on Sequential Function Chart (SFC) and in part 2 we focused on Ladder Diagram or Ladder Logic (LD). Here in part 3 we will focus on Function Block Diagram (FBD).

Function Block Diagram

Function Block Diagram or FBD is a graphical language that allows you to create blocks of functions that group relationships between inputs and outputs. Various data types and mathematical functions are grouped into a block and the inputs and outputs state or condition is altered based on the function of the block. Each block has a symbol that represents a function such as OR which is represented by the symbol “ >=1” for example. The inputs and outputs from one block can be linked to another block enabling a graphical flow that shows the path that an input of one data type takes through a program, processed by different functions until it reaches a final output to achieve the purpose of the program and the overall designed process. The blocks themselves and linking various types of blocks together enables users to create very complex logic in a very graphical easy to follow manner.

Recommended Practices

Within FBD we believe the below recommended practices would improve the secure design and usage of FBD within ICS devices by adding security, safety and resilience supportive concepts within the FBD logic for all devices and operations that operate using FBD. These recommended practices are in no particular order and this is not an all-inclusive list.

  • Keep operational PLCs in run mode. This prohibits changes to the logic. It is often only changeable with physical access to the PLC. While this cannot prevent flaws in the code from being exploited it will stop the changing of the code by anyone who does not have physical access to the PLC.
  • Keep all logic well documented and commented. This makes identifying rouge code easier, but also helps with day to day troubleshooting. The next person to work on the logic should always be able to understand what the last person did.
  • Build a library of tested and approved safe functions and enforce a check in and check out programming methodology for projects where FBD is the language of choice. This creates a baseline of expected functions for your projects and prevents unwanted or unexpected errors or events from occurring due to a new programmer or malicious actor from introducing functions that weren’t already vetted.
  • Keep it minimal. Do not over complicate networks and reduce the number of objects if possible. Good engineering stands out because it is simple, efficient, and easy to follow. It will make troubleshooting easier, reliability higher, and malicious modification harder to hide.
  • Be consistent. If configurable use the same fonts, color schemes, perspective, whitespace, and flow. Let the picture tell your story. Good consistent visual appearance and layout of the FBD help organize it in a logical and efficient manner.
  • Create standards that define data types, tag libraries, naming conventions, comments, symbols, alarms, notifications, mandatory vs optional functions etc. Having a standard enables the asset owners and all other stakeholders to build all projects from a common baseline or sheet of music. Examples being red vs green alarms. Which is good, and which is bad? Some folks have red alarms as good normal state condition and green means something is wrong. Others follow green is good, red is bad. Regardless have a documented standard on each project and for each system. Which alarms will be outputs of which functions, how and why should all be in the standard.
  • Ensure alarms and notifications library and screens that alert operators when the incorrect values and or data types are used. This could detect code changes, errors in code, tampering by an actor or an unexpected malfunction. The more you account for being able to track or flag anomalies the greater the chances of users having an early warning that something is wrong with equipment or the process.
  • Leverage sub out and sub in objects to pass intended logic through validation logic to trigger alarms and notifications whenever the expected values do not match the functions used in the logic and or could indicate that inputs or outputs have been altered in some way or that new functions and or connections have been made to the expected logic blocks.
  • Leverage alarm and notification functions to create classes and levels of alarms and notifications specifically to trigger unexpected, unsafe, anomalous, unauthorized behaviors and conditions that can then be set on a suspicious and unauthorized activity specific HMI screen and forwarded to a centralized alerting and monitoring platform for ICS events.
  • Whenever possible use more advanced programming tools such as RSLogix 5000 instead of 500. The advanced tools are more expensive, but they support more of the IEC 61131-3 languages and they allow you to leverage the strengths of each language within the same main program. You can use FBD to create an advanced suite of mathematical logic functions as well as alarms and notification levels for example.
  •  

    Conclusion

    We know there are many more possible best practices and recommendations that experienced individuals within the community can come up with. We wanted to be part of increasing the conversation for the creation of some formalized and well documented best practices guidelines for each of the 5 IEC 61131-3 PLC languages. Part 4 of this series will focus on Instruction List (IL). We encourage our global multisector community of automation and control systems creators, installers, integrators, regulators, international standards organizations, testing labs, safety and risk assessors, pentesters and end users to think of and enforce the implementation of more recommended practices to increase our level of due diligence in our attempts to improve the assurance levels of infrastructures the public depends on for daily life.

    Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.

    Security Practices for IEC 61131-3 PLC Programming Languages Part 1: SFC

    By Isiah Jones, Director & Principal ICS Cyber Security Engineering & Brian Foster, Senior ICS Cyber Security Engineer

    Within the industrial control systems (ICS), automation, operational technology (OT), cyber-physical systems (CPS), industrial internet of things (IIoT) and instrumentation communities many of the devices with some form of computing and logical capabilities rely on 5 primary programming languages specific to programmable logic controllers (PLCs) that are defined in IEC 61131-3 as Sequential Function Chart (SFC), Ladder Diagram aka Ladder Logic (LD), Function Block Diagram (FBD), Instruction List (IL) and Structure Text (ST). In the IT community OWASP, NIST, SANS, CMMI, ISC2 and EC-Council, among others, have already created secure coding and secure development guidelines, best practices, testing tools and tips for higher level languages such as C, C++, Java, Python, JSON, HTML, XML, SQL and others. Some could argue that Structure Text includes several of these high-level languages. However, there has not been much focus by international standards organizations or industry experts on implementing security within the other 4 primary PLC focused languages in ICS. As a result, we wanted to share some of our recommendations for each of the IEC 61131-3 PLC languages in a 5-part blog series and aggregated white paper. This series will include a list of recommended practices and tips for each language that we believe should eventually become an accepted best practices guide or even long-term an international standard within the automation and control systems communities. This will continue to create innovative ways to decrease the effectiveness of attacks targeting ICS protocols, devices, applications, other assets, and operations by decreasing the potential consequences and impacts that are unique to ICS.

    Sequential Function Chart (SFC)

    Sequential Function Chart is a graphical representation of logical steps executed in order. The path of processing these steps is determined by the development of transitions between steps. Logic can progress in a straight line from one step to the next or diverge based on any number of conditions into different paths, parallel paths, or jump around to different parts of the chart. SFC is best used for programming state machines. State machines are chunks of logical code which can be in one state or another, never one state and another. Each step or parallel step of a SFC program is a state.

    SFC is an easy logic language to learn and use, however that comes at a computational overhead cost. Compared to some of the other common Logic Languages SFC requires more processing resources to execute. For this reason, it is not found in all PLC platforms, particularly those from older generations of equipment. Still, it is a commonly used language in much of the world. It is also often used on paper to convey the operation of a PLC (which may be programmed in another language) to interested parties.

    Recommended Practices

    Within SFC we believe the following recommended practices would improve the secure design and usage of SFC within ICS devices by adding security, safety and resilience supportive concepts within the SFC code for all devices and operations that operate using SFC. These recommended practices are in no particular order and this is not an all-inclusive list.

    • In loops and transitions, you could include logic that checks for unsafe states based on inputs and outputs before allowing the next action in your charts to execute.
    • When doing parallels in SFC insert actions, transitions and other logic points to verify logical requirements to ensure changes to registers, tags, set points, query scripts etcetera do not actually execute if an attacker sends commands via vulnerabilities in protocols like DNP3 and Modbus for example.
    • Build recover logic. This is basically a routine that gets called in the event that the logic hangs or the controller crashes. It can do various things, from simple restarts to isolating bad code and running the logic around it, through dropping a backup copy of logic onto the controller then rebooting it. Not all PLCs support this functionality, but most mainstream ones do.
    • Comment everything with detailed comments. Not only does this help with troubleshooting and future code development, it makes code that is not commented stand out. The bad guys may not comment the bad code at all, or they may do a really poor job (language barriers or in a hurry). In a well-commented program, commented bits stick out.
    • Create Jumps to safe process shutdown charts that leverage actions and transitions to flag and evaluate unsafe inputs and outputs or invalid data results from queries. This forces the SFC flows to execute safe logic when unsafe conditions occur within code logic.
    • Use the Enclosing element to create groups of logic checking charts that can be used to create a reusable logic checking the library of prebuilt charts that should be inserted into all code during system design, integration, FAT, SAT, Commissioning and tested during any logic changes in production.
    • Leverage timers and authorization checks within action and transition elements to track and log changes to charts by data inputs, outputs from devices, tasks, and human users. This enables an extra layer of security in the charts for key critical logic decision points to be protected from being changed to unsafe or unexpected states by malicious or accidental insiders or correct processes and data from other devices.
    • Develop meaningful chart scope and variable nomenclature that does not easily give away specific details about locations, logic, and purpose of devices to outsiders but is easily known and remembered by internal personnel for ease of consistent operations. This ensures that in the event of compromise external attackers will have to spend additional time understanding the chart variables to determine which parts of the charts to target to create true consequences and impacts both without being detected and or that cause sabotage states or undesirable conditions.
    • Test, demo, simulate, run and validate all charts for SFC rule violations, logic errors and design flaws or hanging elements etcetera prior to deployment into production on all projects.
    • Keep operational PLCs in run mode. This prohibits changes to the logic. It is often only changeable with physical access to the PLC. While this cannot prevent flaws in the code from being exploited it will stop the changing of the code by anyone who does not have physical access to the PLC.

    Conclusion

    We know there are many more possible best practices and recommendations that experienced individuals within the community can come up with. We wanted to be part of increasing the conversation for the creation of some formalized and well documented best practices guidelines for each of the 5 IEC 61131-3 PLC languages. Part 2 of this series will focus on Ladder Diagram also known as Ladder Logic. We encourage our global multisector community of automation and control systems creators, installers, integrators, regulators, international standards organizations, testing labs, safety and risk assessors, penetration testers and end users to think of and enforce the implementation of more recommended practices to increase our level of due diligence in our attempts to improve the assurance levels of infrastructures the public depends on for daily life.

    Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.

    Top 10 Universal Best Practices for Critical Infrastructure Security & Resilience

    By Isiah Jones, Director & Principal – ICS Cyber Security Engineering

    While attending the EnergySec Electric Distribution Security Forum March 22 – 23, 2018 in Washington, DC, the topic of best practices came up between trade organizations and state utility commission speakers and attendees. I informed them that in security “best practices” are already defined and not something that wiggles with legal interpretations. A security best practice is something that can be universally applied at different maturity levels regardless of how small or large the organization or what regulatory or non-regulatory jurisdiction or sector vertical they belong to. Each sector and jurisdiction all use PLCs, RTUs, I/O devices, sensors, actuators, laptops, servers, both unmanaged and managed network switches, wired communications transports (e.g. ethernet, fiber, electric power lines, leased phone lines etc) and some form of RF/wireless communications (e.g. 900 Mhz, cellular, ISA100, WirelessHART, Wi-Fi, ZigBee, satellite, microwave etc). These assets and devices range from geographically dispersed to sitting and operating within the same building or facility.

    The below top 10 list is a universal list that all our most critical infrastructures should implement internally–regardless of size or jurisdiction–if they have the budget and staff or seek help externally by prioritizing these requirements in all their third-party agreements and all requests for services and funding from their trade organizations as well as local, state and federal stakeholders. Organizations that don’t have the staff and budget for grandiose commercial based solutions should strongly consider seeking out those with critical infrastructure security experiences and leverage open source tools. Those owners and operators should consider “ICS Security Manager as a Service” as a viable option.

    The top 10 list is in no particular order because applying all 10 is very crucial to the security and resilience of our critical infrastructures, especially our interdependent industrial infrastructures such as water, oil, gas, electric, transportation (e.g. pipelines, rail, aviation, maritime) and telecommunications.

    Practice 1: Operational Resilience and Business Continuity

    Seek out trained individuals or resources from your sector peers and trade organizations that can help you with conducting a business impact analysis. Then seek resources to help implement and enforce in your contracts that backup, recovery, exercises, testing and redundancy be built into your assets and operations. Leverage open source tools and public resources from organizations like NIST. NIST SP 800-34 and other sources have templates that can be leveraged to help even small organizations know what areas they should consider and how they should go about doing it.

    Practice 2: Governance, Risk and Security Program Management

    For industrial control systems (ICS), automation, and operational technology (OT) in general (includes SCADA, DCS, PCS, PLCs, HMIs etc) there is a need for organizations to designate in writing a person responsible for ICS security and critical infrastructure operational resilience. Often this role is best filled by someone with an operations and ICS background who has also been trained in ICS specific security tactic, techniques and procedures. This role should also work with the CISO and CSO collaboratively for ICS security. An ICS security council and change or configuration control board (CCB) should be created where these folks meet monthly to hash out and make execution decisions on issues related to ICS and dependent operations.

    Practice 3: Asset and Inventory Management

    You cannot protect what you do not know you have. You cannot protect what you know you have if you don’t collect or require by contract the collection, maintenance and documentation of ports, protocols, services, real-time OS, OS, firmware, interfaces etc. Leverage tools and ICS trained and experienced individuals to help you keep up with an inventory. Tag assets by name, type, operational business unit, site location etc.

    Practice 4: Insider Threat and Personnel Security Program

    Nation states and terrorist are not the only issue. Sometimes your trusted integrator will make mistakes on your assets in the field and not fix it, know it was broken or tell you about it if they did. You also have former employees you should pay attention to. Third-parties and employees can and have caused more ICS and operational resilience impact than nation states have combined in many cases. Do not overlook all threat sources.

    Practice 5: Configuration Management and Patch Management

    ICS and operational infrastructure is not IT. Do not patch, scan, fix in ICS. Instead by contract and by procedure and policy create at least quarterly maintenance windows, a spare parts inventory, and a test lab and jump kit culture so that patches, drivers, updates, retrofits and other changes can be simulated, tested and scoped prior to a phased zone by zone implementation in production operations. This is very important for ICS. Leverage virtualization and simulation tools as much as possible.

    Practice 6: Vulnerability, Risk, Threat Assessments and Penetration Tests

    At least annually but especially after mergers, acquisitions, divestments or major new greenfield projects or even major brownfield retrofits you should do at a minimum a vulnerability assessment and at best a full risk, threat, consequence, and impact assessment plus a penetration test for ICS and dependent operations. Call in ICS focused security professionals to help you do this on all Commissioning, Factory Acceptance Test (FAT), Site Acceptance Test (SAT), annual exercises and annual assessments.

    Practice 7: Network Management and Security

    ISA/IEC 62443 security zones and conduits is not just a buzzword it is something you must implement in ICS environments. You should always have DMZs with separate domains and zero trust between domains with shared data services locked in the DMZ as needed to avoid direct two-way communication between safety, primary ICS and any other system outside of ICS (e.g. IT, internet and third-party connections). Always enforce this in all designs and all contracts.

    Practice 8: Incident Response, Analysis and Monitoring

    For ICS leverage the US Cyber Command Advanced Control Systems Tactics, Techniques and Procedures (ACI TTP) for ICS, ICS-CERT recommended practices, NIST SP 800-61, ISA/IEC 62443 and SANS Incident Handlers Handbook to create an ICS specific Incident response program with policies, procedures and guides that define what an event is, when an event becomes an incident, chain of command, chain of custody, chain of communication both internal and external to ICS operations and the approved tools, roles, responsibilities, tactics and techniques. Ensure ICS focuses on ICS devices and protocols.

    Practice 9: Security Requirements based Contract/Procurement and Supply Chain Management

    Your third-parties and where you shop is your weakest link. Ensure all technical specifications sections of all contracts and agreements list out the specific security controls you want to implement from NIST SP 800-82, ISA/IEC 62443, NERC CIP and other critical infrastructure and ICS focused security standards, best practices and regulations. Also ensure controls from the NIST SP 800-161 for Supply Chain Risk Management are implemented within all contracts and agreements as well as organizational practices, procedures, cultural processes and policies.

    Practice 10: Systems Security Engineering

    Secure system design, testing and validation, acceptance testing, commissioning and continuous lifecycle checkups is the best way to ensure your ICS assets arrive secure by design and remain secure by design until they are properly decommissioned. Ensure controls from NIST SP 800-160 for Systems Security Engineering is implemented in all processes, procedures and contract agreements.

    In addition to requiring, teaching and educating asset owners on this top 10 list, Regulatory agencies such as one I worked for, Federal Energy Regulatory Commission (FERC), and all NARUC members in general, should do their duty and create cost recovery rules, regulations and orders focused around security, safety and resilience. This needs to be done especially for the small to midsize organizations that don’t have large investor or profit based revenue streams or the staff nor can they afford to contract the staff or tools without cost recovery being granted by the regulatory agencies. All proposals for rate cases, retrofits and new projects should be required to include operational security and resilience, particularly ICS focused, needs and cost estimates that address mitigations of impacts and consequences that require budget and resources to mitigate successfully.

    Implementing these best practices and regulatory support for cost recovery methods will go a long way towards expediting the improvement of many of the various infrastructures society depends on daily for our way of life. If the regulators, asset owners, vendors, EPCs, integrators and the community doesn’t implement these top 10 practices as the daily standard then the insurance industry should step in and build premiums based on the maturity levels of organizations measured against these top 10 practices for ICS security and operational resilience within critical infrastructure.  If you want to learn more of what you should do and how to get help doing it then just reach out to LEO’s ICS team, we are the community and the community is us.

    Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.

    ICS Security Manager as a Service – Part 4

    By Isiah Jones, MPS, CISSP, GICSP, C|CISO, Director, ICS Cyber Security Engineering

    The fourth and final post in our series explores who can benefit from the ICS Security Manager as a Service concept. To revisit the earlier posts, please see Part 1, Part 2, and Part 3.

    So, who would even benefit from this ICS Security Manager as a Service concept? The simple answer is every asset owner and operator with ICS assets that monitor and control any part of their operations. Any critical infrastructure sector that leverages automation and control systems to monitor and control critical infrastructure assets and operations can benefit from ICS Security Manager as a Service. A more specific list of immediate winners are as follows (this list is not complete or exhaustive):

    • Electric cooperatives
    • Municipalities
    • Hydro
    • Water and wastewater
    • Oil and gas pipelines
    • Ships and ports
    • Rail and urban public transit systems
    • Manufacturing
    • Airports
    • Agriculture and food processing
    • Hospitals, Labs, and Clinics
    • Fire, life safety and facilities management
    • Small and mid-size businesses that own and operate critical infrastructure assets
    • Large asset owners and operators with no single authoritative role for ICS security
    • CISOs, CSOs, CIOs and or critical operations managers and business unit owners who have been tasked with the responsibility of ICS security for their assets
    • ICS Vendors, integrators, EPCs

    Asset owners need skilled allies in their efforts to improve and secure some of our most vital infrastructures. They do not always need, nor can they always afford, the traditional consulting firm contractor staff augmentation and advisory service or MSSP SOC and incident response only services or product plug and play. Asset owners, especially the small to mid-market owners and operators, need a continued partner providing ICS Security Manager services on an as needed yet continued retainer style basis.

    This gives the asset owners the ability to have access to a cadre of experienced ICS Security Managers as a Service instead of being limited by staff augmentation assignment to a specific role for various tasks. Also, unlike just a CISO the ICS Security Manager as a Service brings in technical hands-on abilities and creates an ICS focused buffer to help operations manage interactions with the CISO, IT and other stakeholders concerned with ICS security within an organization who don’t have both detailed cyber and ICS experiences.

    Contact LEO Cyber Security today to learn more about how we can help you with your ICS Security Manager as a Service goals or even train other organizations how to provide it.

    • Please complete the following form and one of our team members will get back to you as soon as possible.


    Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.

    ICS Security Manager as a Service – Part 3

    By Isiah Jones, MPS, CISSP, GICSP, C|CISO, Director, ICS Cyber Security Engineering

    This is the third blog post in our series that explores why the ICS Security Manager as a Service is needed. To review the earlier posts please visit Part 1 and Part 2.

    What is the ICS Security Manager as a Service?

    The easiest way for both the ICS and cybersecurity communities to wrap their heads around what the heck ICS Security Manager as a Service is would be to initially think of the ICS focused version of CISO as a Service only with additional duties that include hands on technical engineering and architecture work. Some folks may see it as just another name for staff augmentation. However, staff augmentation implies a permanently contracted individual who essentially belongs to your organization as a contracted employee. Basically, they are simply just another extension to your pool of contractor employees. In some respects, ICS Security Manager as a Service is like a combination of CISO as a Service business models and traditional staff augmentations.

    However, ICS Security Manager as a Service would not be a staff augmentation contractor employee position. Instead it would be like having a firm of experienced lawyers on constant retainer whenever you needed them. They act on your behalf and look out for your interests, they know your organization and your secrets and not only advise you but can also take action up to and including representing you in court or taking legal actions on your behalf. In that spirit ICS Security Manager as a Service would be a fractional, part-time, half-time or full-time scaled pricing-based retainer service that would provide asset owners with access to seasoned ICS Security professionals when they need them to perform various tasks on their behalf.

    ICS Security Manager as a Service could be called upon to write security specifications and specific security controls and sub controls into ICS Master Plans, RFPs, RFIs, contract agreements, design guidelines, roadmaps throughout the lifecycle of your existing and new ICS assets and operations. The service could also include building out your inventory lists, architecture design, testing labs, systems security plans for each system, configuration plans and guides for each system and conducting evaluations of ICS vendor and integrator products and solutions on behalf of the asset owner and operator.

    Some of the duties and tasks this service could complete and maintain are as follows (this is not an exhaustive or complete list):

    1. Build, operate and maintain ICS Security Program (this includes policies, procedures, frameworks, regulations, standards and best practices)
    2. Act as ICS Security Manager on behalf of asset owner and operator (this includes authority to oversee and direct ICS vendors, integrators, staff and contractors)
    3. Serve as liaison between ICS business owners and IT staff and corporate leadership (e.g. CIO, CISO, COO)
    4. Coordinate, evaluate and execute annual ICS focused assessments
    5. Coordinate, evaluate and execute annual ICS focused penetration tests
    6. Lead, support and execute implementations to mitigate discovered risks and vulnerabilities for ICS assets and operations
    7. Integrate, create and enforce ICS security requirements, standards, best practices and functionality into all ICS projects, contracts, agreements, operations and assets on behalf of asset owners and operators
    8. Build, maintain and execute ICS system security plans, ICS configuration management plans, ICS inventory list, ICS incident response plans, ICS system, network and architecture diagrams, etc.
    9. Test, evaluate, authorize, certify and facilitate products and services used by and for ICS assets and operations on behalf of owners and operators
    10. Enable and deliver ICS focused security training and awareness for ICS operators and supporting stakeholders (physical security, HR, finance, procurement, IT, vendors, integrators, EPCs, etc.)

    Why do we need it?

    Many would say this sounds like an amalgamation of existing varied contracted services that different firms may or may not provide. It also sounds like some of the duties that an MSSP would perform in some cases as well. In some respects, yes, but holistically no. Many of these services today are performed by IT firms that have no real ICS security chops or ICS integrators and vendors who have no significant security chops especially no systems security engineering, assessment, validation, secure design, secure integration or security operations and maintenance experiences. Additionally, many existing firms would focus in on just policies, audits, assessments and penetration tests then move on and only return to check to see what mitigations have been implemented. None of these solutions would provide the full lifecycle continuous completion of tasks necessary for ICS Security on behalf of asset owners and operators.

    Asset owners and operators often lack dedicated ICS security expertise and the funding to hire such resources. ICS integrators, ICS vendors and consulting firms that are mostly IT security, compliance and audit based in their nature do not have the full lifecycle systems security engineering experiences or dedicated expertise to continuously close this gap for asset owners and operators. As a result, asset owners and operators end up spending the limited budget they have on expensive audits and assessments that leave them with gaps and findings they have no expertise on staff to help them mitigate. Owners and operators also end up depending heavily on integrators, vendors and MSSPs to perform duties and tasks that only address portions of the gaps and mitigations or end up creating more gaps and risks than they mitigate. Simply put, the status quo means well and does serve a purpose of good but the gaps that remain are continuously putting asset owners, operators and the infrastructures they monitor and control at risk.

    A list of some reasons why asset owners and operators need ICS Security Manager as a Service are as follows (this is not a complete or exhaustive list):

    1. Asset owners, operator and critical infrastructure needs ICS security focused and dedicated resources
    2. Organizations lack resources for full-time ICS security staff
    3. IT does not focus exclusively on ICS security and generally lacks the ICS focused education, training, certifications, understanding and experiences needed
    4. Collateral duty with IT biased approaches to ICS create more risk than solutions
    5. ICS operators cannot focus exclusively on security of their operations and assets and generally lack significant security experience and awareness
    6. Some environments, asset types and sector verticals are best served by need to know, least privilege and segregation of duties, roles, access and infrastructure increasing the need for a separate, experienced and dedicated ICS Security Manager as a Service
    7. Connection to the dedicated ICS security focused community of practitioners is paramount
    8. Access to ICS security skilled resources with experiences across several organizations and infrastructures will be a force multiplier for all sector verticals and ICS asset types
    9. ICS Security Manager as a Service creates an authoritative role and voice for ICS asset owners and operators
    10. Provides an ICS Operations Security Liaison to CISO, CIO, CSO, COO and Board

    Part 4 will provide insight into who we think can benefit from ICS Security Manager as a Service, and our concluding thoughts on why it is important and what your next steps should be.

    Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.

    ICS Security Manager as a Service – Part 2

    By Isiah Jones, MPS, CISSP, GICSP, C|CISO, Director, ICS Cyber Security Engineering

    This is the second blog post in our series that explores the ICS Security Manager as a Service concept. To review Part 1, please visit ICS Security Manager as a Service – Part 1.

    In my travels over the last four years, I’ve consistently encountered the same old tragedy over and over again regardless of what type of critical infrastructure asset type or sector vertical it was and regardless of what state, nation, continent, company and or military base it was. That tragedy was constantly connecting with and trying to support engineers and other personnel building security into active in-flight projects for both existing and new infrastructure monitored and controlled by some type of industrial automation and or control system device, network, protocol, system and or application.

    I usually found many issues within contracts, cultures, and understanding of system design, integration, system configurations, validation, testing, requirements specifications and contract language or systems security engineering principles in general. I also consistently found very small teams, mostly a team of one on the ICS side and a team of totally ill-informed bull in the china shop folks on the IT teams. In other cases, I found teams of impossible to work with engineers and desperately anxious IT staff. One day on a project it hit me: why do I continue to create templates, steps and solutions and share them with folks who either don’t have the time to implement and maintain them, aren’t interested in the first place or honestly have no idea what it is that I just provided them? Why don’t I just complete the task for them, show them how I did it, show them how to maintain it then periodically return to make sure it is maintained? Thus, the idea for ICS Security Manager as a Service was born in my head at the time.

    The next post in our series will explore why the ICS Security Manager as a Service is needed.

    Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.

    ICS Security Manager as a Service – Part 1

    By Isiah Jones, MPS, CISSP, GICSP, C|CISO, Director, ICS Cyber Security Engineering

    As industrial control system (ICS) assets and operations increasingly become the targets of opportunity it is important that new strategies and ideas for focused and tailored security approaches are introduced to the community. ICS security manager as a service can enable the community to contract skilled resources for a new role dedicated solely to securing ICS within the resource-constrained operations staff for ICS asset owners and operations of some of the world’s most critical infrastructures operated, monitored and controlled by automation and control systems.

    The ICS Security Manager as a Service is like CISO as a Service on the IT side of the house with respect to building a security program. However, unlike the CISO as a Service, the ICS Security Manager as a Service is intended to be a more technical, hands-on role as well.

    Examples of duties and tasks the ICS Security Manager would perform as a service are: leading, coordinating and implementing day to day security tasks such as building ICS system security plans, inventory lists and testing products and services for ICS operators’ operations and assets.

    Such a service would most benefit ICS owners and operators who cannot afford a full-time resource within their staff. Some example asset owners and operators would be electric cooperatives, municipalities, and small businesses that own and operate pipelines, water and wastewater plants and hydro dams.

    This series of blog posts will explore the ideas behind the ICS Security Manager as a Service concept including what it is, why it’s needed, and who can benefit.

     

    Isiah has over 13 years of progressive experiences in information technology and systems, information assurance, information security, cybersecurity, operational technology or industrial control systems security, national security and critical infrastructure security.