There are numerous methods available for the analysis of risks and critical issues of the IT platforms dedicated to administrative procedures, where data, more or less privacy sensitive, are mostly introduced by humans, using a wide range of desk and mobile devices. An extensive list is available on the website of ENISA, the European Union agency that deals with network security. Such data are, in effect, the goal of the bad guys: their acquisition, their alteration and manipulation. Data are, therefore, the good to be evaluated and protected.
In the world of Internet of Things, digital or technological platforms (automobile, energy, water, domotics ...) things are different. The data are always present, but rather than being generated by human beings are mostly generated by sensors, processed by small computing units often equipped with proprietary operating systems or little known, with scarce documentation available to public, that send the results of the calculation to actuators rather than monitors or printers . It is the functionality and integrity of the platform devices that must be safeguarded. Access to data and their possible manipulation is only a first step in order to reach the ultimate goal that is the interruption of the service or damage to part or the whole of the attacked platform.
IPSEM is a specific methodology for the analysis and management of the risks of a technological or industrial platform, made up of a series of components with a variable criticity from zero to high. These components are interconnected to form the platform in question that can be, not necessarily, connected to the Internet. The methodology is described in a document that can be requested via contact information on top.
The IPSEM methodology was recently (2018) proposed by Giulio Carducci who has been dealing with risk analysis and risk management methods for over twenty years. The work of Giulio is, at the beginning of this century, the design of MIGRA, a methodology listed in the repertoire of ENISA and used in management and administration. IPSEM and its application are now being examined and applied, with the collaboration of SCS s.r.l., by a work group in the field of energy distribution.
The IPSEM project is open to the examination', criticism and improvement by professionals, academic areas and organizations interested in the security of digital systems. Those interested in furthering the topic and contributing to the project can get in touch with Giulio using the form on the side or the mobile 3188.8.131.529. In particular, IPSEM requires to be instantiated in a software application whose implementation is economically demanding and requires adequate funds. A company wishing to take charge of this development would find maximum collaboration and readiness for a fair deal. It is our convincement that the product created would fill an important gap in a rapidly developing sector.
Summary of functionalities
The entire cycle of application of the methodology is divided into a series of phases which are briefly described below. For each phase the specific functionalities and the resources involved are described.
Phase 1. Creation of the intervention perimeter with components and related vulnerabilities.
In this first phase the perimeter of intervention is described by instantiating the specific components taking them from the components data-base specific to the type of platform (for example "Energy Distribution"). The description of the entire perimeter can be divided into sub-parameters. The components inherit the vulnerabilities described for each component in the component data-base. The result of this phase is a description of the perimeter divided into sub-perimeters and components connected to each other and accompanied by the respective vulnerabilities (Deliverable layer). The possible connections between the various components are themselves components, belonging to a specific category.
Phase 2. Assigning of criticity to components.
In this second phase the attribution of the criticality to each component occurs. The specific logic module 2 uses the classification parameters database applying the parameter set specific to the category to which the component in question belongs. This phase updates the scenario file with the assignment to each component of a criticality index. For a discussion and analysis of critical issues (with respect to risk) and criticality parameters, see the illustrative document of the methodology. The classification in terms of critical components allows to identify the components for which the assignment of countermeasures (next step) is more urgent.
Phase 3. Assigning countermeasures to components.
In this phase, the analyst, using the appropriate logic functional module 3, is able to select the components with the highest criticality index and to associate the countermeasures taken from the specific database with each of them. The perimeter file is then enriched with countermeasures relevant to each critical component. The gradual evolution of the perimeter file during the application of the various phases has a gradual confirmation in the updating of the graphic representation (Reference scenario) with appropriate reference links.
Phase 4. Countermeasures planning and management.
The countermeasures adopted must be planned and checked for implementation over time. The reference perimeter may vary in time in terms of components and their relationships and therefore duly updated. This is what this fourth and final phase provides.
Questions, interest to the project and other may be issued calling 39-3184.108.40.2069.