3 COMPONENT SPECIFICATION
3.6 Security and Privacy Dashboard
This section collects some scenarios for the Security Dashboard according to a FI Developer's perspective:
3.6.1.1 Scenario 1 - Accountability reporting
Section Description Use Case
id Security Dashboard - Scenario 1 Title &
Description Accountability reporting
Author THALES
Actors Federation Security Officer (defines and controls federation security policy in the XIFI Platform).
Objective The Federation Security Officer wants to be reported about on-line and/or off-line accountability incidents.
Pre-Conditions
The actor needs to be authenticated with root permissions in the XIFI platform.
Access control at each node of the federation needs to report logs (log events).
The Service-Level SIEM component included in the FI-WARE Security Monitoring GE needs to be adapted to collect the accountability logs which potentially trigger the correlation rules.
A configurable visualization and/or GUI.
Process Dialog
1. The Federation Security Officer wants to visualize and analyse the accountability events which take place in the XIFI federation. He/She configures the Security Dashboard by adding his/her own correlation rules.
2. The Agents installed in the nodes collects the accountability logs (received from Access Control systems) and send them to the Service Level SIEM component included in the FI-WARE Security Monitoring GE.
3. The events are correlated by the Service Level SIEM component included in the FI-WARE Security Monitoring GE according to correlation rules defined.
4. The accountability alarms generated by the FI-WARE Security Monitoring GE are stored in a database.
5. The Federation Security Officer can visualize detailed information in the Security Dashboard about:
Accountability Incidents at real-time.
Security reports on a weekly, monthly basis.
Variations N/A
Post-Conditions
The Federation Security Officer has identified accountability incidents and he can react in consequence to protect the XIFI federation (XIFI platform).
Diagrams Use Case Diagram
Figure 94: Use Case Diagram for Federation Security Officer Interaction Diagram
Figure 95: Interaction Diagram for Federation Security Officer
Issues &
Notes
We need to clarify how the web interface used to configure and visualize the security alarms/events in the FI-WARE Security Monitoring GE is integrated with the Security Dashboard.
We need an agent to collect the log events from Access Control and normalize them to be compatible with the Service Level SIEM component included in the FI-WARE Security Monitoring GE.
We need to evolve the visualization component included the FI-WARE Security Monitoring GE to also offer statistics tools.
Table 38- Security Dashboard - Scenario 1
3.6.1.2 Scenario 2 - Correlation and Visualization of Security Events
Section Description Use Case
id Security Dashboard - Scenario 2 Title &
Description
Correlation and Visualization of Security Events: The user can visualize in the Security Dashboard security alarms and events based on the correlation performed by the Service Level SIEM included in the Security Monitoring GE with the security events generated in the XIFI Federation platform.
Author ATOS
Actors Local System Administrator at a specific node in the XIFI Platform.
Objective The Local System Administrator wants to know the security events which take place in his specific node and have also access to accountability events to do some statistics on it (e.g. most active accounts, resources never accessed).
Pre-Conditions
The system administrator needs to be authenticated with root permissions in the node.
Collecting agents have been installed in the node in charge of a local system administrator which needs to be monitored to collect the security events and send them to the Service Level SIEM component included in the FI-WARE Security Monitoring GE.
Access control at this node needs to report logs (log events).
FI-WARE Generic Enablers which require to be monitored from a security service level perspective in the node must send the events through Syslog to the FI-WARE Security Monitoring GE.
A configurable visualization and/or GUI.
Process Dialog
1. The Local System Administrator wants to visualize and analyse the security events which take place in his/her node. Through the management interface, he/she can configure the security directives, collection methods and other more advanced configuration parameters.
2. The agents installed and running in the node collect the security events according to the collection methods activated and send them to the Service Level SIEM component included in the FI-WARE Security Monitoring GE.
3. Depending on the source of the security events and the security directives configured, the events are correlated by the Service Level SIEM component included in the FI-WARE Security Monitoring GE.
4. The alarms generated by the FI-WARE Security Monitoring GE are stored in a database.
5. The Local System Administrator can visualize detailed information in the Security Dashboard about:
Security Incidents: details about the alarms generated as well as the security events associated and risk evaluated Security Events: details about all the security events collected (date, source, destination, etc.).
Reports: summary of the security information.
Variations N/A
Post-Conditions
The Local System Administrator has identified security incidents or attacks and can react in consequence to protect his node.
Diagrams Use Case Diagram
Figure 96: Use Case Diagram for Correlation and Visualization of Security Events.
Interaction Diagram
Figure 97: Interaction Diagram for Local System Administrator
Issues &
Notes
We need to clarify how the web interface used to configure and visualize the security alarms/events in the FI-WARE Security Monitoring GE is integrated with the Security Dashboard.
We need to clarify the source of the security events which can be monitored in a node to determine the agents that must be installed to collect and normalize them with the current plugins included in the FI-WARE Security Monitoring GE. A new agent is required to collect the log events from Access Control.
We need to clarify if it is required to have some collection method and security directives already predefined and activated by default in any node.
We need to evolve the visualization component included the FI-WARE Security Monitoring GE to also offer statistics tools.
Table 39- Security Dashboard - Scenario 2
3.6.2 Identified Requirements
Based upon the user stories and analysis of the XIFI space, we capture the following requirements of the Security Dashboard.
Req num Description
Req-1 To know what has been done by who, when and on what.
Req-2 On-line and off-line reporting (coarse and fine-grained).
Req-3 Capacity to scale up / scale down.
Req-4 Configurable Security Dashboard.
Req-5 The user can configure security directives to be monitored.
Req-6 The user can visualize security events and incidents in the Dashboard.
Table 40- Security Dashboard - Requirements
3.6.3 Functionalities and Use Cases
Due to the nature of the Security Dashboard module, the scenarios defined previously can be directly translated into use cases and no additional information is needed here,
3.6.3.1 Summary of Features
Feature Description
A Local System Administrator wants to define the security directives to
be monitored in platform node through the Security Dashboard. First Visualization
incidents detected in a node. First
Advanced configuration of correlation rules
The Federation Security Officer wants to configure the Security Dashboard by adding its own correlation rules to be monitored in the
accountability events which take place in the XIFI federation platform. Second Accountability
statistic report
The Federation Security Officer wants to visualize reports about
accountability events on a weekly, monthly basis. Second Selection of
data set visualized
A Local System Administrator or the Federation Security Officer want to define the data set. He/She should also have the possibility to interact with the data set visualized
Second Table 41- Security Dashboard - Features
3.6.4 Baseline technologies.
The Security Dashboard as envisioned would rely on the following:
FI-WARE IdM GE & Access Control GE and the OAuth2.0 based access control framework offered. Regarding IdM GE implementation we will select the one that best fits the requirements of XIFI. The available implementation of these Generic Enablers can be found in the chapter Security by browsing in the FI-WARE Catalogue [19]. Especially we will target here the one developed by UPM once made fully available. The Open Specification of these Generic Enablers can be found in [35] and [37] respectively
WARE Security Monitoring GE. The Service Level SIEM component included in the FI-WARE Security Monitoring GE allows to monitor and correlate security events generated in the XIFI Platform, including the accountability events generated by the access control framework. The web interface provided by the Service Level SIEM will be also used as main management security dashboard to visualize events and alarms. The Open Specification of this Generic Enabler can be found in [32].
3.6.5 Detailed Design 3.6.5.1 Component model
The Security Dashboard module is responsible for the activities which allows users to define the security directives to be monitored in the XIFI platform, to visualize the security events collected for the agents installed in the XIFI platform, the security alarms detected by the correlation of the security events, to visualize and analyze the accountability events taken place in the XIFI Federation.
The below figure shows a diagram highlighting the relations among the components in the Security Dashboard:
Figure 98: Diagram with the relationships among components in the Security Dashboard.
Oauth-Enabled Client App: The Client Application is the third-party from the Resource Owner's point of view that is requesting access to the resources on behalf of that resource owner. The Client Application must be registered in the IdM Generic Enabler.
Identity Management GE: The IdM GE (Identity Management Generic Enabler) provides identity management and authentication for users and client applications.
XACML Access Control Asset is further broken down into five components.
o Policy Decision Point (PDP): The PDP provides authorization decisions based on various attributes and XACML policies.
o Policy Administration Point (PAP): The PAP provides an interface for policy administrators to manage XACML policies to be enforced by the PDP.
o Policy Repository Point (PRP): The XACML PRP is used for storing policies managed by the PAP and retrieved by the PDP for enforcement.
o Policy Enforcement Point (PEP): The PEP protects the Resource Server from unauthorized access to resources. The PEP can be deployed as a security proxy that intercepts all HTTP(S) traffic to the Resource Server. Access is denied or permitted depending on the XACML PDP’s decision.
o Access Control OSSIM Agent: Collecting Agent collects the accountability events and send them to The Service Level SIEM for correlation and visualization.
Resource Server: The Resource Server is the server hosting the resources that the Client Application requests access to. The Resource Server must be registered in the IdM Generic Enabler. The Resource server includes a collecting agent collecting the security events and sending them to the FI-WARE Security Monitoring GE.
Service Level SIEM: The Service Level SIEM or Service Level Security Information and Event Management component included in the FI-WARE Security Monitoring GE is a high performance parallel correlation engine that provides real-time analysis of security events, aggregating data from many sources and providing the ability to consolidate and correlate monitored data to generate reports and alerts. Service Level SIEM is further broken down into three components (simplify architecture):
o Correlation Engine: The Correlation Engine integrates the OSSIM core engine and a high performance correlation engine.
o Visualisation Module: The visualisation module includes its own customizable dashboard.
o Frontend: where the operator can visualise the status of the system and configure the Service Level SIEM.
o Security Dashboard: Security Dashboard Human Machine Interface (HMI).
3.6.5.2 Sequence diagram
In the following section we are going to detail the main sequence diagrams associated to the above functionalities. These diagrams detailed the interaction among all the components through the different functionalities.
Accountability reporting by the Federation Security Officer:
Figure 99: Sequence Diagram for Accountability Reporting
Correlation and visualization of security events by a Local System Administrator:
Figure 100: Sequence Diagram for Correlation and Visualization of Security Events.
In both diagrams the sequence could be summarized by the following steps:
The user of the Security Dashboard (a local system administrator or the Federation Security Officer), wants to monitor security/accountability events and incidents in the XIFI environment (a node or all the XIFI federation platform, depending on the user). He/She can define different collection methods, correlation rules and other configuration parameters through the GUI.
Once the configuration has been applied, the monitoring process starts in the FI-WARE Security Monitoring GE. The events will arrive thanks to the OSSIM agents installed in the node (in the case of a local system administrator) or through Access Control OSSIM agents distributed in the XIFI platform to collect accountability events.
When the user (a local system administrator or the Federation Security Officer) wants to visualize the events collected and the incidents detected, he/she accesses to the GUI provided by the Security Dashboard to recover the information required from the FI-WARE Security Monitoring GE.
3.6.5.3 Data Model
The following picture depicts the necessary entities for the Security Dashboard Module:
Figure 101: Data model diagram for the Security Dashboard
CORR_ENGINE_CONTEXT: This entity identifies the correlation engine included in the Security Monitoring GE. By default, only one correlation engine will be used in the XIFI Platform and most of the rest of entities used in the Security Dashboard will maintain a reference to its CTX id.
ASSETS: The entities HOSTS, PORTS and NETWORK_DEVICES represent the list of inventoried hosts, ports and devices involved in generating the events belongs to the network that is being monitored.
USER: This entity identifies the users available to use the Security Monitoring GE. These users are created by the system administrator and they are identified by a unique login. Besides, a flag is used to identify if the user has administration rights or not. Each user can have relationships with one or more different assets.
SESSION: This entity identifies each session opened by a user in the Security Dashboard through the web interface and they are related through the login field.
INTELLIGENCE: Several entities are used to deal with the correlation process including POLICY,
POLICY: This entity represents a group of settings that handle the security monitoring behavior, specifying what to do with certain events or alarms from certain assets. The user can have defined several policies in the correlation engine.
ACTION: This entity represents programmed actions to be taken when an event or alarm is detected by the correlation engine. There are three types of actions: send an email message, execute an external program or open a ticket.
CORRELATION DIRECTIVE: A correlation directives will create patterns for incoming events. It can be composed by one or more correlation rules.
CORRELATION RULE: This entity defines a condition that will be met by the incoming events. Each correlation rule is associated with a PLUGIN_SID and a PLUGIN.
SENSOR: This entity identifies the source (IP address and port) generating the events to be analysed by the Security Monitoring GE.
DEVICE: A sensor can have one or more devices associated.
PLUGIN: This entity identifies each type of event generated in a device and collected by the security monitoring agents to analyse and standardize its security information.
PLUGIN_SID: It identifies a class of event within the type specified in the PLUGIN entity.
Each PLUGIN_SID is associated to a PLUGIN id.
ACID_EVENT: This entity is associated to the sensor where it was generated and the PLUGIN/PLUGIN_SID used to collect it. It represents any incoming event collected by the SIEM.
EVENT: This entity is also associated to the sensor where it was generated and the plugin_sid used to collect it but it represents the event once it has been processed by the correlation engine.
ALARM: It is a special type of EVENT with has a risk higher than 1. But this type of event may group more than one EVENT when it becomes an alarm generating using correlation directives. The relationship is maintained through the BACKLOG entity.
BACKLOG: This entity contains all those directives matched that either have not reached the last correlation level or have not timed out yet. Each ALARM has a unique relationship with a BACKLOG id.
3.6.6 Graphical User Interface (GUIs)
The following are a sequence of screen mock-ups that illustrate how the Security Dashboard will behave.
Security Dashboard: Security Monitoring Main Screen
The Security Dashboard is integrated in the XIFI Portal so the user only needs to authenticate in it.
Once the user is logged in, the main security management page is presented:
Figure 102: GUI - Security Dashboard: main page.
Security Dashboard: Visualization of events and alarms
When the Analysis section is selected, the collected events are shown in the dashboard with different filtering options:
Figure 103: GUIs - Analysis of events The alarms detected are shown in the Incidents section:
Figure 104: GUIs - visualization of incidents
Security Dashboard: Configuration
Several sections can be used to configure the Security Dashboard but the main page is the Intelligence section where security policies and correlation directives can be defined as it is shown in the following screenshots:
Figure 105: GUIs - configuration of policy
Figure 106: GUIs - configuration of correlation directive.
3.6.7 Interfaces exposed (REST)
The Security Dashboard Module does not expose a RESTful API to access its functionalities. They are provided through a graphical web interface offered by the FI-WARE Security Monitoring GE. The input events are collected through OSSIM agents installed in the XIFI platform or in the node monitored. More information about these agents, the collection methods and the event format can be found in the FI-WARE Security Monitoring GE Open Specifications [32], in the FI-WARE Security Monitoring GE Installation & Administration Guide [34] and in the FI-WARE Security Monitoring GE User & Programmers Guide [33].
Regarding FI-WARE IdM and Access Control GE similar information is available through IdM GE and Access Control GE Open Specifications. As for GE implementations considered in XIFI aka IdM GEi from UPM and Access Control GEi from Thales all details have also been provided on FI-WARE Catalog [19] this together with accompanying manuals (Installation & Administration guide, User &