Security Baseline for Substation Automation Systems
Abstract
:1. Introduction
Main Contributions
2. Cyber Security in Substation Automation Systems
- Standards containing an overview and terminology—ISO/IEC 27000.
- Standards specifying requirements—ISO/IEC 27001, ISO/IEC 27006, ISO/IEC 27009.
- Standards describing general guidelines—ISO/IEC 27002, ISO/IEC 27003, ISO/IEC 27004, ISO/IEC 27005, ISO/IEC 27007, ISO/IEC 27014.
- Standards describing industry-specific guidelines—ISO/IEC 27011, ISO/IEC 27019, ISO/IEC 27799.
2.1. Technological Constraints
2.2. Legal Aspects
2.3. International Standards
2.4. New Trends in Substation Automation Security
- Anomaly detection: machine learning algorithms can analyze large volumes of data to identify patterns and detect anomalies. In the context of security, this can be used to detect unusual or suspicious behavior such as network intrusions, fraud, or malware.
- Intrusion detection and prevention: Machine learning techniques can be used to create robust intrusion detection and prevention systems. By training models on historical data, they can learn to recognize patterns associated with different types of attacks and alert security personnel or automatically block suspicious activity.
- Malware detection: Deep learning models, particularly convolutional neural networks (CNNs), have proven to be very effective in detecting and classifying malware. By learning from large datasets of known malware samples, these models can identify new and emerging threats based on their characteristics and behavior.
- User authentication: machine learning can improve user authentication mechanisms by analyzing various factors such as keystroke dynamics, biometrics, or behavioral patterns. These models can learn to distinguish between genuine users and imposters, which helps prevent unauthorized access.
- Threat detection: machine learning can help analyze vast amounts of security data, including threat feeds, vulnerability databases and security reports. By processing this information, machine learning models can provide valuable insights into emerging threats, identify patterns and help security teams proactively respond to potential risks.
- Predictive analytics: by leveraging historical data and applying machine learning algorithms, security professionals can develop predictive models that anticipate potential security breaches or vulnerabilities. This allows proactive measures to be taken, such as patching systems or strengthening defenses in advance.
- Cyber security automation: machine learning can automate several security tasks such as log analysis, event correlation, and incident response. This reduces the burden on security personnel and enables faster detection and response to security incidents.
- Fraud detection: Machine learning techniques can be used to identify fraudulent activity in a variety of areas, including financial transactions, e-commerce, and online advertising. By learning from past fraud patterns, models can detect suspicious behavior and flag potentially fraudulent activity in real-time.
3. Substation Architecture Model
3.1. Typical Technical Assets
- graphical user interfaces (GUIs) accept input through devices such as a computer keyboard and mouse and provide graphical output on a computer monitor.
- Web user interfaces receive input and provide output by generating web pages that are transmitted over the network and viewed by the user using a web browser. The operator must be able to control the system and assess the state of the system.
- An input that allows users to control devices (actuators, RTUs, etc.),
- Output that provides output to the user.
3.2. Risks and Threats
4. Security Baseline Proposal
Scope Unchanged − Roundup(Minimum [(Impact + Exploitability), 10])
Scope Changed − Roundup(Minimum [1.08 × (Impact + Exploitability), 10])
Scope Changed 7.52 × [ISCBase − 0.029] − 3.25 × [ISCBase − 0.02]15
4.1. Excluded Areas of ISO 27001
4.2. Security Baseline for Power Distribution Control Systems
5. Conclusions
- Considers the heterogeneity and propriety of individual solutions according to the supplier, but also maps individual functionalities into a generalized Modified Purdue model of the electrical substation system, simplifying risk analysis and utilization of standard assets.
- Provides the supplier with a comprehensive clear checklist of safety requirements, the fulfillment of which meets national and international safety legislation and safety standards. The specific technical solution is then usable on the global market, and from the supplier’s point of view, it is difficult to standardize it.
- It provides transmission and distribution network operators with clear instructions on how to define security requirements for the supply chain, including solutions for their fulfillment, which has also been approved by the National Agency for Information and Cyber Security, which is responsible for checking the fulfillment of national security requirements.
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Acknowledgments
Conflicts of Interest
References
- Gunduz, M.Z.; Das, R. Cyber-security on Smart Grid: Threats and Potential Solutions. Comput. Netw. 2020, 169, 107094. [Google Scholar] [CrossRef]
- Pavon, W.; Inga, E.; Simani, S.; Nonato, M. A Review on Optimal Control for the Smart Grid Electrical Substation Enhancing Transition Stability. Energies 2021, 14, 8451. [Google Scholar] [CrossRef]
- Abrahamsen, F.E.; Ai, Y.; Cheffena, M. Communication Technologies for Smart Grid: A Comprehensive Survey. Sensors. 2021, 21, 8087. [Google Scholar] [CrossRef] [PubMed]
- Adamiak, M.; Falk, H. Wide Area Implementations of IEC 61850 Substation Systems. In IEC 61850 Principles and Applications to Electric Power Systems; Bishop, P., Nair, N.K.C., Eds.; CIGRE Green Books; Springer: Cham, Switzerland, 2022. [Google Scholar]
- Chehri, A.; Fofana, I.; Yang, X. Security Risk Modeling in Smart Grid Critical Infrastructures in the Era of Big Data and Artificial Intelligence. Sustainability 2021, 13, 3196. [Google Scholar] [CrossRef]
- Lázaro, J.; Astarloa, A.; Rodríguez, M.; Bidarte, U.; Jiménez, J. Survey on Vulnerabilities and Countermeasures in the Communications of the Smart Grid. Electronics 2021, 10, 1881. [Google Scholar] [CrossRef]
- Zhang, H.; Liu, B.; Wu, H. Smart Grid Cyber-Physical Attack and Defense: A Review. IEEE Access 2021, 9, 29641–29659. [Google Scholar] [CrossRef]
- Pandey, J.C.; Kalra, M. A Review of Security Concerns in Smart Grid. In Innovative Data Communication Technologies and Application; Raj, J.S., Kamel, K., Lafata, P., Eds.; Lecture Notes on Data Engineering and Communications Technologies; Springer: Singapore, 2022; Volume 96. [Google Scholar]
- Mavale, S.; Katade, J.; Dunbray, N.; Nimje, S. Review of Cyber-Attacks on Smart Grid System. In Proceedings of Third International Conference on Communication, Computing and Electronics Systems; Bindhu, V., Tavares, J.M.R.S., Du, K.L., Eds.; Lecture Notes in Electrical Engineering; Springer: Singapore, 2022; Volume 844. [Google Scholar]
- Krause, T.; Ernst, R.; Klaer, B.; Hacker, I.; Henze, M. Cybersecurity in power grids: Challenges and opportunities. Sensors 2021, 21, 6225. [Google Scholar] [CrossRef] [PubMed]
- Mokhor, V.; Honchar, S.; Onyskova, A. Cybersecurity Risk Assessment of Information Systems of Critical Infrastructure Objects. In Proceedings of the 2020 IEEE International Conference on Problems of Infocommunications. Science and Technology (PIC S&T), Kharkiv, Ukraine, 6–9 October 2020; pp. 19–22. [Google Scholar]
- Daria, G.; Massel, A. Intelligent System for Risk Identification of Cybersecurity Violations in Energy Facility. In Proceedings of the 2018 3rd Russian-Pacific Conference on Computer Technology and Applications (RPC), Vladivostok, Russia, 18–25 August 2018; pp. 1–5. [Google Scholar]
- Xiao, S.; Ye, Y.; Kanwal, N.; Newe, T.; Lee, B. SoK: Context and Risk Aware Access Control for Zero Trust Systems. Secur. Commun. Netw. 2022, 2022, 7026779. [Google Scholar] [CrossRef]
- Mrabet, Z.E.; Kaaboucha, N.; Ghazi, H.E.; Ghazi, H.E. Cyber-security in smart grid: Survey and challenges. Comput. Electr. Eng. 2018, 67, 469–482. [Google Scholar] [CrossRef] [Green Version]
- Rawat, D.B.; Bajracharya, C. Cyber security for smart grid systems: Status, challenges and perspectives. SoutheastCon 2015, 2015, 15240672. [Google Scholar]
- Khan, Z.A.; Herrmann, P. Recent Advancements in Intrusion Detection Systems for the Internet of Things. Secur. Commun. Netw. 2019, 2019, 4301409. [Google Scholar] [CrossRef] [Green Version]
- Gunduz, M.Z.; Das, R. A comparison of cyber-security oriented testbeds for IoT-based smart grids. In Proceedings of the 2018 6th International Symposium on Digital Forensic and Security (ISDFS), Antalya, Turkey, 22–25 March 2018; pp. 1–6. [Google Scholar]
- NIST. NIST Framework and Roadmap for Smart Grid Interoperability Standards Release 2.0; National Institute of Standards and Technology, Special Publication 1108R2; NIST: Gaithersburg, MD, USA, 2012. [Google Scholar]
- López, G.; Moura, P.; Moreno, J.I.; Camacho, J.M. Multi-Faceted Assessment of a Wireless Communications Infra-structure for the Green Neighborhoods of the Smart Grid. Energies 2014, 7, 3453–3483. [Google Scholar] [CrossRef] [Green Version]
- Baul, A.; Sarker, G.C.; Sadhu, P.K.; Yanambaka, V.P.; Abdelgawad, A. XTM: A Novel Transformer and LSTM-Based Model for Detection and Localization of Formally Verified FDI Attack in Smart Grid. Electronics 2023, 12, 797. [Google Scholar] [CrossRef]
- Haq, E.U.; Xu, H.; Pan, L.; Khattak, M.I. Smart Grid Security: Threats and Solutions. In Proceedings of the 2017 13th Inter-national Conference on Semantics, Knowledge and Grids (SKG), Beijing, China, 13–14 August 2017; pp. 188–193. [Google Scholar]
- EU. Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 Concerning Measures for a High Common Level of Security of Network and Information Systems across the Union; EU: Brusel, Belgium, 2016. [Google Scholar]
- Leszczyna, R. Cybersecurity in the Electricity Sector—Managing Critical Infrastructure; Springer: Cham, Switzerland, 2019; ISBN 978-3-030-19537-3. [Google Scholar]
- EU. Proposal for a Directive of the European Parliament and of the Council on Measures for a High Common Level of Cybersecurity across the Union, Repealing Directive (EU) 2016/1148; EU: Brusel, Belgium, 2020. [Google Scholar]
- Hernandez-Ramos, J.L.; Geneiatakis, D.; Kounelis, I.; Steri, G.; Fovino, I.N. Toward a Data-Driven Society: A Technological Perspective on the Development of Cybersecurity and Data-Protection Policies. IEEE Secur. Priv. 2020, 18, 28–38. [Google Scholar] [CrossRef]
- Krzykowski, M. Legal Aspects of Cybersecurity in the Energy Sector-Current State and Latest Proposals of Legislative Changes by the EU. Energies 2021, 28, 14. [Google Scholar] [CrossRef]
- Curtis, P.D.; Mehravari, N. Evaluating and Improving Cybersecurity Capabilities of the Energy Critical Infrastructure. In Proceedings of the 2015 IEEE International Symposium on Technologies for Homeland Security (HST), Waltham, MA, USA, 14–16 April 2015; pp. 1–6. [Google Scholar]
- Nazir, H.M.J.; Han, W. Proliferation of Cyber Situational Awareness: Today’s Truly Pervasive Drive of Cybersecurity. Secur. Commun. Netw. 2022, 2022, 6015253. [Google Scholar] [CrossRef]
- Sarker, E.; Halder, P.; Seyedmahmoudian, M.; Jamei, E.; Horan, B.; Mekhilef, S.; Stojcevski, A. Progress on the Demand Side Management in Smart Grid and Optimization Approaches. Int. J. Energy Res. 2021, 45, 36–64. [Google Scholar] [CrossRef]
- Lyulyov, O.; Vakulenko, I.; Pimonenko, T.; Kwilinski, A.; Dzwigol, H.; Dzwigol-Barosz, M. Comprehensive assessment of smart grids: Is there a universal approach? Energies 2021, 14, 3497. [Google Scholar] [CrossRef]
- Omitaomu, O.A.; Niu, H. Artificial Intelligence Techniques in Smart Grid: A Survey. Smart Cities 2021, 4, 548–568. [Google Scholar] [CrossRef]
- Guru, D.; Perumal, S.; Varadarajan, V. Approaches towards Blockchain Innovation: A Survey and Future Directions. Electronics 2021, 10, 1219. [Google Scholar] [CrossRef]
- Alrowais, F.; Marzouk, R.; Nour, M.K.; Mohsen, H.; Hilal, A.M.; Yaseen, I.; Alsaid, M.I.; Mohammed, G.P. Intelligent Intrusion Detection Using Arithmetic Optimization Enabled Density Based Clustering with Deep Learning. Electronics 2022, 11, 3541. [Google Scholar] [CrossRef]
- Figueiredo, J.; Serrão, C.; de Almeida, A.M. Deep Learning Model Transposition for Network Intrusion Detection Systems. Electronics 2023, 12, 293. [Google Scholar] [CrossRef]
- Rabie, O.B.J.; Balachandran, P.K.; Khojah, M.; Selvarajan, S. A Proficient ZESO-DRKFC Model for Smart Grid SCADA Security. Electronics 2022, 11, 4144. [Google Scholar] [CrossRef]
- Mazhar, T.; Irfan, H.M.; Haq, I.; Ullah, I.; Ashraf, M.; Shloul, T.A.; Ghadi, Y.Y.; Imran; Elkamchouchi, D.H. Analysis of Challenges and Solutions of IoT in Smart Grids Using AI and Machine Learning Techniques: A Review. Electronics 2023, 12, 242. [Google Scholar] [CrossRef]
- Urrea, C.; Morales, C. Enhancing Modbus-RTU Communications for Smart Metering in Building Energy Management Systems. Secur. Commun. Netw. 2019, 2019, 7010717. [Google Scholar] [CrossRef]
- Xiao, L. Construction Technology and Quality Control of Power and Electrical Engineering Based on Convolutional Neural Network. Secur. Commun. Netw. 2021, 1–15. [Google Scholar] [CrossRef]
- Alazab, M.; Tang, M. (Eds.) Deep Learning Applications for Cyber Security; Springer: Cham, Switzerland, 2019. [Google Scholar]
- Nguyen, T.T.; Reddi, V.J. Deep Reinforcement Learning for Cyber Security. IEEE Trans. Neural. Netw. Learn Syst. 2021, 34, 3779–3795. [Google Scholar] [CrossRef] [PubMed]
- Liu, H.; Lang, B. Machine Learning and Deep Learning Methods for Intrusion Detection Systems: A Survey. Appl. Sci. 2019, 9, 4396. [Google Scholar] [CrossRef] [Green Version]
- Susilo, B.; Sari, R.F. Intrusion Detection in IoT Networks Using Deep Learning Algorithm. Information 2020, 11, 279. [Google Scholar] [CrossRef]
- Thapa, N.; Liu, Z.; KC, D.B.; Gokaraju, B.; Roy, K. Comparison of Machine Learning and Deep Learning Models for Network Intrusion Detection Systems. Future Internet 2020, 12, 167. [Google Scholar] [CrossRef]
- Gupta, C.; Johri, I.; Srinivasan, K.; Hu, Y.-C.; Qaisar, S.M.; Huang, K.-Y. A Systematic Review on Machine Learning and Deep Learning Models for Electronic Information Security in Mobile Networks. Sensors 2022, 22, 2017. [Google Scholar] [CrossRef]
- Alkahtani, H.; Aldhyani, T.H.H. Developing Cybersecurity Systems Based on Machine Learning and Deep Learning Algorithms for Protecting Food Security Systems: Industrial Control Systems. Electronics 2022, 11, 1717. [Google Scholar] [CrossRef]
- Akhtar, M.S.; Feng, T. Detection of Malware by Deep Learning as CNN-LSTM Machine Learning Techniques in Real Time. Symmetry 2022, 14, 2308. [Google Scholar] [CrossRef]
- Xu, C.; Liao, Z.; Li, C.; Zhou, X.; Xie, R. Review on Interpretable Machine Learning in Smart Grid. Energies 2022, 15, 4427. [Google Scholar] [CrossRef]
- Moti, M.M.M.A.; Uddin, R.S.; Hai, M.A.; Saleh, T.B.; Alam, M.G.R.; Hassan, M.M.; Hassan, M.R. Blockchain Based Smart-Grid Stackelberg Model for Electricity Trading and Price Forecasting Using Reinforcement Learning. Appl. Sci. 2022, 12, 5144. [Google Scholar] [CrossRef]
- Piotrowski, P.; Baczyński, D.; Kopyt, M.; Gulczyński, T. Advanced Ensemble Methods Using Machine Learning and Deep Learning for One-Day-Ahead Forecasts of Electric Energy Production in Wind Farms. Energies 2022, 15, 1252. [Google Scholar] [CrossRef]
- Alrasheedi, A.; Almalaq, A. Hybrid Deep Learning Applied on Saudi Smart Grids for Short-Term Load Forecasting. Mathematics 2022, 10, 2666. [Google Scholar] [CrossRef]
- Habbak, H.; Mahmoud, M.; Metwally, K.; Fouda, M.M.; Ibrahem, M.I. Load Forecasting Techniques and Their Ap-plications in Smart Grids. Energies 2023, 16, 1480. [Google Scholar] [CrossRef]
- Ibrahim, B.; Rabelo, L.; Gutierrez-Franco, E.; Clavijo-Buritica, N. Machine Learning for Short-Term Load Forecasting in Smart Grids. Energies 2022, 15, 8079. [Google Scholar] [CrossRef]
- Mazhar, T.; Irfan, H.M.; Khan, S.; Haq, I.; Ullah, I.; Iqbal, M.; Hamam, H. Analysis of Cyber Security Attacks and Its Solutions for the Smart grid Using Machine Learning and Blockchain Methods. Future Internet 2023, 15, 83. [Google Scholar] [CrossRef]
- Strom, B.E.; Applebaum, A.; Miller, D.P.; Nickels, K.C.; Pennington, A.G.; Thomas, C.B. MITRE ATT&CK: Design and Philosophy. 2020. Available online: https://attack.mitre.org/docs/ATTACK_for_ICS_Philosophy_March_2020.pdf (accessed on 8 February 2023).
- Ackerman, P. Industrial Cybersecurity: Efficiently Secure Critical Infrastructure Systems, 1st ed.; Packt Publishing: Birmingham, NI, USA, 2017; ISBN 978-1788395151. [Google Scholar]
- Few, C.; Thompson, J.; Awuson-David, K.; Al-Hadhrami, T. A Case Study in the Use of Attack Graphs for Predicting the Security of Cyber-Physical Systems. In Proceedings of the 2021 International Congress of Advanced Technology and Engineering (ICOTEN), Taiz, Yemen, 4–5 July 2021; pp. 1–7. [Google Scholar]
- Jha, A.V.; Ghazali, A.N.; Appasani, B.; Mohanta, D.K. Risk Identification and Risk Assessment of Communication Networks in Smart Grid Cyber-Physical Systems. In Security in Cyber-Physical Systems, Proceedings of the 2021 International Conference on Advanced Informatics for Computing Research (ICAICR), Gurugram, India, 18–19 December 2021; Awad, A.I., Ed.; Springer: Singapore, 2021; pp. 97–107. [Google Scholar]
- The MITRE Enterprise Matrix. Available online: https://attack.mitre.org/matrices/enterprise/ (accessed on 8 February 2023).
- ISO/IEC 27005; Information Technology—Security Techniques—Information Security Risk Management. Česká agentura pro standardizaci: Prague, Czech Republic, 2019.
- Common Vulnerability Scoring System Version 3.1 Calculator. Forum of Incident Response and Security Teams, 2015–2022. Available online: https://www.first.org/cvss/calculator/3.1 (accessed on 21 July 2022).
- EN IEC 62443-3-3; Industrial Communication Networks—Network and System Security—Part 3-3: System Security Re-Quirements and Security Levels. Czech Agency for Standardization: Prague, Czech Republic, 2019.
- EN IEC 62443-4-2; Security for Industrial Automation and Control Systems—Part 4-2: Technical Security Requirements for IACS Components. Czech Agency for Standardization: Prague, Czech Republic, 2019.
- EN ISO/IEC 27001; Information Technology—Security Techniques—Information Security Management Systems—Requirements. Czech Agency for Standardization: Prague, Czech Republic, 2014.
- The MITRE Corporation. Access Management. 2022. Available online: https://attack.mitre.org/mitigations/M0801/ (accessed on 8 February 2023).
- The MITRE Corporation. Account Use Policies. 2022. Available online: https://attack.mitre.org/mitigations/M0936/ (accessed on 8 February 2023).
- The MITRE Corporation. Antivirus/Antimalware. 2022. Available online: https://attack.mitre.org/mitigations/M0949// (accessed on 8 February 2023).
- The MITRE Corporation. Authorization Enforcement. 2022. Available online: https://attack.mitre.org/mitigations/M0800/ (accessed on 9 February 2023).
- The MITRE Corporation. Code Signing. 2021. Available online: https://attack.mitre.org/mitigations/M0945/ (accessed on 9 February 2023).
- The MITRE Corporation. Data Backup. 2022. Available online: https://attack.mitre.org/mitigations/M0953/ (accessed on 9 February 2023).
- The MITRE Corporation. Disable or Remove Feature or Program. 2022. Available online: https://attack.mitre.org/mitigations/M0942/ (accessed on 8 February 2023).
- The MITRE Corporation. Execution Prevention. 2022. Available online: https://attack.mitre.org/mitigations/M0938/ (accessed on 9 February 2023).
- The MITRE Corporation. Exploit Protection. 2022. Available online: https://attack.mitre.org/mitigations/M0950/ (accessed on 8 February 2023).
- The MITRE Corporation. Limit Hardware Installation. 2022. Available online: https://attack.mitre.org/mitigations/M0934/ (accessed on 11 February 2023).
- The MITRE Corporation. Mechanical Protection Layers. 2022. Available online: https://attack.mitre.org/mitigations/M0805/ (accessed on 8 February 2023).
- The MITRE Corporation. Network Allowlists. 2022. Available online: https://attack.mitre.org/mitigations/M0807/ (accessed on 11 February 2023).
- The MITRE Corporation. Network Segmentation. 2022. Available online: https://attack.mitre.org/mitigations/M0930/ (accessed on 8 February 2023).
- The MITRE Corporation. Operating System Configuration. 2022. Available online: https://attack.mitre.org/mitigations/M0928/ (accessed on 8 February 2023).
- The MITRE Corporation. Out-of-Band Communications Channel. 2022. Available online: https://attack.mitre.org/mitigations/M0810/ (accessed on 11 February 2023).
- The MITRE Corporation. Privileged Account Management. 2022. Available online: https://attack.mitre.org/mitigations/M0926/ (accessed on 5 February 2023).
- The MITRE Corporation. Restrict File and Directory Permissions. 2022. Available online: https://attack.mitre.org/mitigations/M0922/ (accessed on 11 February 2023).
- The MITRE Corporation. Restrict Registry Permissions. 2022. Available online: https://attack.mitre.org/mitigations/M0924/ (accessed on 12 February 2023).
- The MITRE Corporation. Restrict Web-Based Content. 2022. Available online: https://attack.mitre.org/mitigations/M0921/ (accessed on 12 February 2023).
- The MITRE Corporation. Vulnerability Scanning. 2022. Available online: https://attack.mitre.org/mitigations/M0916/ (accessed on 12 February 2023).
- The MITRE Corporation. Watchdog Timers. 2022. Available online: https://attack.mitre.org/mitigations/M0815/ (accessed on 12 February 2023).
- The MITRE Corporation. Active Directory Configuration. 2022. Available online: https://attack.mitre.org/mitigations/M0915/ (accessed on 15 February 2023).
- The MITRE Corporation. Application Developer Guidance. 2022. Available online: https://attack.mitre.org/mitigations/M0913/ (accessed on 15 February 2023).
- The MITRE Corporation. Application Isolation and Sandboxing. 2022. Available online: https://attack.mitre.org/mitigations/M0948/ (accessed on 14 February 2023).
- The MITRE Corporation. Audit. 2022. Available online: https://attack.mitre.org/mitigations/M0947/ (accessed on 12 February 2023).
- The MITRE Corporation. Boot Integrity. 2022. Available online: https://attack.mitre.org/mitigations/M0946/ (accessed on 12 February 2023).
- The MITRE Corporation. Communication Authenticity. 2022. Available online: https://attack.mitre.org/mitigations/M0802/ (accessed on 12 February 2023).
- The MITRE Corporation. Data Loss Prevention. 2022. Available online: https://attack.mitre.org/mitigations/M0803/ (accessed on 15 February 2023).
- The MITRE Corporation. Encrypt Network Traffic. 2022. Available online: https://attack.mitre.org/mitigations/M0808/ (accessed on 15 February 2023).
- The MITRE Corporation. Encrypt Sensitive Information. 2022. Available online: https://attack.mitre.org/mitigations/M0941/ (accessed on 12 February 2023).
- The MITRE Corporation. Filter Network Traffic. 2022. Available online: https://attack.mitre.org/mitigations/M0937/ (accessed on 12 February 2023).
- The MITRE Corporation. Human User Authentication. 2022. Available online: https://attack.mitre.org/mitigations/M0804/ (accessed on 15 February 2023).
- The MITRE Corporation. Limit Access to Resource over Network. 2022. Available online: https://attack.mitre.org/mitigations/M0935/ (accessed on 15 February 2023).
- The MITRE Corporation. Minimize Wireless Signal Propagation. 2022. Available online: https://attack.mitre.org/mitigations/M0806/ (accessed on 25 February 2023).
- The MITRE Corporation. Mitigation Limited or Not Effective. 2022. Available online: https://attack.mitre.org/mitigations/M0816/ (accessed on 25 February 2023).
- The MITRE Corporation. Multi-Factor Authentication. 2022. Available online: https://attack.mitre.org/mitigations/M0932/ (accessed on 23 February 2023).
- The MITRE Corporation. Network Intrusion Prevention. 2022. Available online: https://attack.mitre.org/mitigations/M0931/ (accessed on 23 February 2023).
- The MITRE Corporation. Operational Information Confidentiality. 2022. Available online: https://attack.mitre.org/mitigations/M0809/ (accessed on 15 February 2023).
- The MITRE Corporation. Password Policies. 2022. Available online: https://attack.mitre.org/mitigations/M0927/ (accessed on 5 February 2023).
- The MITRE Corporation. Redundancy of Service. 2022. Available online: https://attack.mitre.org/mitigations/M0811/ (accessed on 26 February 2023).
- The MITRE Corporation. Restrict Library Loading. 2022. Available online: https://attack.mitre.org/mitigations/M0944/ (accessed on 26 February 2023).
- The MITRE Corporation. Safety Instrumented Systems. 2022. Available online: https://attack.mitre.org/mitigations/M0812/ (accessed on 15 February 2023).
- The MITRE Corporation. Software Configuration. 2022. Available online: https://attack.mitre.org/mitigations/M0954/ (accessed on 15 February 2023).
- The MITRE Corporation. Software Process and Device Authentication. 2022. Available online: https://attack.mitre.org/mitigations/M0813/ (accessed on 18 February 2023).
- The MITRE Corporation. SSL/TLS Inspection. 2022. Available online: https://attack.mitre.org/mitigations/M0920/ (accessed on 12 February 2023).
- The MITRE Corporation. Static Network Configuration. 2022. Available online: https://attack.mitre.org/mitigations/M0814/ (accessed on 3 February 2023).
- The MITRE Corporation. Supply Chain Management. 2022. Available online: https://attack.mitre.org/mitigations/M0817/ (accessed on 15 February 2023).
- The MITRE Corporation. Threat Intelligence Program. 2022. Available online: https://attack.mitre.org/mitigations/M0919/ (accessed on 19 February 2023).
- The MITRE Corporation. Update Software. 2022. Available online: https://attack.mitre.org/mitigations/M0951/ (accessed on 15 February 2023).
- The MITRE Corporation. User Account Management. 2022. Available online: https://attack.mitre.org/mitigations/M0918/ (accessed on 16 February 2023).
- The MITRE Corporation. User Training. 2022. Available online: https://attack.mitre.org/mitigations/M0917/ (accessed on 11 February 2023).
Network Layer | Confidentiality | Integrity | Availability |
---|---|---|---|
Application Layer | Data-Injection Attack | - | LDoS, HTTP Flooding, Buffer Overflow |
Transport Layer | IP-Spoofing, Data-Injection, Sniffing, MITM, Password Pilfering Attacks | Replay, Covert, Wormhole, Data-Injection, MITM, Spoofing Attacks | Wormhole, MITM, Buffer Overflow, Buffer Flooding, DdoS Attacks |
MAC Layer | ARP-Spoofing, Traffic Analysis, MITM Attacks | ARP-Spoofing, TSA, MITM Attacks | Spoofing, TSA, Jamming, DdoS, Flooding, MITM Attacks |
Physical Layer | Eavesdropping | Smart Meter Tampering Attacks, TSA | Jamming Attacks, TSA |
Id | Mitigating Measures | Description of Measures | NIST SP 800-53 REV. 4 | IEC 62443-3-3:2013 | IEC 62443-4-2:2019 | ISO 27001 | DOCS |
---|---|---|---|---|---|---|---|
M_01 | Access Management [64] | Technical measures using Access Management technology are used to enforce authorization policies, especially when existing devices in the substation do not provide sufficient capabilities to support user identification and authentication. These technologies are typically used for in-line network devices or gateways to prevent access by unauthenticated users. They are integrated with an authentication service for the initial authentication of user credentials. The measure is directly linked to the organizational measures set out in §12 of the DoCS, the implementation of which is an integral part of a functional Access Management system. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation covers access to HW, especially SW platforms. | AC-3 | SR 2.1 | CR 2.1 | A.9.1, A.9.2, A.9.3, A.9.4 | §12. §19, §20, §25, §26 |
M_02 | Account Use Policies [65] | The technical measure reflects the need to configure functions related to the use of the account, e.g., locking the account for a given number of unsuccessful login attempts, setting specific login times, etc. The measure has a direct link to the organizational measures mentioned in §4, where it is necessary to have asset management in place for relevant settings of Account Use Policies, as well as §10 reflecting traffic and communication management, §12 access control. It is also necessary to explicitly implement this measure in §13 Acquisition, Development, Maintenance based on the establishment of security policies and their transfer to supply and service contracts. Mitigation is the responsibility of the supplier and the configuration engineer. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | IA-5 | SR 1.11 | CR 1.11 | A.6.2, A.9.1, A.9.2, A.9.3, A.9.4, A.12.1, A.12.2, A.12.3, A.12.4, A.12.5 | §4, §10, §12, §13, §19, §22, §25, §26 |
M_03 | Antivirus/Antimalware [66] | It is a service used to detect malware. In industrial environments, antivirus/antimalware installations should be limited to resources that are not involved in critical or real-time operations to minimize the impact on system availability. All products must first be tested in a representative test environment prior to deployment on production systems. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation mainly covers protection to SW platforms. | SI-3 | SR 3.2 | CR 3.2 | A.8.3, A.12 | §10, §21 |
M_04 | Authorization Enforcement [67] | It is necessary to implement permission management on ICS equipment and systems according to RBAC procedures with emphasis on the allocation of minimum permissions. it is then appropriate to use the IEC 62351 standard in the ICS area for both user and system and operational processes. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | AC-3 | SR 2.1 | CR 2.1 | A.8.3, A.9.1, A.9.2, A.9.4, A.12.5 | §10, §12, §19, §25, §26, §28 |
M_05 | Code Signing [68] | Using digital signature authentication strengthens binary and application integrity to prevent the execution of untrusted code. The application of this measure must consider the technical limitations of Legacy systems that are in real-life operation and reflect this in the applicability statement, according to §5 of the DoCS. Mitigation is relevant in the supplier-customer relationship. Mitigation covers access to HW (firmware), especially SW platforms. | SI-7 | SR 3.4 | CR 3.4 | A.10.1, A.12.1, A.12.5, A.14.1, A.14.2 | §10, §11, §13, §25, §26, §28 |
M_06 | Data Backup [69] | When taking and storing backups of data from end-user systems and critical servers, it is necessary to ensure that backup and storage systems are enhanced to store backups in a separate offsite environment. Plans and responses to potential incidents, including backup image and configuration management for key systems, must be maintained and tested to enable rapid recovery to respond to attacker activity that affects the control, view, or availability of systems. Based on the asset management according to §4 and §5 of the DoCS, a process model per information and technical asset must be established with respect to the recovery plan, data value and configurations. Mitigation mainly covers protection to SW platforms and data. The design must come from the system architect. | CP-9 | SR 7.3 | CR 7.3 | A.6.2, A.12.1, A.12.3 | §4, §10, §27, § 28 |
M_07 | Disable or Remove Feature or Program [70] | This service is used to remove or deny access to unnecessary and potentially vulnerable software to prevent abuse by attackers. Only original systems and software directly related to its functions must be run on the substation. Technical implementation must be preceded by a comprehensive §4 asset management process. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation covers access to HW, especially SW platforms. | CM-7 | SR 7.7 | CM 7.7 | A.8.1, A.9.1, A.9.2, A.9.3, A.9.4 | §4, §12, §19, §25, §26 |
M_08 | Execution Prevention [71] | This is used to block the execution of code in ICS by the applications themselves and to block the execution of scripts. It is necessary to control the appropriate permissions with respect to inheritance of the subprocess generation framework. As part of the implementation of this measure, FAT tests shall be performed on the relevant test environment to maintain the full range of services provided, considering the maturity of the system and its dependency on other TR traffic management processes. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | SI-3 | SR 3.2 | CR 3.2 | A.9.4 | §12, §19, §25 |
M_09 | Exploit Protection [72] | A system for ensuring the detection and blocking of conditions leading to software misuse or abuse. The implementation of the measures shall consider any legacy systems operating in individual TRs and downstream systems. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation mainly covers protection to SW platforms and data. | SI-16 | SR 3.2 | CR 3.2 | A.8.3, A.9.4, A.12.1, A.12.5, A.14.1 | §10, §13, §18, §19, §25, §26 |
M_10 | Limit Hardware Installation [73] | This service shall block users or groups of users from installing or using unapproved hardware on substation systems, including USB devices. If, for example, a hardware key is required to run specialized substation systems, the physical perimeter protection of the, according to §17, must be increased and this solution must be reflected in the PoA. Mitigation is relevant in the supplier-customer relationship. Mitigation covers access to HW (firmware), especially SW platforms. | MP-7 | SR 3.2 | EDR 3.2 | A.11.2, A.12.1, A.14.1 | §10, §13, §17, §18, §21 |
M_11 | Mechanical Protection Layers [74] | Physical security is an integral part of cyber protection within layered (onion) protection. It is therefore necessary, from a security perspective, to address the location of the facility itself, its security, surveillance and its zoning, which allows us to effectively divide the individual elements of physical protection according to individual, embedded, access zones. Mitigation is related to the operational environment and is entirely the responsibility of the customer. It mainly covers access to HW platforms. | N/A | N/A | N/A | A.11.2 | §17 |
M_12 | Network Allowlists [75] | It is strongly recommended to implement lists of allowed networks and to determine for which connections (e.g., IP address, MAC address, port, protocol) connections can be made. Allowed protocol lists that operate at the application layer (e.g., DNP3, Modbus, HTTP) are described in M_32. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | AC-3 | N/A | N/A | A.13.1 | §18 |
M_13 | Network Segmentation [76] | The network design should include an isolated section for critical systems, functions or resources. Physical and logical segmentation may be used to prevent access to potentially sensitive systems and information. A DMZ or jumped approach may be used to secure the station bus and ensure that the critical assets are not accessible from the internal network. Furthermore, it is necessary to restrict network access to specific systems and services, in addition to securing and preventing systems from other networks from accessing critical management systems. For example, in IEC 62443, systems at the same security level should be grouped into a “zone” and access to this zone is restricted and mechanisms are in place to restrict data flows between zones by segmenting the network. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | AC-3 | SR 5.1 | CR 5.1 | A.13.1 | §18, §28 |
M_14 | Operating System Configuration [77] | Changes to the underlying operating system configuration are required to strengthen system protection against attackers. In this section, in addition to recommending vendors, the mitigation measures outlined in the AT&T Operating System Configuration Project are used effectively. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation is relevant in the supplier-customer relationship. Mitigation covers access to SW platforms in particular. | CM-7 | SR 7.7 | CR 7.7 | A.14.1 | §18, §28 |
M_15 | Out-of-Band Communications Channel [78] | Introduces alternative methods to support communication requests during communication failures and data integrity attacks. The implementation of this technical measure shall consider, on the basis of a risk analysis, possible warnings from the NCIB concerning technical and software resources. At the same time, the availability requirements for unified systems and data must be clearly identified. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | SC-37 | N/A | N/A | A.12.1, A.13.1 | §10, §11, §13, §18 |
M_16 | Privileged Account Management [79] | Rules for the creation, modification, use and permissions associated with privileged accounts, including the root account, must be established and clearly described. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation covers access to HW, especially SW platforms. | AC-2 | SR 1.3 | CR 1.3 | A.9.1, A.9.2, A.9.3, A.9.4 | §12, §19, §20 |
M_17 | Restrict File and Directory Permissions [80] | Rules for restricting access and setting permissions to directories and files that are not specific to users or privileged accounts must be set and clearly documented. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation covers access to HW, especially SW platforms. | AC-6 | SR 2.1 | CR 2.1 | A.12.1, A.12.2, A.12.3, A.12.4 | §10, §11, §13, §20, §25 |
M_18 | Restrict Registry Permissions [81] | Set restrictions on the ability to modify certain sub registers or keys in the MS Windows registry. Here it is recommended to follow the data sources available in the AT&T Windows Registry project area. The unique measures must be tested on an appropriate test environment. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation covers access to HW, especially SW platforms. | AC-6 | SR 2.1 | CR 2.1 | A.12.1, A.12.2, A.12.3, A.12.4 | §10, §11, §13, §25 |
M_19 | Restrict Web-Based Content [82] | It is necessary to implement strict restrictions on access to web services, block downloading/sending files, disable script execution, restrict installation of browser extensions, etc. Mitigation is relevant in the supplier-customer relationship. Mitigation covers access to SW platforms in particular. | SC-18 | SR 2.4 | HDR 2.4 | A.12.1, A.12.2, A.12.3, A.12.4 | §10, §11, §13, §25 |
M_20 | Vulnerability Scanning [83] | This measure is used to implement regular vulnerability scanning, which is used to find potentially exploitable software vulnerabilities and leads to their remediation. The implementation of this measure is dependent on the implementation of the §4 asset management and §5 risk management process. One effective solution is to implement a comprehensive configuration database of the system and its downstream processes. Mitigation is the responsibility of the vendor and the system architect. Mitigation is relevant in the supplier-customer relationship. Mitigation covers access to SW platforms in particular. | RA-5 | N/A | N/A | A.12.6 | §11, §25 |
M_21 | Watchdog Timers [84] | Implementation of Watchdog Timers, in order to provide early indication that a device or system is not responding. Mitigation covers not only access in HW but especially to SW platforms. The design must come from the system architect. | N/A | N/A | CR 7.2 | A.13.1 | §27 |
M_22 | Credential Access Protection | Some network devices are capable of storing passwords for local accounts, either in plain text or encrypted format. It is important to ensure that where technically possible, local passwords are always encrypted. Mitigation is the responsibility of the supplier and the configuration engineer. Mitigation covers access to HW, especially SW platforms. | IA-5 | SR 1.5 | CR 1.5 | A.10.1 | §18, §26 |
Id | Mitigating Measures | Description of Measures | NIST SP 800-53 REV. 4 | IEC 62443-3-3:2013 | IEC 62443-4-2:2019 | ISO 27001 | DOCS |
---|---|---|---|---|---|---|---|
M_23 | Active Directory Configuration [85] | When configuring Active Directory services, make sure that security identifier (SID) filtering, etc., is also used. The implementation of this technical support is significantly affected by the age of the deployed system. The implementation of this measure then supports the requirements specified in §4, §10 and §12. Its requirements need to be taken into account in the implementation of the §13 acquisition, development and maintenance principle. Mitigation is the responsibility of the vendor and the configuration engineer in necessary coordination with the system architect. Mitigation mainly covers protection to SW platforms and data. | N/A | N/A | N/A | A.6.2, A.8.1, A.8.3, A.9.2, A.9.4, A.12.1, A.12.4 | §4, §10, §12, §13, §19, §25, §26, §28 |
M_24 | Application Developer Guidance [86] | This is the documented provision of specific guidance and training to application developers to avoid implementing security weaknesses in software development that could be exploited by an attacker. These rules should be part of defined vendor relationships and their management. Mitigation is the responsibility of the vendor and the configuration engineer in necessary coordination with the system architect. Mitigation covers access to HW, especially SW platforms, including links to the continuity and recovery lanes. | AT-3 | N/A | N/A | A.15.5, A.14.1, A.14.2, A.14.3 | §8, §10, §11, §13, §25, §28 |
M_25 | Application Isolation and Sandboxing [87] | Restricts code execution on virtual environments or when transferring to end systems. It is recommended that this principle is also implemented in the maintenance services provided and in the transfer of all data between the public and internal communication infrastructure. In the substation area, these are physically separate data circuits, where any direct connection to other data circuits is not allowed. Mitigation is the responsibility of the vendor and the configuration engineer in necessary coordination with the system architect. Mitigation mainly covers protection to SW platforms and data. | SI-3 | SR 5.4 | CR 5.4 | A.9.4, A.12.1, A.12.5, A.14.2 | §10, §11. §13, §19, §25, §26. §28 |
M_26 | Audit [88] | To identify potential weaknesses, it is necessary to conduct audits and scans of systems, permissions, insecure software, insecure configurations, etc. Documented periodic device integrity checks, verifying the correctness of firmware, software, programs and configurations must be implemented. Integrity checks, which typically include cryptographic hashes or digital signatures, should be compared against checks obtained against known valid states, especially after events such as device reboots, program downloads, or program restarts. An audit should be implemented by both: the substation technology vendor and the substation operator. The possibilities of transferring audit outputs between stakeholders should be considered in contractual arrangements. Mitigation is intended for the customer side and its security and IT department. Both processes and HW and SW configurations are audited. | SI-7 | SR 3.4 | CR 3.4 | A.6.2, A.8.3, A.9.2, A.10.1, A.12.1, A.12.5, A.13.1, A.18.1, A.18.2 | §3, §10, §12, §16, §19, §24, §25, §26, §28, §30 |
M_27 | Boot Integrity [89] | The technical measure is based on the principle of using a secure method to boot the system and verify the integrity of the operating system and its loading mechanisms. The deployment of this technical measure is significantly dependent on the age of the compared systems. Mitigation is the responsibility of the vendor and the configuration engineer in necessary coordination with the system architect. Mitigation covers access to HW, especially SW platforms. | SI-7 | N/A | CR 3.14 | A.10.1, A.12.2, A.12.4, A.12.5, A.14.1, A.14.2, A.18.2 | §3, §10, §13, §16, §26, §21, §22, §25, §28 |
M_28 | Communication Authenticity [90] | When communicating over an untrusted network, it is necessary to use secure network protocols that authenticate the sender of the message and can verify its integrity. This can be done through 802.1x or digital signatures. The solution can detect spoofed network messages and unauthorized connections. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | SC-8; SC-23 | SR 3.1 | CR 3.1 | A.13.1 | §18 |
M_29 | Data Loss Prevention [91] | Data Loss Prevention (DLP) technology is commonly deployed to protect technology and technical data and information relevant to can generally be used to identify hostile attempts to penetrate operational information such as technical plans, trade secrets, configurations, intellectual property or process telemetry. DLP features can be built into other security products such as firewalls or standalone suites running as agents on the network. The DLP feature can be configured to prevent the transmission of information through corporate sources such as email, the web, and physical media such as USB in the case of hosted solutions. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | N/A | SR 4.1 | CR 4.1 | A.6.1, A.6.2, A.9.2, A.12.4 | §10, §11, §13, §12, §19, §22 |
M_30 | Encrypt Network Traffic [92] | Strong cryptographic techniques and protocols must be used to prevent eavesdropping on network communications. A list of approved cryptographic devices is available on the website The National Cyber and Information Security Agency (NÚKIB) based on the recommendations of The National Institute of Standards and Technology (NIST) technical laboratory in the field of cryptography. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | SC-8 | SR 4.1 | CR 4.1 | A.10.1, A.13.1 | §18, §26 |
M_31 | Encrypt Sensitive Information [93] | This involves ensuring the implementation of strong encryption to protect stored data. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | SC-28 | SR 4.1 | CR 4.1 | A.10.1 | §18 |
M_32 | Filter Network Traffic [94] | In ICS networks it is necessary to implement filtering of incoming and outgoing traffic based on the implementation rules for filtering. It is necessary to define the allowed traffic using whitelists, both at packet, state and application firewall level. It is also generally recommended to also deploy deep packet inspection, specific firewalls for SCADA automation/protocol. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | AC-3; SC-7 | SR 5.1 | CR 5.1 | A.13.1 | §18 |
M_33 | Human User Authentication [95] | Access to system and technical resources of ICS systems must be controlled at the level of user authentication and authorization. It is often problematic or technically impossible to deploy multi-factor authentication within ICS systems. Therefore, it is necessary to strengthen the perimeter of protection accordingly, e.g., to implement multi-factor authentication at the physical entrance to ICS resources, to implement account management and account permissions, to increase the frequency of technical and process audits, etc. Mitigation is the responsibility of the vendor and the configuration engineer in necessary coordination with the system architect. Mitigation is related to the operational environment and is entirely the responsibility of the customer. It mainly covers access to HW platforms. | IA-2 | SR 1.1 | CR 1.1 | A.9.1, A.9.2, A.9.3, A.9.4 | §12, §19, §25, §26 |
M_34 | Limit Access to Resource Over Network [96] | Mitigation is based on restricting access to shared system and technical resources. In order to exploit remote accesses, secure protocols, appropriate cryptographic protection, and a tightened lottery of these activities must be uniquely described, implemented, and enforced. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | AC-3; SC-7 | SR 5.1 | CR 5.1 | A.13.1 | §18, §20 |
M_35 | Minimize Wireless Signal Propagation [97] | By its physical nature, a wireless signal propagates outside the boundaries of an organization, providing attackers with the ability to monitor traffic on that network and attempt to gain unauthorized access to it. When it is necessary to use a Wi-Fi network in the environment of transformation stations (it is generally not recommended or prohibited), it is essential that appropriate measures are put in place to detect and limit unnecessary Wi-Fi propagation. At the same time, this must be considered in the actual design of the network and wireless technologies must not be used for the transmission of control and monitoring data. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | SC-40 | SR 1.6 | CR 1.6 | A.13.1 | §18 |
M_36 | Mitigation Limited or Not Effective [98] | This service is based on the principle of abusing the given systems functions. Mitigation is possible by preventive checks and maintenance of the systems. The solution is linked to the implementation of measures M_20, M_26 and M_50. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | N/A | N/A | N/A | A.14.1 | §13 |
M_37 | Multi-factor Authentication [99] | The service uses two or more factors to authenticate for system access. For example, a username and password supplemented by a token from a physical smart card or token generator. In industrial control systems, assets such as IDEs, workstations, and HMIs have high requirements for operational control and real-time security that can limit the use of multi-factor control. Deployment is affected by the age of the system. Mitigation is the responsibility of the supplier and the configuration engineer. The design must come from the system architect. Mitigation covers not only access in HW but especially to SW platforms. | IA-2 | SR 1.7 | CR 1.7 | A.6.2, A.9.4 | §10, §19, §25, §26 |
M_38 | Network Intrusion Prevention [100] | It is recommended to use signatures to detect network traffic intrusions and block unauthorized traffic at the network boundaries. In industrial control systems, network intrusion prevention should be configured so that it does not interfere with protocols and communications responsible for real-time control or security-related functions. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | SI-4 | SR 6.2 | CR 6.2 | A.13.1 | §18 |
M_39 | Operational Information Confidentiality [101] | Implements/introduces a mechanism to protect the confidentiality of information related to operational processes, facility locations, facility configurations, programs, or databases that may contain information usable to derive organizational trade secrets, processes, and other intellectual property. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | N/A | SR 4.1 | CR 4.1 | A.6.1 | §11, §13 |
M_40 | Password Policies [102] | It is necessary to describe and implement password security rules with an emphasis on enforcing secure password policies according to user persistence. This also applies to system process accounts. Mitigation is the responsibility of the supplier and the configuration engineer. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | IA-5 | SR 1.5 | CR 1.5 | A.9.1, A.9.2, A.9.3, A.9.4 | §12, §19 |
M_41 | Redundancy of Service [103] | The design and implementation of the logical and physical topology of the network within the electrical substations must consider the availability requirements of the services provided and thus ideally be fully redundant, Minimal redundancy is required for critical services of the entire system. Mitigation is the responsibility of the vendor and the configuration engineer in necessary coordination with the system architect. Mitigation covers access to HW, especially SW platforms., including links to the continuity and recovery lanes. | CP-9 | N/A | N/A | A.12.1, A.12.2, A.12.3, A.12.4 | §10, §11, §13, §27, §28 |
M_42 | Restrict Library Loading [104] | The mitigation measure is aimed at ensuring the integrity of the libraries used within the operating system and unified applications. For these parts, an appropriate level of integrity must be ensured. This can be effectively achieved by using verified resources and libraries. Thus, in an ICS environment, even generally reliable sources such as GitHub cannot be used without prior vetting and assurance of integrity. Mitigation is the responsibility of the supplier and the configuration engineer. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | CP-7 | SR 7.7 | A.12.1, A.12.2, A.12.3, A.12.4 | §10, §11, §13, §25 | |
M_43 | Safety Instrumented Systems [105] | Utilize Safety Instrumented Systems (SIS) as an additional layer of protection for safety scenarios that may cause property damage. An SIS typically includes sensors, logic controllers, and a final control element that can be used to automatically respond to an unsafe condition. It is necessary to ensure that all SIS are segmented from the operational networks. Mitigation is the responsibility of the supplier and the configuration engineer. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | N/A | N/A | N/A | A.13.1 | §18 |
M_44 | Software Configuration [106] | Implements documented procedures for software (non-operating system) configuration changes to mitigate security risks associated with software operation. Mitigation is the responsibility of the supplier and the configuration engineer. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | CM-7 | SR 7.7 | CR 7.7 | A.12.1, A.12.2, A.12.3, A.12.4 | §10, §11, §13, §22, §28 |
M_45 | Software Process and Device Authentication [107] | Devices that connect remotely to other systems should require strong authentication to prevent unauthorized communication. Among other things, software processes should also require authentication when accessing APIs. If necessary, authentication of devices and software processes in the ICS environment should be required. Mitigation is the responsibility of the supplier and the configuration engineer. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | IA-9 | SR 1.2 | CR 1.2 | A.12.1, A.12.2, A.12.3, A.12.4 | §10, §11, §13, §19, §18, §25, §28 |
M_46 | SSL/TLS Inspection [108] | In the three cases where it is necessary for electrical substation systems to communicate to an Internet-type network, it is imperative that they have implemented TLS (or its predecessor SSL) for the purpose of encrypted communication and thus ensuring its confidentiality. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | N/A | N/A | N/A | A.13.1 | §18 |
M_47 | Static Network Configuration [109] | For security reasons, it is recommended to use static network configurations. Protocols that require dynamic discovery/addressing (e.g., ARP, DHCP, DNS) can be used to manipulate network message passing and enable various MitM attacks. This measure may not always be applicable due to device limitations or problems posed by different network configurations. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | CM-7 | SR 7.7 | CR 7.7 | A.13.1 | §18 |
M_48 | Supply Chain Management [110] | This is purely an organizational measure that is recommended to be implemented as part of a supply chain management program, including policies and procedures to ensure that all equipment and components are sourced from trusted suppliers and tested to verify their integrity. The design must come from the system architect. Mitigation mainly covers protection to SW platforms and data. | SA-12 | N/A | N/A | A.14.1 | §8 |
M_49 | Threat Intelligence Program [111] | It is a software implementation to support threat intelligence, helping an organization generate its own threat intelligence and monitor trends to inform defense mitigation priorities. Integral to the implementation of this measure is the implementation of a configuration database as the primary source of information about the system and its configuration. Mitigation is intended for the customer side and its security and IT department. Mitigation covers not only access in HW but especially to SW platforms including links to the continuity and recovery lanes. | N/A | N/A | N/A | A.12.6 | §10, §13, §28 |
M_50 | Update Software [112] | It introduces a requirement for regular software updates to reduce the risk of software misuse, including the development of an update schedule and the introduction of a system for testing and documenting updates. Software updates may need to be scheduled during operational downtime. Mitigation is intended for the customer side and its security and IT department. Mitigation mainly covers protection to SW platforms and data. | N/A | N/A | N/A | A.12.1 | §10 |
M_51 | User Account Management [113] | It is the implementation of a central system for documented management, creation, modification, use and permission control of user accounts. Mitigation is the responsibility of the supplier and the configuration engineer. The design must come from the system architect. Mitigation covers access to HW, especially SW platforms. | AC-2 | SR 1.3 | CR 1.3 | A.9.2 | §12, §19 |
M_52 | User Training [114] | Continuously educate users on cyber security, to increase user information literacy in order to prevent potential cyberattacks and manipulation by an attacker, in order to reduce the risk of successful spear phishing, social engineering and other techniques that involve user interaction. Mitigation intended for the customer side and its security department. It concerns both HW and SW usage. | AT-2 | N/A | N/A | A.6.1 | §11, §13 |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Horalek, J.; Sobeslav, V. Security Baseline for Substation Automation Systems. Sensors 2023, 23, 7125. https://doi.org/10.3390/s23167125
Horalek J, Sobeslav V. Security Baseline for Substation Automation Systems. Sensors. 2023; 23(16):7125. https://doi.org/10.3390/s23167125
Chicago/Turabian StyleHoralek, Josef, and Vladimir Sobeslav. 2023. "Security Baseline for Substation Automation Systems" Sensors 23, no. 16: 7125. https://doi.org/10.3390/s23167125
APA StyleHoralek, J., & Sobeslav, V. (2023). Security Baseline for Substation Automation Systems. Sensors, 23(16), 7125. https://doi.org/10.3390/s23167125