1. Short Description
SPGU (Situational Picture
Generation and Update) is a module dedicated to collecting all the events
arising from the detectors and / or correlators and is considered as a
"middleware" module to allow the network of tools to communicate with
each other.
SPGU provides the current status of a SGS (Satellite Ground Station) in terms of
Situational Picture (SP). This includes data that has been produced by
7Shield's monitoring tools, data relating to events resulting from an
identified incident or attack, and a rich set of information on the current
situation such as a list of defined and taxonomically agreed Hazards in order
to identify the alarms coming from the event and a list of areas / assets that
make up the entire critical infrastructure.
2. Main Purpose and Benefits
The SPGU
/ CPTMD module provides to represent the critical infrastructure and the events
associated with it in terms of Situational Picture. The SP is an overview of
the current status which includes information relating to the security status,
the severity level, the number of events verified, information relating to the
components in terms of assets / areas and the related risk assessment data. The
SPGU module aims to collect all the data coming from the C/P detectors and
correlators, furthermore it proposes to be a centralized unit that allows
communication between all the modules connected to it. All the information
collected is then displayed in a dashboard through a map rendering and visually
detailed in organized content structures.
3. Main Functions
The main
function of SPGU is to collect all the data coming from the tools of the 7Shield
framework and to represent this data on its relative frontend.
3.1 Situational Picture OverviewSPGU sends the Kafka broker a
Situational Picture (SP) message containing information such as a status
that provides information on whether the current situation is critical or not;
a severity level that provides information about the criticality of the
current SP, that is evaluated by considering the risk score and the resilience
value assigned to SGS assets in relation to the threats that are affecting
them; an hazard list that represent the dangers generated by some
specific events.
3.2 Event ListEach SPGU update message also
contains data relating to the list of events generated for that specific SP by
all detectors / correlators that have updated SPGU.
3.3 Asset List
SPGU also exposes an end-point of a
RESTful service secured via SSO which returns a list of all assets / areas
involved in the SGS being monitored.
3.4 Risk Assessment DataSPGU collects risk assessment data
from other tools such as CIRP / RAT, DiVA. It is also able to generate risk
assessment data autonomously by heuristically detecting whether a certain event
impacts a specific asset / area and at each update it calculates new risk
assessment data such as the Warning Level and the Priority. These data are then
provided through the same RESTful service which provides information relating
to the assets.
4. Integrations with other Tools
Below
is an architectural diagram that highlights the interactions between the SPGU
and the other components.
Interactions
with the pre-crisis layer are used to receive data relating to assets / areas
and risk assessment data.
Interactions
with Crisis/Post-Crisis are dedicated to the presentation layer (through the
CPTM dashboard) and the mitigation tool (ENGAGE).
Through
CRCL it is possible to update the severity level based on the historical
events.
In
the Post-Crisis layer it is possible to have interactions with the Knowledge
Base (KB) to receive information on the history of events and print any PDF
reports.
In
the Correlation / Detection layer it is possible to interact by receiving
messages from the relative modules at each triggering of an event.
The
only exception in this layer is CPTI which allows SPGU to update its severity
level (SP) based on the tweets found on the internet (if they are relevant to
the SGS and express attempts to attack the critical infrastructure from to
protect).
Figure 1 - SPGU Interaction Diagram
Every interaction happens through
Apache Kafka broker:
Figure 4 - SPGU – Kafka Interaction
5. Infrastructure Requirements
There are no particular
requirements only for SPGU.
A system with 8GB RAM and 100GB HDD
is definitely recommended.
The
module is dockerized and can run on any system, virtualized or not.
6. Operation Manual
6.1 Set-up
The user deploying the dockerized
module needs to set some parameters in the docker-compose.yaml.
The default SGS ID and GUID are
required using:
# Default Settings
seven-shield.modelId.sgs.map.mId:
31ca584d-870f-4077-97d6-52e21e019391
seven-shield.modelId.sgs.map.sgsId: ICECUBES (this is SpaceApps example)
Furthermore, the
settings related to the Kafka broker are important:
#Development environment
configuration
spring.kafka.consumer.bootstrap-servers:
7shield-broker-02.eng.it:9093
#spring.kafka.consumer.bootstrap-servers:
7shield-broker-01.eng.it:9093
spring.kafka.ssl.key-store-location: /usr/local/certificates/ENG.keystore.jks
spring.kafka.ssl.key-store-password: 7shield
spring.kafka.ssl.trust-store-location:
/usr/local/certificates/ENG.truststore.jks
spring.kafka.ssl.trust-store-password: 7shield
spring.kafka.consumer.group-id: sa-events-id-dc
seven-shield.consumer.prefix-id: ""
seven-shield.consumer.prefix-id.length: 5
seven-shield.current.instance.SGS: ICECUBES
All other parameters can be set but do not need to be changed in order
for SPGU to function correctly.
7. User Interface
SPGU is a back-end software; thus, no user interface is provided.