All.Net presents our standards of practice decision framework for securing industrial control systems. These decisions provide an overarching basis and many specifics surrounding what we currently view as a reasonable and prudent approach to addressing information protection for industrial control systems. While there may be many other approaches that might also meet the need, we hope that these will provide guidance and discussion within the community, and we use them as a starting point in our practice to help guide consistent quality and performance within our own team and in customer engagements.

This content is part of a process used by our affiliated companies as developed over many years. We identify these issues, characterize the environment, and apply these decision points by interacting with clients and applying our expertise to help form overall architecture and its component parts. Typically, decisions are reviewed both internally and externally in an iterative fashion so that as we discover things that require changes, those changes ripple through the overall standard to keep it up to date and relevant.

In many cases, this standard of practice is used starting with an as-is review, identifying a desired future state, doing what, by then, is a relatively straight forward gap analysis, and then characterizing a workable transition plan for the organization. In our more agile approach, we undertake only an initial and periodic as-is and future state analysis, understanding that the reduced time and cost in assessment leads to more resources available for acting on the results, and that planning is less certain and less permanent when we are moving at a faster pace.

Elements of the framework:

• Who are the interviewees?
• Overarching: How does the enterprise describe itself and why this effort is being undertaken?
• Overarching: Protection model: What overarching model will be used for understanding information protection issues?
• Overarching: Business: What is the nature of the business and how do ICS systems support it?
• Overarching: Promises: What promises does the business make, to whom, and why? How do they relate to information?
• Overarching: Scope: What is the scope of this ICS security architecture?
• Overarching: Maturity level: What maturity level should the information protection program have?
• Overarching: Content: What are the reasonably anticipated consequences of ICS information protection failures?
• Overarching: Location: How should ICS and their workers be located?
• Overarching: Organization: What is the structure of the organization?
• Overarching: Outsourcing people: What part and portion of the workforce is outsourced?
• Overarching: Outsourcing things: When is information technology be outsourced?
• Business modeling: How does the enterprise model itself and its business?
• Business modeling: Will an explicit business model be used to support information protection decision-making?
• Business modeling: What are the business functions and what information do they depend on for what?
• Oversight: What does enterprise oversight provide to the protection program to define duties to protect?
• Oversight: How will different sorts of duties be prioritized in determining what to protect and how well?
• Oversight: Form of duties: What form will duties be defined in?
• Oversight: Duties analysis: How will duty to protect be analyzed?
• Risk Management: How does ICS do risk management?
• Risk Management: Risk management process: What risk assessment processes should be used?
• Risk Management: Risk definition: How should I define risk levels for ICS systems?
• Risk Management: Threats: How should information-related threats be assessed?
• Risk Management: Threats: What threats have been identified, what are their characteristics and relevant history?
• Risk Management: Threats: What design basis threat will be used?
• Risk Management: Threats: What attack mechanisms should be considered?
• Risk Management: Vulnerabilities: How and when should information-related vulnerabilities be assessed?
• Risk Management: Risks: When should the enterprise avoid, accept, transfer, and mitigate information-related risks?
• Risk Management: Risk aggregation: What process should I use to identify and control the aggregation of risks?
• Risk Management: Separation of Duties: How should duties be separated?
• Risk Management: Interdependencies: How should supply chain risks be managed?
• Risk Management: Interdependencies: How should real-time interdependency risks be managed?
• Risk Management: Costs: How should ICS security be prioritized and budgeted?
• Risk Management: Surety matching: How should surety be matched with risk?
• Risk Management: Failsafes: When should failsafes be required and how should they be determined?
• Risk Management: Changing systemic risks: How should changing systemic risks be managed?
• Risk Management: Changing subsystem risk and surety: How should risk and surety changes of a subsystem be handled?
• Management: How does the enterprise manage the ICS information protection program?
• Management: ICS Security Management: Who should manage ICS security and where should they be placed?
• Management: Duties: What duties should the ICS information protection (IP) Lead have?
• Management: Influence: What power and influence should the IP Lead have?
• Management: Security Metrics: What security measurements should be taken and when?
• Management: Policy: What information security policies are really needed?
• Management: Standards: Which widely used control standards are best suited to the enterprise?
• Management: Procedures: What procedures are implemented and how?
• Management: Documentation: How should security-related issues be documented?
• Management: Auditing: How should audits be managed within information protection?
• Management: Testing: What should the protection testing function do and cover?
• Management: Personnel: How should the personnel issues with information protection be managed?
• Management: Background checks: When should which background checks be done on which workers?
• Management: Incident handling: How should incidents be managed?
• Management: Legal issues: How should legal issues interact with protection management?
• Management: Physical security: How should physical security be integrated with information protection?
• Management: Knowledge: How should the knowledge program be integrated with information protection?
• Management: Security awareness: What sort of enterprise security awareness program should the enterprise have?
• Control Architecture: How does the enterprise model information-related controls?
• Control Architecture: Establishment: Will a control architecture be formally established?
• Control Architecture: Objectives: What are the protection objectives and how are they applied?
• Control Architecture: Access Controls: What access control model will be used?
• Control Architecture: Original Identification: How are individuals originally identified and their identities verified?
• Control Architecture: Identity proofing: How are asserted identities proofed after originally identified?
• Control Architecture: Authentication: How are identities authenticated to support authorized access?
• Control Architecture: Access facilitation: How is access facilitated once identity is adequately established?
• Control Architecture: Trust model: How is trust assessed and managed?
• Control Architecture: Change management: How are changes to ICS and supporting infrastructure handled?
• Control Architecture: Control Architecture: When should a systematic security architecture be created and updated?
• Technical Security Architecture: How are technical controls structured?
• TechArch: Inventory: What protection-related inventory should be kept and in what form(s)?
• TechArch: Workflows: How are workflows used, controlled, and assured?
• TechArch: Lifecycles: What aspects of lifecycles should be considered in the protection program and its processes?
• Zones: How should the enterprise separate parts of (zone) its network(s)?
• Zones: Placement: What systems, data, and people go in which zones and subzones?
• Zones: Firewalls: What mechanisms should be used to separate communicating zones and subzones?
• Zones: Zone separation verification: How should zone separation be verified?
• Zones: Physical separation: How should zones and subzones be physically separated and controlled?
• Zones: Connection controls: How should connections between devices be controlled?
• Zones: Remote access: How is access to internal zones from distant locations (including wireless) facilitated?
• Zones: Endpoint protection: What protective mechanisms should be used to harden which ICS components (endpoints)?
• Zones: PLC placement and controls: What protection mechanisms should be used between a PLC and a network?
• Zones: SCADA placement and controls: What protection mechanisms should be used between a SCADA system and a network?
• Zones: Sensor and actuator connections to PLCs: How should sensors and actuators be connected to PLCs?
• Zones: HMI connections: How should HMIs be connected to other ICS systems?
• Incidents: Detection: How should anomalies and/or intrusions be detected?
• Incidents: Malicious ICS Alteration Detection: How should malicious ICS alteration be detected?
• Incidents: Response: Who should control and execute responses to information-related attacks?
• Incidents: Detection and response: What are the process requirements for detection and response?
• Incidents: Deception: When is it appropriate to use deceptions to defend my networks and systems?
• Content control: How should I control harmful and useless content in my computing environments?
• Content control: What mechanisms should I use to keep control over content with business utility?
• Content control: Data in use: How should data in use be protected?
• Content control: Data in motion: When should I transmit content encrypted?
• Content control: Data at rest: What should I store encrypted?
• Content control: How should intelligence gathering be countered?
• Content control: How is intellectual property protected?
• Human factors: How are human factors considered in the protection program?
• Human factors: Protection load: How is security load managed?
• Human factors: User decision-making: What decisions do users make and how do they make them?
• Human factors: Disruption: How is disruption of work controlled?
• Redundancy: Fault model: What fault model should be assumed for analysis of redundancy?
• Redundancy: Backups: What should be backed up and how often?
• Redundancy: Data history redundancy: How many copies of data history should be retained, where, and for how long?
• Redundancy: ICS control room redundancy: How many ICS control rooms are needed?
• Redundancy: Redundant facility distance: How far should redundant data centers and people be to assure continuity?
• Redundancy: Business continuity and disaster recovery: What information resources should I have and where?
• Redundancy: Interdependencies: How should redundancy be applied to interdependent mechanisms?
• Technology: Logical Perimeters: What logical perimeters have what protection mechanisms?
• Technology: Physical Perimeters: What physical perimeters have what protection mechanisms?
• Technology: Physical/Logical Nexus: How do physical and logical controls interact and integrate? Copyright(c) Fred Cohen, 1988-2015 - All Rights Reserved