- Recently, due to the increasing complexity and wider adoption of heterogeneous systems, the management of security properties, vulnerabilities and risks of systems by integrating and structuring existing components, is becoming more and more crucial. A particular aspect to be considered is the Risk Analysis and, specifically, the analysis of the Systemic Risk. This risk derives from the interdependence of the system under consideration, from services provided by other systems and, in general, from the interactions among them. In fact, it may happen that an adverse event, which occurs at a certain system that is not properly controlled, can cause dangerous effects that, through its propagation to other interconnected systems, would/could compromise their operation. Thus, suitable engineering approaches need to be exploited to prevent and manage the risks arising from the integration of system components so as to increase the security of systems, data and even human life. In this context, the paper proposes specific extensions of a Goal Oriented methodology for Requirement Modeling, called GOReM, through the RAMSoS method, natively conceived for supporting dependability analysis. Such combination enables the modeling and the evaluation of the Systemic Risk centered on agent-based simulation techniques. The combination of RAMSoS and GOReM is experimented on a case study concerning an online payment service, by evaluating the impact of the failure of a single component on the overall system.
Copyright © held by the authors.
Keywords— Cybersecurity, Modeling and Simulation, Requirement Engineering, Systemic Risk Analysis.
In recent years, the global crisis has shown that the
benefits of globalization are increasingly accompanied by a
growing interdependence and interconnection of systems and
services, bringing out new vulnerabilities coming from
unexpected directions. Global risk can cause a significant
negative impact on a number of countries and companies,
showing a systemic nature [
In this context, the paper aims at investigating in such
direction by exploiting engineering tools for representing
relationships among systems/services and observing their
behavior. Specifically, the adoption of the Systems
Engineering approach combined with Modeling and
Simulation techniques are used to catch how and which
entities of the overall system influence the operation of the
entire system and, as a consequence, the evaluation of the
Systemic Risk. In particular, the combination of a Goal
Oriented methodology for Requirement Modeling, called
GOReM [
The rest of the paper is structured as follows: Section II presents the related work and highlights the main research challenges related to the systemic risk in the cyber-security domain; the combination of the GOReM and RAMSoS methods are presented in Section III. A case study concerning an online payment service is described in Section IV, whereas the simulation-based evaluation is presented in Section V. Finally conclusions are drawn in Section VI.
As mentioned above the Systemic Risk is intended as a
risk deriving from the interdependence between the main
system, object of the analysis, and the services provided by
other systems and, in general, by the interactions between
them. It is possible to define the systemic risk as “any set of
circumstances that threatens the stability of or the public trust
in the system” [
Companies inadvertently expose themselves to risks
outside of their structure, by outsourcing, interconnecting or
divulging their data to an increasingly complex and
inscrutable networks’ system. Some risk factors have been
identified and published on the “Zurich Cyber Risk Report”,
and, in particular, seven IT risks have been identified that
could threaten a systemic shock: internal corporate network,
outward counterparts and affiliates, supply chain and
outsourcing contracts, disruptive technologies (IoT in the first
place), critical infrastructure and external shocks [
These seven risks can be grouped in three areas “Near,
Everywhere and Distant”. The “near” area is related to the
usage of contracts, SLAs, internal corporate controls and
resiliency within a company. The “everywhere” area includes
all those companies that may have contractual relationships
with other companies around the world, so the risks are not
generally controlled by individual contracts, but by companies
and governments through standards, regulations, global and
national governance. The “distant” area is then related to all
those external risks to which individuals or group of
companies may not have any influence. Risk control coming
from external shocks is almost entirely in charge of
governments, intergovernmental organizations and
transnational organizations [
Systemic risk in the financial sector can be thought as the probability that a failure of a significant portion of the financial sector can occur, which can lead to a reduction in credit availability. The materialization of such event is likely to generate negative effects on the real economy. Systemic risk in the financial sector is essentially related to the risk of infection among financial institutions, which could generate a potential destabilization of the entire financial system. Some negative externalities, or inappropriate behaviors, generating damaging effects on the financial market status, have great impact on the increasing of the systemic risk. Several preventing approaches have been proposed: making use of suitable financial stability or strength indicators; measuring the existing correlations between financial institutions; usage of legislative bodies aiming at regulating the activities of the actors in the financial sector to minimize such kind of risks.
Four main reasons determining negative effects on a system have been identified (the focus is on negative externalities, i.e. economic and financial behaviors which affect the overall market trend, and influencing systemic risk growth):
having influence on financial topics leading to considerable mismatches on assets and liabilities maturities. A striking example of the materialization of such event is the failure of Lehman Brothers, which led, from one side, Merrill Lynch to merge with Bank of America, and, on the other side, Goldman Sachs and Morgan Stanley to become ordinary banks, causing in this way the collapse of US real estate stocks. The involvement of important institutions in the crisis is relevant for the propagation of negative information.
creditworthiness of the debtor. The failed credit bank customers will have greater difficulty in obtaining a credit to new banks. This is because new banks can apply more restrictive policies for granting credit to new customers since there is scarce information about them.
Debt-Credit relations between banks. Credit institutions and financial intermediaries are inclined to work more closely among themselves at commercial level. The risk of a crisis spreading in the whole financial system can be increased by the interactions between banks and intermediaries, which can be related not only to the interbank market, but also to a large sector of derivatives markets, included CDS (Credit Default Swap), guarantees, brokerage services, etc.
Liquidity spiral. This negative externality occurs when financial market operators, instead of selling financial assets for gaining liquidity, use different strategies to restrict the new credit extension, that means, for example, making a credit rationing having high-margin/cuts, or increasing the interest rate for the grant allocation. These activities can reduce prices and outputs and, can increase the possibility of failure in accessing the loan. This kind of problem is caused by an extreme exposure to risk of the liquidity shortage by financial institutions, which make use of high debt strategies.
In the end, the negative propagation effects can be greater when the failure is related to large institutions having different interconnections and in the presence of a not transparent market structure (OTC markets, not characterized by the typical requirements for regulated markets). Government institutions implicitly support and foster financial institutions to increase their size and interconnections, so that they can increase the possibility of being saved in time of crisis, since they are “too big to fail”.
Microsoft has proposed the creation of a G20+20 Cyber Stability Board, that means, 20 governments and 20 companies, operating in the information and communication technology, which should work in synergy to draw up a set of basic principles ensuring, from one side, an 'acceptable behavior' in cyberspace and, on the other side, some “guidelines” to improve IT risk management.
The following recommendations about potential systemic risk impact in IT, can be useful for both large and small organizations to survive to a potential cyber shock, and can be considered as a kind of “shock absorber” that can potentially reduce the magnitude of the shock: (i) improving the resilience and incident response at system level; (ii) expanding security concepts aim at involving third-party suppliers as much as possible; (iii) providing targeted subsidies; (iv) considering other measures, such as “Stability Board” and the “G-SIFIs” requirements.
For small business enterprises there are three categories of recommendations: Basic, Advanced and Resilience.
Basic. The main 5 crucial recommendations of the 20 Critical Security Controls SANS, are taken in consideration: (1) Whitelist application - organizations should enable computers to perform only a limited set of pre-approved programs; (2) Standard system configurations usage computers with a few standard configurations are less expensive and easier to defend; (3) Patch application software and (4) System software within 48 hours - large companies should check software on a regular basis looking for any bugs in order to drastically reduce the opportunities of vulnerabilities exploitation by hackers;(5) Reduction of the number of users having administrative privileges.
Advanced. Broadening risk horizon - taking in consideration counterparts, contracts and outsourcing agreements, and critical infrastructure, each part should be at least partially controlled by contracts, agreements on service levels, in-depth site visits and audits; Cyber Insurance usage to transfer IT risks, particularly risks associated with thirdparty data breaches or business interruption; Requiring standard and more resilient and safe products to key suppliers; Acquiring at management level a broader view on IT risks.
Resilience (the ability of large companies to recover from interruptions in the shortest time as possible): Redundancy redundant power and telecommunications suppliers, ISP alternately connected to the peering point, work-around with little dependence on IT in order to provide some alternative solutions when Internet access is off; well defined Response to incidents and business continuity planning - standard operating procedures, clear objectives based on metrics, quantification of the needed time to detect an accident or an intrusion in the system; Simulating scenarios and security training - analyzing the most likely and the most dangerous cyber risks and test their Security Response Team, together with the company management in order to build a historical memory for incident response.
III. COMBINING GOREM AND RAMSOS METHODS FOR
GOReM (Goal Oriented Requirements Methodology) is a
lean, easy to master methodology for capturing and
maintaining up-to-date requirements of large systems
operating in complex application domains. GOReM first
definition [
GOReM consists of three main phases, each of which is devoted to modeling specific aspects of a requirement engineering process: Context Modeling, Scenario Modeling, Application Modeling; specifically: in the Context Modeling phase, the stakeholders are identified along with their objectives as well as the dependencies among softgoals; moreover, the rules and regulations that govern the business context under analysis are identified and documented. in the Scenario Modeling phase, different business scenarios are derived from the Context model, in terms of roles that are played by the stakeholders involved in the modeled scenario, their specific goals and their dependencies, and the rules and regulations that govern each elicited business scenario. Furthermore specific analyses that show the strengths, weaknesses, opportunities and threats are also performed to guide and support strategic decisions at business level related to the future work. in the Application Modeling phase, one or more application scenarios are introduced in order to specify main functionalities which should be provided by a single business scenario resulting from the previous phase.
Multiple scenarios are concurrently set down. A sketch of the reference process for the GOReM method along with its main work-products is shown in Figure 1.
The lessons learned from the experience derived by
exploiting the GOReM method on important research projects
by cooperating with industrial partners such as ACI
Informatica [
Lesson 1: human interactions and cooperation. It is probably the most difficult task due to different skills, backgrounds and knowledge which lead to big misunderstandings, lethal for establishing system requirements. It is likely to encounter mistakes when a new application domain is being explored because of: (i) misleading interpretation, due to the coexistence of different interpretations of stakeholder goals and requirements, that usually happens when people have different skills and the same concepts are interpreted differently according to the stakeholder’s background; (ii) conflicting specifications, when specific strategies, that could potentially create strong disadvantages in other application scenarios are adopted in order to reach a specific goals in a specific application context; (iii) late discovery of redundancy, when in advanced development project stages the same concept is described and represented differently several time or different terminologies is used for describing the same concepts (iv) fragmentation of efforts; (v) weak focus on objectives for achieving the desired goals and being competitive and effective; (vi) partner coordination, when there exist different partners having different objectives to reach; (vii) work-product integration, when there is a need to integrate, harmonize and handle deliverables, services and products coming from different tasks.
Lesson 2: cross-domain aspects. There are some recurrent features that might be identified once for all as well as common characteristics for each domain of interest that have to be considered and properly represented, which in turn arise questions that need to be answered, such as: space: Is the considered context model influenced by the location and the territorial extension (e.g. regional, national, international, members states)? time: Is the considered context model influenced by temporal aspects (e.g. a new law replaces partially or totally a previous one )? context history: does the current context state depend on a previous ones?
Lesson 3: legal aspects. The specific context model and the different business scenarios are handled by several Rules and Regulations that might be in conflict. As a consequence, it is important for modeling a context and any specific business scenario, to understand which laws are involved, which is a policy as a “standard” or a best practice as a “guideline” that can be adopted or not, depending on the stakeholders needs. In addition, there are stakeholders of specific customers that can have a set of internal policies which, in turn, should be considered and their eventual contrast with some laws or requested best practices should be discovered and resolved. Finally, as a desired service can be used in different Nations, the requirement model has to analyze and manage the legal usability of a service for a given customer. Furthermore, requirements engineering processes should manage legal aspects by continually monitoring their changes over the time, during the overall system lifecycle.
Lesson 4: tracing evolution. Business context, scenarios and applications can evolve because of their dynamic nature. It is important to have some tracing mechanism that allows knowing which application model version from which scenarios model version has been derived and this last one to which business context model version refers to. For big and continuously evolving system engineering process, this is of fundamental importance and especially for maintaining control and governing the system evolution along its life.
Lesson 5: inter-scenarios dependencies and reuse. Quite often, business scenarios evolve with a specific team of analyst/designer (sub)domain experts that have the objective to go ahead following their requirements engineering for specific final services. This can lead to duplication of work and, worse, to services which do the same thing (same requirements) but in a different way. This is often difficult to discover and create customer dissatisfactions. This happen, for example, when the same stakeholder has two different goals which belong to two different scenarios, but the two application models reaching the two goals, share many “what to do” but unawares.
In the light of the above reported lessons learned during
the method exploitation, starting from Lesson n.1, an updated
and refined version of the GOReM method in [
The Context Modeling phase aims at clearly representing the reference business domain for the project under consideration. The work-products of this phase are: a Stakeholder Diagram, which shows a (hierarchical) specification of all the involved stakeholders, each of which is in turn characterized by a set of Softgoals they intend to pursue; a Softgoal Dependency Diagram, which shows the relationships among Softgoals, (i.e., contribute, hinder, include, extend, generalize); a Rules and Regulations report shortly describing the rules and regulations governing the Context, distinguishing between Laws, which can be National or International, and known used Policies and Best practices.
Whereas there are some features that need to be identified and analyzed according to the specific scenario, such as: subject: who/what is the subject of the described context? user profile: are the user preferences/personal features represented in the context model? Does the system describe the user’s characteristics one by one or does it provide a role-based model of user classes?
Table I shows symbols already used in the first version of the methodology, while table II shows the identified and considered types of rules and regulations.
The Scenario Modeling phase specializes the Context Model through the identification of evolutionary scenarios that have to be modelled within the context of interest. Such scenarios are identified through an analysis that takes into account the roles played by stakeholders in each scenario, by indicating the specific Goals related to some Softgoals in the context model and the Rules and Regulations that govern the scenario. Table III shows symbols used for roles and for the associations with the stakeholders.
The SWOT Analysis activity [
Rules and Regulations selection activity considers which rules and regulations, identified in the Context Modeling phase, must be considered in the modelled scenario, by identifying them with a structured ID, describing them, specifying if they are laws, policies and best practices, indicating the adopters, and warning possible dependencies with other considered rules. In particular, GOReM uses the matrix formats, showed in table V. This is an improvement introduced and allows to better manage the issues discussed in lesson 3 related to legal aspects.
Starting from the scenarios defined during the previous phase, in the Application Modeling phase, a set of specific business scenarios might be identified. This phase defines application scenarios that are used to specify in detail the capabilities to be provided in the specific scenarios identified in the previous phase, along with main use cases description, actors and processes. In particular, each main use case may become a service to be developed as a research prototype and/or developed and engineered as part of a more complete industrial system.
In addition, some processes can be specified using UML or
BPMN notations [
Table VI shows basic used symbols in modelling an application scenario. The Package is a Namespace of use cases, which are not in the scope of the application which is modelled, but are assumed that they exist in some different Application model, even in an Application model obtained from a different Scenario Model, while in this Application Model they have to be identified and extended through the standard “extend” UML relationship.
This is how GOReM is now responding to lesson n.2 cross-domain aspects and lesson n.5, Inter-scenarios dependencies and reuse. The corresponding work-products should be more precise and should indicate exactly to which use case of which scenario an extending use case refers to and the kind of needed extension.
Every UML based diagram can be enriched with the UML comment symbol which allows adding a description to all the GOReM diagrams. However, a textual description and complete information is located in the corresponding workproduct.
Finally, concerning lesson n.4, tracing evolution, some
shared existing policy of naming and versioning method/tool,
for every model (context, scenario, application) and each of its
work-products, must be used. In addition, some configuration
management tool should be of help in maintaining the
requirements evolution of the whole system [
RAMSoS [
System Design Systemic
Risk Evaluation Scenario Modeling
and Use Case
Modeling
A full description of RAMSoS can be found in [
In particular, some phases are complementary, some others use the output produced from a method as input for the other one. The resulting method will be exemplified through a case study in the next Section.
IV. A CASE STUDY ON AN ONLINE PAYMENT SERVICE The case study under consideration falls within the online payment services and in particular exemplifies the approach based on combination of GOReM and RAMSoS, adopted for systemic risk analysis applied to a service of Electronic Payment Online (PEO) of Poste Italiane. The main objectives of this study are: (i) The assessment of systemic risk, when there is a dysfunctional behavior in one of the service components, in terms of the propagation of a disservice among other components; (ii) impact of a service failure to the services.
The PEO service is based on two services: SMS
to be used from smartphones and tablets. SMS Notifications allows to receive SMS messages on transactions made on a bank account or by “PostePay” card; whereas Payments and Transactions allows bank transfers, payment of bills, money transfer via MoneyGram, PostePay top up, or balance check and movements. In this context, the aim of this experience is the identification and the analysis of systemic risk factors linked to the PEO service. In particular, the risk of success or failure of the PEO service relies on two complementary services: SMS Notifications and Payments and Transactions, plus the IT Internal Infrastructure. A preliminary analysis shows that the SMS Notification service is linked to the Mobile Service Provider whose goal is to notify the user of the transaction (payment, charging, etc.). Whereas the Payments and Transactions is related both to the Web Service Provider that provides access to the Intranet / Internet and the Energy Provider that supports the entire infrastructure with the electrical service. An additional risk factor is related to the underlying IT infrastructure (hardware, servers, etc.).
In this context, the following risk factors: IT Internal,
identified and described along with the related actors. In particular: (i) the IT Internal risk relies on the reliability of the
risk depends on the WebServiceProvider for supporting the monetary transactions; (iii) whereas Infrastructure Upstream risk is related to the availability of both the mobile notification service offers by the MobileServiceProvider and the electricity provided by the ElectricityProvider.
Furthermore, since the approach requires the input of information related to potential risk groups (e.g. contract type, involved partner), for each actor, the following risk groups have been identified:
StandardLevelOfService;
The output of this analysis is the risk level of the PEO service according to the different levels of risk of the other services. It is estimated in terms of success and failure, where Success = 1-Failure, therefore Success + Failure = 1. The higher the percentage / value of the Success, the lower the level of risk associated to it and as a consequence the lower the risk level of the PEOservice. Vice versa the lower the percentage of the Failure variable, the lower the level of risk associated to it, and then the lower the risk level of the PEO service. In the following, the extended version of GOReM is employed for the modeling and evaluating the system above described.
As described above, the context falls within the scope of online payment systems in which through a websites is possible to make purchases, transfers of money etc. A particular important diagram of GOReM is the Dependency diagram (Fig. 2) that at the same time allow to represents the stakeholders, the goals that they are meant to achieve and dependencies (conflicts/extensions and so on among goals).
In this phase of the method, as it is shown in Figure 3, both the roles played by the stakeholders in each specific scenario are identified, and the goals related to each identified role are highlighted. Furthermore the dependencies among the Goals are shown in Table IX.
The application model allows describing, with more details, a particular instance of the scenario under consideration. Specifically, Figure 4 represents the case of failure of a service to third parties necessary for the provision of online payment services, and the impact on the other users who use the service, possible costs (impact) for the failure to provide the service.
Once the model and relationships among actors and their goals are well described and defined, it is possible to use simulation to provide an assessment about what can happen into an application scenario according to specific inputs to the system. In the following, first a statistic based tool is exploited for a static analysis and then a more dynamic is adopted.
GeNIe (Graphical Network Interface) is a development
environment for the creation of decision models [
Starting from different contractual terms of the services described above, it is possible to obtain an assessment in terms of the level of success (and complementary to the failure level) of the PEO service, which in turn can be associated with a level of risk. From the experience of the domain experts of Poste Italiane, the following percentage range is used:
89%≥Success>70 then MediumRisk;
A first example is shown in Figure 5. By considering a combination of services based on the percentages shown in each block the probability of success is 99%, which means a LowRisk. The diagram is also enriched with to additional blocks: FinancialGain and InvestmentDecision, lead the decision maker to make decisions about the quality of the services to be subscribed. In this case, as shown by the “InvestmentDecision” and “Financial income” blocks, it is convenience to invest (with a gain of € 9850) by subscribing services with such quality parameters indicated, compared to not invest (€ 6940).
Conversely, considering a low level quality of the SMS Notification service, and by also subscribing a low level quality of the WebServiceProvider service, the level of risk spreads systematically on the Payments and Transactions services by influencing drastically the PEO service. In fact, the success rate drops to 63%, which means “HighRisk” (Fig. 6).
This second approach is centered on a reference
framework, called ReActor, an object oriented framework
based on discrete-events simulation[
ServiceModel: this model is employed for services belonging in the specific scenario to be analyzed; its aim is to provide the service associated to it; AttackModel: this model is adopted for modeling attack scenarios and related typologies of attacks respect to a specific ServiceModel; RecoveryModel: it aims to model policies and countermeasures in order to make more resilient a specific service when some anomalies occur; ObserverModel: it is employed for monitoring specific properties of interest which are strictly related to a specific service; it aims to collect information of specific properties, locally at service level or globally at scenario level.
Such models have been implemented by extending the above mentioned agent-based framework by mapping them as agents, that is, autonomous entities each of which has its own behavior. In particular, the ServiceModel is mapped as
Such agents and their behaviors are achieved by implementing and extending the basic class ActorBehavior of the Reactor framework, which in turn, has been also defined as Observable. Consequently all agents that are introduced in the system, and that extends ActorBehavior, are potentially trackable. Whereas, the ObserverModel and as a consequence the ObserverAgent, has been marked as Observer, that is with the ability to monitor other agents. Finally, the behavior of each agent is characterized by different types of Message, that can respectively transmit, receive and handle in order to enable the communication with the other agents. As an example, the diagram in Figure 8 shows the behavior of the ServiceAgent defined as a state machine.
In particular, when the simulation starts, the status of ServiceAgent becomes Working. This means that the ServiceAgent is doing its job/delivering the service correctly.When an anomaly occurs, the state Working can get two types of events: ServiceFailure and ServiceFailurePropagation. Such events change the status of ServiceAgentinto NotWorking, which, in turn, is defined in terms of two sub-states DirectFailure and IndirectFailure. In particular, when the ServiceFailure event occurs, the status NotWorking declines into the state of DirectFailure. This means that the failure of the service was due to internal factors of the service. This condition triggers the propagation of the failure by a ServiceFailurePropagation event to the services that depend from the ServiceAgent; this means that a service of the system, could receive a ServiceFailurePropagation event, which turns its status into NotWorking and specifically into the IndirectFailurestatus. This implies that its failure was due to a failure propagated by third parties on which it depends.Finally, from the NotWorking status, the ServiceAgent can receive a ServiceRepearing event that brings it into the Repearing status. This allows to recover/restore the ServiceAgent and propagate this information among the other services depending on it, so as to make them all Working again.
From the analysis conducted on this case study, it is clear how the quality of services level and the involved system infrastructure (internal or third-party), strongly influence the success or the failure for the delivery of a service. In this case the use of a low quality Notification service is a critical. As a consequence, the choice of a good MobileServiceProvider, combined to a Medium/High quality of the WebServiceProvider is essential for making the system more resilient. Indeed, (i) in the first scenario, which involves the deployment of services with a high level of reliability, or in the second scenario, which combines medium-quality services, the system operates to keep resilient in presence of permanent failures, or temporary blackout, of some involved entities; (ii) instead, the second scenario highlights the high risk due to the strong dependence on entities that provide low robust / reliable services.
Whereas from the conducted study based software agents, other useful and more dynamic information are gathered from the simulation for each service involved (see Table X); for example: if a service is available (working) or unavailable (not working), the time when the failure of a service happened (timestamps), if the cause of the failure is due to external factors, the impact (e.g. in terms of money) per unit of time (e.g. per hours). WebService
Provider Payment & Transaction
PEO WebService
Provider Payment & Transaction
PEO …
Timestamp 44 44 47 56 58 64 …
Service status
Not Working
Not Working
Not Working Working Working Working …
External causes of failure no yes yes …
Impact (€) per Hour 3 2 5 3 2 5 …
This paper presented a panorama on the concept of risk and, in particular, the systemic risk in the financial sector as well as in the cyber-security field. Furthermore, some recent research efforts about the modeling and assessment of systemic risk are also presented. In particular, an extended version of GOReM combined with the RAMSoS method has been employed.
A statistical analysis tool for the assessment of systemic risk based on a probabilistic approach, called GeNIe, has been adopted; whereas an actor-based and agent-oriented framework for the development of a simulation platform for supporting the evolutionary assessment and dynamic behavior analysis of system has been exploited.
Finally, a first experimentation of such above mentioned conceptual and technical tools has been conducted on a case study concerning the assessment and the impact of failures on an online payment service.
This work has been partially supported by the “National Operational Programme for Research and Competitiveness” 2007-2013, Technological District on Cyber Security (PON03PE 00032 2 02), funded by the Italian Ministry of Education, University and Research, and the Italian Ministry of Economic Development.