NERC has comments open right now on Virtualization and CIP Standards. Registered Entities, hie thee hence and make known your will. After all, you get the governance you deserve, not the one you want. Especially if you don't participate.
Here's more or less what we came up with in my neck of the woods:
Q1. Version 5 introduced the BES Cyber System concept, and requirements reference applicability at the BES Cyber System level. However, language in the measures shows that, implicitly, many controls are expected to be implemented at the BES Cyber Asset or device level. The SDT assumes that most auditors expect entities to demonstrate compliance at the device level. Do you agree with the SDT’s assumption?
A1. It has been our experience that guidance provided to auditors leads them to expect and look for controls to be applied to the Cyber Asset. Also, they seem sceptical of implementations where a given device performs a portion of the control function and additional components of the security strategy are implemented across multiple devices on the network. Auditors might consider only the device portion of an overall control and evaluate it outside of the network-based defense-in-depth strategy.
One way to address this inconsistency would be to normalize the use of the term “system” across the example measures rather than “device” wherever applicable. The SDT should add Guidance in the Technical Basis sections to clarify that defense in depth strategies are desirable. The EACMS paradigm should be revised in line with standard IT Security practice and terminology as performing Authentication, Authorization, and Accounting. It is also important to explicitly allow for distributed systems to perform this AAA function for a security zone rather than the legacy concept of hardened perimeter.
There may also be a need to revisit the RSAWs in light of system vs device to provide better guidance to auditors attempting to apply the questions in the RSAW to an entity’s particular security posture.
Q2. The SDT proposes that each virtual machine and hypervisor are separate Cyber Assets. 2. Do you agree with this position?
A2. The proposed definition of Cyber Asset must include virtual machines. Both “virtual machine” and “hypervisor” are well-understood terms with formal definitions and broad IT Industry acceptance, thus do not need further definition in the NERC Glossary. We agree that each Hypervisor and Virtual Machine is a distinct Cyber Asset. Controls and strategies for securing virtual machines across a variety of industries have been published by agencies such as NIST and SANS.
The key issue the SDT appears to address in this revised definition is clarifying the scope or boundaries of a given virtual cyber asset in order to apply requirements and controls to each. Clarifying the definition is only necessary to address gaps in current requirements language that allow for mis-applying the requirement, not because Industry doesn't understand how to do it.
Q3. Do you agree that the proposed Cyber Asset definition clarifies the term programmable? Please provide a rationale to support your position.
A3: The SDT’s proposed definition clarifies programmable means that such a device is subject to configuration and software changes by the end user. This clarification and scope limitation is useful.
However, the device does not "consist of" all the data stored in the device. Data inside the device is peripheral and irrelevant to the operation of the device. It may be necessary to operation of the BES, but unless you want the BES to be one, singular BCS, it is ridiculous to scope it that way.
Much data inside the device is peripheral and irrelevant to the operation of the device. Even data which is required to perform the function of the device is generally not part of the device. This “data in the device” portion of the definition apparently is a mis-interpretation of wording from Section 215 of the Energy Policy Act of 2005 which actually reads: “programmable electronic devices and communication networks including hardware, software and data that are essential to the reliable operation of the bulk power system.” Even this is problematic in that standard IT Security best practice separates the concept of protecting a system (better known as Information Assurance, Source: NIST SP 800-50, CNSSI-4009) from the mechanisms of protecting data transiting or resident on that system (the latter being Information Security, Source: NIST SP 800-59; SP 800-53; SP800-53A; SP 800-60; CNSSI-4009; FIPS 199; 44 U.S.C., Sec. 3542). For example; a SCADA server can be deemed perfectly functional with no real SCADA data present. A newly-deployed SCADA server functions at the instant of being commissioned before real SCADA data is input.
The introduction of the concepts of management plane and data plane which are referenced in question 8 is a useful addition to the NERC CIP discussion because it enables appropriate controls to specifically protect systems or data.
Q4. Such (shared infrastructure) configurations are not addressed explicitly in CIP-005-5. Are modifications required to address the issue?
A4. CIP-005-5 would benefit from being modified to a security objective-oriented standard rather than a requirements-based standard. The security objective in this case would be isolation of CIP-applicable Cyber Assets from Cyber Assets that are out of scope of CIP controls. The mechanisms of that protection are primarily Boundary Protection and Control of Network Ports, Protocols, and Services (SANS 20 Critical Security Controls).
CIP v5 narrowly focuses on routable protocols and Layer 3 controls and does not address the other layers of the OSI model. For example, under CIP-005-5 Layer 2 protocols are not addressed and can convey malware as well as allow information exfiltration and cyber-attacks even if no routable IP communications are present. Controls for these protocols should not be limited to or defined by Layer 3/4 ACLs on a firewall or router as the only or even the best means of achieving in-bound and out-bound access control. Entities need the opportunity to provide technical controls at whatever conceptual layer is appropriate to meet the security objective.
I recommend retiring the ESP construct in favor of security zones. When framed in terms of Boundary Protection, a security zone is more inclusive and granular because it is not limited to routable protocols at the OSI Model’s Layer 3. A security zone construct does not force any particular interpretation or control onto serial or other non-routable means of transporting data or accessing the management plane of any systems. Security zones apply to physical and logical separation equally. An example of logical isolation provided by other than ACLs would be when a hypervisor provides isolation between Guest VMs or between Virtualized Network Functions. This isolation is implemented in the control plane by means of logic embedded in code base (NIST SP 800-125A – Draft, Section 1.2: Hypervisor Baseline Functions) and not at a conceptual network layer.
Current CIP standards take a broad stroke approach by requiring the protection of all cyber assets within an ESP in a singular manner at the highest impact level of controls ("High Water Mark"). Further, High Water Mark is applied to the impact rating of the BES Asset or Facility, and not to the impact rating or risk level of the Cyber System itself. This is not cost effective or flexible enough for individual entities’ needs. Security zones provide a scalable means of appropriately protecting Cyber Systems of differing security risks by further isolation within the zone.
Q5. The SDT asserts that VLANs providing logical isolation are not addressed explicitly in CIP-005-5, and controls may be necessary to isolate BES Cyber Systems. Are the current requirements of CIP-005-5 sufficient to address logical isolation using VLANs? Please provide your rationale.
A5. The same modifications necessary to make CIP-005-5 adequate to question 4 would apply to addressing the specific question of 802.1 Q VLANs providing adequate logical isolation in question 5. The security objective should be to provide isolation by means of Boundary Protection as well as Control of Network Ports, Protocols, and Services. Legacy software vulnerabilities that have long since been patched or known exploits that are mitigated through proper configuration should not require the blanket rejection of VLANs as a component of a particular entity’s specific security scheme. Newly discovered exploits and vulnerabilities are addressed through CIP-007 testing and patching, CIP-010 baseline configuration, change management, vulnerability scanning and assessment.
Q6. Do you agree with the proposed definition of CMS (Centralized Management Systems)? If not, please provide alternative language for the definition and your rationale.
A6. The SDT’s proposed definition of CMS captures most types of systems that support automation with a large span of control and privileged access. A similar span of control risk exists in that EACMS is a type of CMS for electronic access but the term EACMS is specific to NERC CIP and used nowhere else in IT Security or Information Assurance in any other industry. This inherently limits the amount of expertise, guidance, and documentation available for solving the root problem of controlling access to CIP-applicable systems.
The SDT should retire the NERC CIP defined term Electronic Access Control & Monitoring System from the NERC Glossary and adopt the industry solution Authentication, Authorization, and Accounting System (AAA System). Non-standard jargon should be avoided when adequate terms and concepts exist already.
Further, the SDT should clarify in Guidelines and Technical Basis, that:
Q7. Do you agree with the SDT’s approach to reference the CMS specifically as a type of applicable system in the CIP standards? Please provide your rationale.
A7. The inherent risk in such (centralized management) systems’ span of control and privileged access to CIP-applicable Cyber Systems should be addressed in support of the security objective of protecting BES Cyber Systems from threats in the data plane and isolation of the management plane (out of band management).
Q8. Do you agree with the SDT’s approach to require the isolation between the data plane and the management plane?
A8. Cautiously agree with the SDT’s proposal to require isolation between Data Plane and Management Plane for centralized management systems when system capability allows and risk justifies it (i.e. Hgih and Medium Risk Control Centers). We caution the SDT against overly rigid prescriptions for providing isolation. Combinations of other controls may afford the same or better protection in a particular circumstance. When the use of automated tools can improve security and manageability, it is important to avoid discouraging automation with overly burdensome compliance requirements.
Q9. Do you agree with limiting the applicability to high and medium impact Control Centers?
A9. Limiting applicability only to those facilities such as High and Medium Control Centers with the highest level of risk is reasonable, and there may be exceptions to those as well. Combinations of other controls may afford the same or better protection in a particular circumstance.
Here's more or less what we came up with in my neck of the woods:
Q1. Version 5 introduced the BES Cyber System concept, and requirements reference applicability at the BES Cyber System level. However, language in the measures shows that, implicitly, many controls are expected to be implemented at the BES Cyber Asset or device level. The SDT assumes that most auditors expect entities to demonstrate compliance at the device level. Do you agree with the SDT’s assumption?
A1. It has been our experience that guidance provided to auditors leads them to expect and look for controls to be applied to the Cyber Asset. Also, they seem sceptical of implementations where a given device performs a portion of the control function and additional components of the security strategy are implemented across multiple devices on the network. Auditors might consider only the device portion of an overall control and evaluate it outside of the network-based defense-in-depth strategy.
One way to address this inconsistency would be to normalize the use of the term “system” across the example measures rather than “device” wherever applicable. The SDT should add Guidance in the Technical Basis sections to clarify that defense in depth strategies are desirable. The EACMS paradigm should be revised in line with standard IT Security practice and terminology as performing Authentication, Authorization, and Accounting. It is also important to explicitly allow for distributed systems to perform this AAA function for a security zone rather than the legacy concept of hardened perimeter.
There may also be a need to revisit the RSAWs in light of system vs device to provide better guidance to auditors attempting to apply the questions in the RSAW to an entity’s particular security posture.
Q2. The SDT proposes that each virtual machine and hypervisor are separate Cyber Assets. 2. Do you agree with this position?
A2. The proposed definition of Cyber Asset must include virtual machines. Both “virtual machine” and “hypervisor” are well-understood terms with formal definitions and broad IT Industry acceptance, thus do not need further definition in the NERC Glossary. We agree that each Hypervisor and Virtual Machine is a distinct Cyber Asset. Controls and strategies for securing virtual machines across a variety of industries have been published by agencies such as NIST and SANS.
The key issue the SDT appears to address in this revised definition is clarifying the scope or boundaries of a given virtual cyber asset in order to apply requirements and controls to each. Clarifying the definition is only necessary to address gaps in current requirements language that allow for mis-applying the requirement, not because Industry doesn't understand how to do it.
Q3. Do you agree that the proposed Cyber Asset definition clarifies the term programmable? Please provide a rationale to support your position.
A3: The SDT’s proposed definition clarifies programmable means that such a device is subject to configuration and software changes by the end user. This clarification and scope limitation is useful.
However, the device does not "consist of" all the data stored in the device. Data inside the device is peripheral and irrelevant to the operation of the device. It may be necessary to operation of the BES, but unless you want the BES to be one, singular BCS, it is ridiculous to scope it that way.
Much data inside the device is peripheral and irrelevant to the operation of the device. Even data which is required to perform the function of the device is generally not part of the device. This “data in the device” portion of the definition apparently is a mis-interpretation of wording from Section 215 of the Energy Policy Act of 2005 which actually reads: “programmable electronic devices and communication networks including hardware, software and data that are essential to the reliable operation of the bulk power system.” Even this is problematic in that standard IT Security best practice separates the concept of protecting a system (better known as Information Assurance, Source: NIST SP 800-50, CNSSI-4009) from the mechanisms of protecting data transiting or resident on that system (the latter being Information Security, Source: NIST SP 800-59; SP 800-53; SP800-53A; SP 800-60; CNSSI-4009; FIPS 199; 44 U.S.C., Sec. 3542). For example; a SCADA server can be deemed perfectly functional with no real SCADA data present. A newly-deployed SCADA server functions at the instant of being commissioned before real SCADA data is input.
The introduction of the concepts of management plane and data plane which are referenced in question 8 is a useful addition to the NERC CIP discussion because it enables appropriate controls to specifically protect systems or data.
Q4. Such (shared infrastructure) configurations are not addressed explicitly in CIP-005-5. Are modifications required to address the issue?
A4. CIP-005-5 would benefit from being modified to a security objective-oriented standard rather than a requirements-based standard. The security objective in this case would be isolation of CIP-applicable Cyber Assets from Cyber Assets that are out of scope of CIP controls. The mechanisms of that protection are primarily Boundary Protection and Control of Network Ports, Protocols, and Services (SANS 20 Critical Security Controls).
CIP v5 narrowly focuses on routable protocols and Layer 3 controls and does not address the other layers of the OSI model. For example, under CIP-005-5 Layer 2 protocols are not addressed and can convey malware as well as allow information exfiltration and cyber-attacks even if no routable IP communications are present. Controls for these protocols should not be limited to or defined by Layer 3/4 ACLs on a firewall or router as the only or even the best means of achieving in-bound and out-bound access control. Entities need the opportunity to provide technical controls at whatever conceptual layer is appropriate to meet the security objective.
I recommend retiring the ESP construct in favor of security zones. When framed in terms of Boundary Protection, a security zone is more inclusive and granular because it is not limited to routable protocols at the OSI Model’s Layer 3. A security zone construct does not force any particular interpretation or control onto serial or other non-routable means of transporting data or accessing the management plane of any systems. Security zones apply to physical and logical separation equally. An example of logical isolation provided by other than ACLs would be when a hypervisor provides isolation between Guest VMs or between Virtualized Network Functions. This isolation is implemented in the control plane by means of logic embedded in code base (NIST SP 800-125A – Draft, Section 1.2: Hypervisor Baseline Functions) and not at a conceptual network layer.
Current CIP standards take a broad stroke approach by requiring the protection of all cyber assets within an ESP in a singular manner at the highest impact level of controls ("High Water Mark"). Further, High Water Mark is applied to the impact rating of the BES Asset or Facility, and not to the impact rating or risk level of the Cyber System itself. This is not cost effective or flexible enough for individual entities’ needs. Security zones provide a scalable means of appropriately protecting Cyber Systems of differing security risks by further isolation within the zone.
Q5. The SDT asserts that VLANs providing logical isolation are not addressed explicitly in CIP-005-5, and controls may be necessary to isolate BES Cyber Systems. Are the current requirements of CIP-005-5 sufficient to address logical isolation using VLANs? Please provide your rationale.
A5. The same modifications necessary to make CIP-005-5 adequate to question 4 would apply to addressing the specific question of 802.1 Q VLANs providing adequate logical isolation in question 5. The security objective should be to provide isolation by means of Boundary Protection as well as Control of Network Ports, Protocols, and Services. Legacy software vulnerabilities that have long since been patched or known exploits that are mitigated through proper configuration should not require the blanket rejection of VLANs as a component of a particular entity’s specific security scheme. Newly discovered exploits and vulnerabilities are addressed through CIP-007 testing and patching, CIP-010 baseline configuration, change management, vulnerability scanning and assessment.
Q6. Do you agree with the proposed definition of CMS (Centralized Management Systems)? If not, please provide alternative language for the definition and your rationale.
A6. The SDT’s proposed definition of CMS captures most types of systems that support automation with a large span of control and privileged access. A similar span of control risk exists in that EACMS is a type of CMS for electronic access but the term EACMS is specific to NERC CIP and used nowhere else in IT Security or Information Assurance in any other industry. This inherently limits the amount of expertise, guidance, and documentation available for solving the root problem of controlling access to CIP-applicable systems.
The SDT should retire the NERC CIP defined term Electronic Access Control & Monitoring System from the NERC Glossary and adopt the industry solution Authentication, Authorization, and Accounting System (AAA System). Non-standard jargon should be avoided when adequate terms and concepts exist already.
Further, the SDT should clarify in Guidelines and Technical Basis, that:
- AAA clients that subscribe to AAA services (e.g. via a protocol such as LDAP, RADIUS or TACACS+) but do not maintain any account information are not AAA Systems in themselves
- Remote access clients or terminal emulators that are used to connect to a CMS, are not a CMS in themselves
Q7. Do you agree with the SDT’s approach to reference the CMS specifically as a type of applicable system in the CIP standards? Please provide your rationale.
A7. The inherent risk in such (centralized management) systems’ span of control and privileged access to CIP-applicable Cyber Systems should be addressed in support of the security objective of protecting BES Cyber Systems from threats in the data plane and isolation of the management plane (out of band management).
Q8. Do you agree with the SDT’s approach to require the isolation between the data plane and the management plane?
A8. Cautiously agree with the SDT’s proposal to require isolation between Data Plane and Management Plane for centralized management systems when system capability allows and risk justifies it (i.e. Hgih and Medium Risk Control Centers). We caution the SDT against overly rigid prescriptions for providing isolation. Combinations of other controls may afford the same or better protection in a particular circumstance. When the use of automated tools can improve security and manageability, it is important to avoid discouraging automation with overly burdensome compliance requirements.
Q9. Do you agree with limiting the applicability to high and medium impact Control Centers?
A9. Limiting applicability only to those facilities such as High and Medium Control Centers with the highest level of risk is reasonable, and there may be exceptions to those as well. Combinations of other controls may afford the same or better protection in a particular circumstance.
wonderful post! Thank you for sharing this infowith us.keep updating imwould like to know more
ReplyDeleteupdates on this topic very useful context I would i like to suggest this blog to my friend.
cloud computing training centers in chennai
Cloud Computing Certification in Chennai
This blog post sharing valuable information on security operations. Here I found very important information on OT Asset Discovery.
ReplyDeleteYou make so many great points here that I read your article a couple of times. Your views are in accordance with my own for the most part. This is great content for your readers. West texas IT solutions
ReplyDelete