Abstract:
Security information and Event Monitoring (SIEM) tools collect log data from critical resources which helps organizations to plan appropriate security assessment and reconciliation strategies. Root cause analysis of security risks needs data prevenance capabilities.
Blockchain Technology augments SIEM tools with data provenance capability so that an effective security framework can be built for organizations. In the article, we describe a unified and comprehensive security assurance framework that supports a tamper-proof, time-stamped, and decentralized storage repository that useful in assessing compliance with the security policy framework. We hope the architecture is suitable in the context of the National Blockchain Framework environment.
1. Introduction
The proposed security policy framework comprises various security controls that would be monitored continuously. The monitoring of threat perception with regard to each control entity is in turn dependent on several events that may take place in the underlying system being monitored. It is proposed to identify control entitiesbased onthebelow-depictedmodel inFigure1.
Figure1:Security Policy Assessment Framework
The security policy framework has drawn its inputs from three different sources viz., (a) Cloud Security Alliance Control Matrix v 3.0.1, (b) Top threats on the cloud platform, and (c) Centre for Internet Security benchmarks, each having its own purpose. The cloud security alliance control matrix comprises several control domains that have been grouped into various control domains containing mapping to several industry best practices and standard documents, top threats on a cloud platform give insights into the more frequently observed phenomenon and corresponding preventive mechanisms, and implementation of the observations using CIS benchmark metrics.
It is also proposed to implement Common Vulnerability Severity Score for each control entity as an integral part of the framework. This helps in observing the effectiveness of the policy and guides for further improvising security policy control entities over a period of time.
The security policy framework can be implemented following the Software-as-a-Service paradigm. All resources (here a resource could be NBF node) to be monitored for their compliance with the Security Assessment Policy Framework will have to run an ‘Agent’ program that is entrusted with the job of collecting relevant log information in JSON format and passing the same to the SIEM platform powered by Hyperledger Fabric. In order to ensure data integrity, the JSON object may be encrypted before sending to the SIEM platform. The smart contracts in the SIEM platform upon receiving the JSON object would decrypt the same to verify its integrity. Modified JSON objects would be rejected and will not be stored in the SIEM platform.
2. SIEM Blockchain Platform Architecture
The advantages of using SIEM Blockchain are (a) The security policy-relevant information that is collected from each resource that is to be monitored in NBF gets replicated in all the SIEM platform’s nodes in a tamper-proof and time-stamped manner based on the underlying consensus mechanism (b) Reduces log processing load on the resources (i.e., NBF Nodes) being monitored by delegating the data processing to the SIEM platform. (c) Due to the consensus-based unique state representation of data across all the SIEM platform’s nodes, all stakeholders would see the same data provenance or its analysis report at any given time without loss of generality.
The SIEM Blockchain platform may have three logical organizations (a.k.a Organizations in HLF) namely NBF Administrator, Application Owner, and Information Security Auditor. Each logical organization can be assumed as a representation of corresponding real-time entities. A schematic diagram of the proposed deployment scenario is shown below in Figure 2.
Since logical organizations have been defined based on the functionalities of respective stakeholders who are concerned about the security of the NBF, and all stakeholders are ensured of unique state replication with the tamper-proof capability the SIEM platform can be regarded as a fool-proof, robust and trustworthy system. Because of the Hyperledger Fabric’s inherent capability of maintaining a consortium of logical organizations and restricting message exchanges among the consortium members only through a concept called ‘Channel’ the SIEM platform can be used to extend its service to multiple groups of NBF administrators, Application Owner and ISA where each group is responsible for monitoring the compliance with the security policy framework.
The roles of each stakeholder of a consortium can be defined as follows.
NBF Node: A resource to be monitored that is designated as “peer” and is also member of the same channel where other stakeholders of the same consortium have already joined the channel.
NBF Administrator: A user or entity that is responsible to provision resources for Application Owner and joins the same channel.
Application Owner: A user or entity that is running its own Blockchain network on NBF and joins the same channel
System Security Auditor: A user who represents a system auditor who can monitor resources health status of NBF nodes that are members of the same channel.
The SIEM Blockchain system level architecture is as shown in Figure 3 and the control entities of prototype version is as shown in Figure 4 below.
Figure3:SIEM System LevelArchitecture Figure4:Control Entities and CCM Matrix Mapping
Users from different geographical locations can access such a system as Software-as-a-Service. Having been informed about the role of the SIEM Blockchain platform and its necessity, we now focus on how the SIEM platform reports its findings. For this purpose, two different metrics (a) Compliance rate – Which informs to what extent the service provider is compliant with the pre-defined security assurance policy (b) Severity level – Which informs the perceived threat severity level as per the criteria defined by CVSS scores to measure the overall health report of the resources controlled by each NBF consortium.
Compliance Rate can be calculated as CR = (Xt-1 – Xt ) / Xt-1 where Xt is no of security violations that are observed at time t and Xt-1 is at time t-1. CR represents the observed rate of change w.r.t identified non-compliance factors of security policy. The CR represents the compliance rate against the security policy pertaining to the most recent time window. The time window represents the gap between two successive vulnerability analysis attempts. The time window is a configurable parameter that defines how frequently the security log and other critical information have to be collected from the critical resources to be monitored.
The average Compliance rate is a simple mean of different CR values corresponding to different time windows over an extended period of time, for example, for every 24 hours, for every month etc.
A prototype version in line with the above-proposed concept has been built and tested in a local data center and the same can be explored for its suitability in the NBF platform.
3.Reference
[1]Technical article submitted to 25th ICACT Conference with detailed implementation methodology titled “A Blockchain-based Security Information and Event Monitoring Framework”.
4. Autobiography
N Satyanarayana is a Master of Technology in Computer Science holder from Jawaharlal Nehru Technological University, Hyderabad, India. Prior to this, he completed his Master’s in Computer Applications from Sri Venkateswara University in the year 1999. He published several papers in National and International conferences in various areas such as Peer to Peer Computing, Network Management, e-Learning and Blockchain. His current research interest includes Blockchain consensus algorithms and reference architectures.
