1 / 5

ISA 99.00.01 “Security Zones and Conduits”

ISA 99.00.01 “Security Zones and Conduits”. The challenge to map ISA 99.00.01 to ISA 99.00.04. Presented to ISA 99 WG04 Dennis Holstein holsteindk@ieee.org. ISA 99 WG 04 Meeting Scottsdale, AZ 25-27 June 2007. What is the challenge. ISA 99.00.01 contains Definitions and Models

erek
Download Presentation

ISA 99.00.01 “Security Zones and Conduits”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ISA 99.00.01“Security Zones and Conduits” The challenge to map ISA 99.00.01 to ISA 99.00.04 Presented to ISA 99 WG04 Dennis Holstein holsteindk@ieee.org ISA 99 WG 04 Meeting Scottsdale, AZ 25-27 June 2007

  2. What is the challenge • ISA 99.00.01 contains Definitions and Models • Definitions are not the problem • Models are abstract – instantiation for Part 4 is the challenge • ISA 99.00.04 is a compliance specification • Compliance requires testability criteria • By measurement • By inspection and analysis • To be testable requirements must be prescriptive • But, Part 4 must not define “how to” implement the requirements – it must state “what is” required

  3. Apply lessons learned from IEC 62443-3 • IEC TC65WG10 approach • Establish a common reference model defining zones and conduits • Served well for analysis and contributions by independent work packages • Overlaps in the reference model resulted in duplication of requirements and divergent specifications • The challenge was to harmonize the contributions • The approach was to cast the requirements in the context of a security policy statement • This resulted in the generation of a Public Available Specification (PAS) – which is a non-binding document in Europe • Original 62443-3 work has been turned over to ISA 99 for their development • Zones and conduits used by TC65WG10 are applicable to ISA 99.00.04 • Requirements are testable • ISA 99WG04 challenge is to balance the detailed prescriptive specifications • Technology dependent language needs to be adjusted to ensure longer life of the specification • Language must be cast in terms of “If required by security policy, then the capability to …. is required” – most requirements become optional

  4. The need for foundational requirements • Foundational requirements can be stated that apply to any Asset Owner’s derived common reference model • PCSF seven foundational requirements • Operations centric view of requirements • The simplest set to understand and use • NIST 800-53 & INL/DHS catalog • A comprehensive treatment of requirements • A daunting task to assimilate and correlate interdependency of requirements • Suggested approach: two simultaneous teams • Start with the PCSF foundational requirements • Use the NIST and INL/DHS documents as a checklist to find missing requirements for Part 4

  5. What worked well for TC65WG10 • Common template for domains (zones & conduits) • Statement of cyber security issue addressed • Assumptions and constraints applied • Requirements addressed in another domain • Relationship to stated policy • Statement of requirement • Litmus test – it must be testable • Options to increase strength of protection (defense in depth) • Rationale or justification for requirement “This is important because ….” • Need to harmonize Part 4 statements with Parts 2 and 3 – Part 3 work needs to start

More Related