Расширенный поиск

 

Introduction

Recent examples of vulnerabilities make evidence that security model of 10 to 15 years ago is no longer adequate to meet contemporary challenges derived from the universal use of Internet in every ICT system. The older model is out-moded and does not scale in the face of today’s threats to ICT systems. Perimeter-based security has evolved to a highly distributed model as employees, partners and customers conduct business remotely across the Internet. The security industry has responded with new and enhanced products to meet each new threat appearing on the scenario.

All of these tools add some temporary value to overall enterprise security, but they are, in effect, only case by case security solutions facing the single threats. They are not derived from a risk-based, enterprise-wide security program, and the overall effort tends to be fragmented. In many cases, organizations must deal with incomplete data because a given security tool may not recognize a threat or risk for what it is without correlation from other data sources.

Diverse security technologies have been developed in response to the evolving threat landscape, what is missing is a methodology that supports the analysis of the security context and only consequently the design of the appropriate solution. An activity that appears innocuous to one part of an infrastructure may be revealed as a threat when it is correlated with the all rest of the infrastructure.

1. Security by Design

As defined by the US Department of State [1]: “Security-by-Design” is a concept that incorporates security in all phases and aspects of facility design, construction, and operations. Security is viewed from a life cycle management perspective, ensuring that the facility is designed, constructed and maintained in a manner to ensure efficient and effective security operations. Early in the facility design phase, the design is tested against a spectrum of threats through vulnerability assessment and the use of modeling and simulations tools. The design is modified in response to any issues identified and the subsequent changes to the design are evaluated in the same manner, along the life span of the system.

According to SANDIA National Laboratories, the overarching objective of Security-by-Design is to allow mission achievement while security exceeds threat capability [2]. So, security analysis has to be done early in the system design phase, and it has to ensure the appropriate security level during the entire mission achievement, i.e. for the whole system lifetime. The security of the Critical Infrastructure (CI) and that of the ICT system are not mechanically composable. An ICT system can be considered fully secure when stand-alone and where all components and their supply chain meet stringent requirements, while presenting vulnerabilities when integrated in a real operational environment (integration with other components of the overall sociotechnical systems, i.e., other ICT systems and networks, human operators, procedures and work practices).

When dealing with Critical Infrastructures protection, it is not possible to ensure ICT systems security without taking in detailed account their operational environment, from a technical, architectural and operational perspective. This is also due to the fact that, although Critical Infrastructures control and managing systems are actually ICT systems (they include telecommunications, computers, enterprise software, middleware, storage, display systems, etc.), they have in addition precise real-time and continuity constraints that prevent the use of many of the common ICT countermeasures (e.g. the use of firewall and antivirus, as well as of software update).

While the protection of Critical Infrastructures started dominantly by utilities, the methods for developing secure by design paradigms is still less elaborated. To be effective it has to address the complex interdependencies and interactions originating in a mix of physical and ICT infrastructures, together with operational procedures and human operators. All together they form a system subject of high-level of security requirements. The evolution and changes in the requirements, workloads and other environmental factors necessitate a complex closed loop assessment of the designs and their operation.

Moreover, changing key performance indicators like a differently weighted risk, security, throughput, etc., under different conditions necessitate at least a set of pre-validated operation scenarios. Such a multi-aspect analysis for existing infrastructures is a core element for the efficient
functioning of infrastructures.

The same CI can be observed from different viewpoints [3]. These viewpoints can be considered as “Dimensions” in a 3D space: the Component Dimension, the Countermeasure Dimension, and the Risk Dimension (Figure 1).

figure1

Figure 1. Three different viewpoints of the CI

Each point of the space in Figure 1 represents a countermeasure applied to a system component in order to thwart a specific risk. The Component Dimension entails the decomposition of the CI in subelements, which can be either physical or logical. It is therefore possible to define CI Physical and Logical Architectures.

1. System Engineering Approach

Most important activities to implement the concept of Security — by — Design are represented in Figure 2.

1.1. System Analysis
Consists of the following steps:

figure2

Figure 2. System Engineering Approach

• The identification of the functionalities implemented by the Critical Infrastructure.
• The identification of the role played by the cyber and physical components (databases, data communication links, process units, etc.) in the implementation of those features.
• The analysis of internal and external interfaces that connect the CI components among them and with the outside world.

The analysis framework has to manage the entire closed loop model composed of both the physical and the ICT infrastructure system models. The Systems Engineering Methodology as defined by INCOSE is a valuable tool to conduct System Analysis [4].

1.2. Risk Analysis
Consists of the following steps:
• The identification of the potential threats that may affect the Critical Infrastructure.
• The analysis of the system/components vulnerabilities that can be exploited by identified threats in order to cause damages to the Critical Infrastructure.
• Definition of the method to evaluate security risks given the architecture and the threats, and implementation via software tools of algorithms.

The outputs of this phase are those typical of any risk analysis [5]:
Vulnerability, Damage (Component or Functionality integrity loss due to the occurrence of a Cause), Cause (i.e. the damaging event), Consequence (i.e. the damaging effect), Threat, and Impact.

1.3. Security Analysis
Consists of the following steps:
• Modeling of a set of protection goals which can be translated in formal semantics with clear dependencies and derivations among protection goals. Similarly, a set of controls and countermeasures is to be defined, which are to be employed in support of the protection goals relevant for a given scenario or configuration and where reasoning may be partly automated to determine necessary and sufficient conditions.
These protection goals and mechanisms for security and — as they are intended to be reconfigurable also in the presence of attacks or other degradation — also serve the resilience of the ICT systems against yetunknown types of attacks, including partially successful ones.

• Definition and implementation via software tools of algorithms supporting the validation of the proposed countermeasures at the design stage. It is worth noting that this security analysis consists of an initial design stage in which the overall objectives (protection goals) are specified, which must also be matched against operational requirements, but that the strengths of mechanism or actual implementation of protective and mitigating operations should be determined dynamically.
This is to ensure that in the inevitable event of configuration changes or as a result from attacks, protection goals can still be satisfied, or where it is not possible to satisfy all or the same level, to have appropriate
prioritisation in place.

1.4. Implementation of countermeasures
Consists of the following main tasks:
• Selected standards — Identify standards required to meet design requirements constraints derived from the previous activities.
• Identify system components — Clearly identify system elements under design control of the project team and/or organization and expected interactions with systems external to that control boundary.
• External interfaces — Functional and design interfaces to interacting systems, and/or humans external to the system under development.
• System Functions — Define the functions that the System is to perform. These functions should be kept implementation independent.
• Utilization environment(s) — Identify all environmental factors (natural or induced) that may affect System performance, impact human comfort or safety, or cause human error for each of the operational scenarios envisioned for System use.
• Life-cycle process requirements — Conditions or design factors that facilitate and foster efficient and cost-effective life-cycle functions (e.g., Production, Deployment, Transition, Operation, Maintenance, Reengineering/Upgrade, and Disposal).
• Design considerations — Including human systems integration, system security requirements, and potential environmental impact.
• Design constraints — Including physical limitations, manpower, personnel, and other resource constraints on operation of the System, and interacting systems external to the system boundary.

1.5. Technology Selection
NIST special publication 800-36 “Guide to Selecting Information technology Security Products” [6] covers the selection of IT security products to be used as operational or technical security controls. The guideline address questions like:
• Have security requirements been identified and compared against product specifications?
• Is the security product consistent with physical security and other policy requirements?
• Have known product vulnerabilities been addressed by reviewing the relevant vulnerabilities of a product?
• Has the vendor’s policy or stance on re-validation of products when new releases of the product are issued been considered?
• What is the vendor’s “track-record” in responding to security flaws in its products?

2. Toward a cyber security culture

Security culture involves perception, culture background, latent knowledge and experience beyond the scientific and technological assets. In general, security culture is a branch of security organization. Indeed, one of the key element is linked with trust and reliability of the organization underpinning the security measures. Security culture is the final step of a chain involving (in order) “responsive culture, preventive culture, management culture, and security culture itself”.

Therefore, training education in personal ethic for the next generation ICT specialist could be the only effective measure.

3. Conclusions

As complex infrastructures move across locations, networks and devices, there is an increasing need to protect sensitive information and critical assets without having to compromise workforce mobility, or productivity. Given the speed and sophistication of today’s security attacks and the severe consequences of a security breach, addressing these challenges is an increasingly complex task for organizations of all sizes. It is now clear that past security models are no longer adequate to meet contemporary challenges derived from the universal use of Internet in every complex infrastructure. Security solutions give the way to meet key assets and functions protection by ensuring the right level of protection for every individual situation and subsystems.

 

[1] http://www.state.gov/t/isn/rls/fs/186672.htm
[2] SANDIA REPORT, Security-by-Design Handbook, SAND2013-0038, January 2013, Albuquerque (US). http://prod.sandia.gov/techlib/access-control.cgi/2013/130038.pdf
[3] AIIC Piano di Sicurerzza dell’Operatore: Proposta di line guida operative (in Italian) http://www.infrastrutturecritiche.it/aiic/index.php?option=com_docman&task=doc_details&gid=481&Itemid=103
[4] INCOSE Systems Engineering Handbook v. 3.2.2, INCOSE-TP-2003-002-03.2.2, October 2011
[5] For instance: Kjølle, G.H. et al. 2012. “Risk analysis of critical infrastructures emphasizing electricity supply and interdependencies.” Reliability Engineering and System Safety (2012)
[6] http://csrc.nist.gov/publications/nistpubs/800-36/NIST-SP800-36.pdf

Sandro Bologna, Maurizio Martellini
Insubria Center on International Security (Italy)
Claudio Calisti
ASTER-TE

This speech was delivered at the 11th Scientific conference of the International Research Consortium on Information Security, as part of the International Forum on «Partnership of state authorities, civil society and business community in ensuring international information security», held on 20-23 April 2015 in Garmisch-Partenkirchen, Germany. It is published on Digital.Report with an explicit permission from the conference organizers.

Об авторе

Sandro Bologna

Итальянская ассоциация экспертов по критически важной инфраструктуре.

Написать ответ

Share this
Перейти к верхней панели