Uploaded byChadni Islam
Architecture-centric Support for Integrating Security Tool in a Security Orchestration Platform
The document discusses an architecture-centric approach for integrating security tools into a security orchestration platform to enhance agility and modularity. It outlines the challenges faced by existing platforms and proposes a layered architecture that supports automation and integration processes for incident response. Additionally, the authors present a prototype implementation showcasing the capabilities of various security tools and suggest future work for deployment automation and large-scale mapping.
More Related Content
Similar to Architecture-centric Support for Integrating Security Tool in a Security Orchestration Platform
Architecture-centric Support for Integrating Security Tool in a Security Orchestration Platform
- 1. Architecture-Centric Support forIntegrating Security Tools in a Security Orchestration Platform Authors: Chadni Islam, Muhammad Ali Babar, and Surya Nepal CREST, University of Adelaide, Adelaide, Australia CSIRO’s Data61, Australia
- 2. Outline Introduction Challenges Research Aim Proposed Solution Evaluation Limitations FutureWork CREST | University of Adelaide 2
- 3. Introduction Architecture-Centric Support forIntegrating Security Tools in a Security Orchestration Platform| ECSA 2020 3 Firewall Intrusion Detection System (IDS) Endpoint Detection and Response (EDR) Detect and Prevent Integrate Analyze Validate Plan Monitor and Analyze Security Operation Centre I1 I2 S: Security ToolA: Assets AC: ActivityI: Security Incident Organization Security Operation Centre
- 4. Introduction CREST | Universityof Adelaide 4 Firewall Intrusion Detection System (IDS) Endpoint Detection and Response (EDR) Security Orchestration and Automation Platform Detect and Prevent S: Security ToolA: Assets AC: Activity I1 I2 I: Security Incident Security Orchestration and Automation Platform (SOAR) Search Organization t: Task IRP: Incident response plan
- 5. Challenges in existingSOAR platforms • Lack proper abstraction for designing a platform at architecture level • Designed in ad-hoc manner – Difficult to embed agility in a SOAR platform – Results in complex and monolithic design that is hard to evolve • Lack of conceptual and practical guideline for optimal architecture design decision Architecture-Centric Support for Integrating Security Tools in a Security Orchestration Platform| ECSA 2020 5
- 6. Research Aim How softwarearchitecture can play a role in improving the design practices of a SOAR Platform? CREST | University of Adelaide 6 |
- 7. Proposed Solution (1/3) Architecture-CentricSupport for Integrating Security Tools in a Security Orchestration Platform| ECSA 2020 7 A Concept Map of Security Orchestration and Automation Incident Response Plan Playbook Designer SOAR Developer Detection Analysis Response implements requires provides integrates Activity Security Tool Task executes executes Unification Orchestration Automation Playbook Orchestration Process runs and manages supports Organization SOAR Platform Capability Legend A B A B Composition Generalization A Brelation uses
- 8. Proposed Solution (2/3) CREST| University of Adelaide 8 High-level Architecture for SOAR platform Semantic Layer Integration Layer Orchestration Layer Data Processing Layer Tool Registry Interpreter Data Extractor PlannerOrchestratorTask Manager Query Engine Plugin Repositories UI Layer Abstraction Layer API GatewayWrapper Security Tool Layer Knowledge Base Data Analyzer Security Tool Security Tool Security Tool Security Tool Users Integration Manager Data Curator
- 9. Proposed Solution (3/3) •Process Decisions – Integration process – Interpretation process – Security tools to capability mapping process – Security tool discovery process – Security tool invocation process • Technology Decisions – Integration technologies – Interpretation mechanisms – Tools discovery mechanisms Architecture-Centric Support for Integrating Security Tools in a Security Orchestration Platform| ECSA 2020 9 Dimensions of Design Space
- 10. Prototype Implementation (1/5) •Two scenarios – Automating the process for integration of security tools – Automating the interpretation of the activities to execute IRP • Security Tools – Snort, Splunk, Limacharlie, Wireshark, Windows defender, MISP • 24 different capabilities 10CREST | University of Adelaide
- 11. Capabilities of SecurityTools • δSplunk = {F2, F3, F4, F9, F10, F11} • δSnort = {F1, F5, F6} • δLimacharlie = {F2, F7, F8, F12} Activity Functional capability 𝑎𝑐1 Detect incident Intrusion detection F1 𝑎𝑐2 Collect alert log Log collection F2 𝑎𝑐3 Identify affected system Alert analysis F3 𝑎𝑐4 Generate incident report Report generation F4 𝑎𝑐5 Sniff network packet Packet sniffing F5 𝑎𝑐6 Log network packet Packet logging F6 𝑎𝑐7 Isolate affected node Node isolation F7 𝑎𝑐8 Kill malicious process Process killing F8 𝑎𝑐9 Generate report Report generation F9 𝑎𝑐10 Monitor event Event monitoring F10 𝑎𝑐11 Manage log Log management F11 𝑎𝑐12 Investigate alert Alert analysis F3 𝑎𝑐13 Generate alerts Intrusion detection F1 𝑎𝑐14 Scan endpoint Intrusion detection F1 𝑎𝑐15 Remove malware Process killing F8 Prototype Implementation (2/5) Architecture-Centric Support for Integrating Security Tools in a Security Orchestration Platform| ECSA 2020 11 Incident type Incident response plan (IRP) 𝐼1 DDoS attack 𝑎𝑐2, 𝑎𝑐12, 𝑎𝑐5, 𝑎𝑐3, 𝑎𝑐13, 𝑎𝑐10, 𝑎𝑐7, 𝑎𝑐9 𝐼2 Malicious process 𝑎𝑐10, 𝑎𝑐11, 𝑎𝑐3, 𝑎𝑐9, 𝑎𝑐8 𝐼3 Malware 𝑎𝑐14, 𝑎𝑐12, 𝑎𝑐15, 𝑎𝑐9
- 12. Prototype Implementation (3/5) 12 Implementationarchitecture for security tool integration CREST | University of Adelaide MISP API LimaCharlie API Splunk API MISP API LimaCharlie API Splunk API InputOutput Wrapper Wrapper Wrapper Wrapper Ontology Collector Process Orchestration Collected data Integration Security Tools Send data (alert, log, report, packet) Interpreted data invoke process Invoke tools MISPSplunk LimaCharlie Snort Wireshark WinPcap WinDefender command Data Analyzer SPARQL query engine IRP Orchestrator Interpreter Output Handler Input Constructor
- 13. Prototype Implementation (4/5) Architecture-CentricSupport for Integrating Security Tools in a Security Orchestration Platform| ECSA 2020 13 Security tool Security Tool class has Capability Capability class executeActivity snort_s IDS intrusion_detection_s IntrusionDetection detectIncident limaCharlie_l EDR intrusion_detection_l process_killing_l IntrusionDetection ProcessKilling detectIncident killProcess splunk_s SIEM log_collection_s alert_analysis_a LogCollection AlertAnalysis collectAlertLog investigateAlert Illustration of selected set of object properties of security tool class of an ontology
- 14. Prototype Implementation (5/5) CREST| University of Adelaide 14 Interpreter SplunkCollector -String: dir +run() .... OutputHandler -log: DataElement +run() ... Directory Splunk <<Interface>> InputConstructor +formulateCommand(String) Output to directory LimacharlieInputConstructor +deleteFile(String, String) +killProcess(String, String) ..... +interpret(DataElement) ArrayList<HasMap> Querier +getToolCaps(String) +getReqCaps(String) Ontology <<Interface>> Collector +getData(DataElement) ..... LimaCharlie Orchestrator +execute() +getProcess(String)IRP Example of data transfer from Splunk to LimaCharlie
- 15. Results (1/2) • Automatingthe Integration of Security Tools - Integration of new security tool - MISP - Integration approaches - Static APIs - Plugins based integration - Semantic based integration Architecture-Centric Support for Integrating Security Tools in a Security Orchestration Platform| ECSA 2020 15 With semantic based integration approach the number of components and connections remains constant with the integration of new security tools
- 16. Results (2/2) • Automatingthe interpretation of the activities to execute an IRP - Integration of new IRPs or activities - Identify and isolate suspicious endpoints - Implementation of SOAR platform - Non modular and Monolithic - Modularized – separation of concerns CREST | University of Adelaide 16 Incorporation of changes with the proposed architectural implementation is easier and requires less overhead in comparison to other approaches
- 17. Limitations • The PoCis developed based on freely available and open source security tool’s capabilities and activities • Feasibility of the proposed architecture is performed for two scenarios based on three quality attributes Future Work • Design space and deployment automation of SOAR platforms • Large scale mapping of existing SOAR platforms and IRPS onto the architecture design decisions Architecture-Centric Support for Integrating Security Tools in a Security Orchestration Platform| ECSA 2020 17
- 18. Key Takeaways • Considerationof architecture design decisions to describe and evaluate existing and new SOAR platform • A conceptual map of SOAR platform to support architect’s understanding the design space of a SOAR platform • Identification of the requirements of a SOAR in terms of unification, orchestration and automation and propose a layered architecture help to modularize the functions and separate the concepts of the components of a SOAR platform • Consideration of the principle dimension of architecture design space improves SOAR design practices CREST | University of Adelaide 18
- 19. References • Chadni Islam,Muhammad Ali Babar and Surya Nepal. Architecture- centric Support for Integrating Security Tools in a Security Orchestration Platform. 14th European Conference on Software Architecture (ECSA’2020), September 14-18, 2020, L’Aquila, Italy. • Chadni Islam, Muhammad Ali Babar, and Surya Nepal, Automated Interpretation and Integration of Security Tools Using Semantic Knowledge. 31st International Conference on Advanced Information Systems Engineering, CAiSE, 2019, Rome, Italy, 3-7 June 2019. • Chadni Islam, Muhammad Ali Babar, and Surya Nepal, An Ontology- Driven Approach to Automate the Process of Integration Security Software Systems. International Conference of Software and Systems Process, ICSSP, 2019, Montreal, Canada, 2019. • Chadni Islam, Muhammad Ali Babar, and Surya Nepal. 2019. A Multi- Vocal Review of Security Orchestration. ACM Computing Survey. Vol 52, Issue 2, Article 37 (April 2019), 45 pages. DOI: https://doi.org/10.1145/3305268. Architecture-Centric Support for Integrating Security Tools in a Security Orchestration Platform| ECSA 2020 19
- 20. Acknowledgement • CREST teammembers (https://crest-centre.net/) • School of Computer Science, University of Adelaide, Australia • CSIRO’s Data61, Australia CREST | University of Adelaide 20
- 21. Q&A Architecture-Centric Support forIntegrating Security Tools in a Security Orchestration Platform| ECSA 2020 21 Chadni Islam CREST (https://crest-centre.net/) School of Computer Science, University of Adelaide, Australia Email: chadni.islam@adelaide.edu.au
Editor's Notes
- #2 Hello Everyone, This is Chadni Islam, from CREST research group of University of Adelaide, Australia. Here, I am going to present our work on architecture centric support for integrating security tools in security orchestration platform. This work has been carried out as part my of PhD research under the supervision of Prof. m. Ali Babar and Dr. Surya Nepal
- #3 Throughout my presentation, I will first provide an overview of security orchestration platform, then what are the challenges that we are trying to overcome through this work, Followed by our research goal, and proposed solutions. Next, I will show how we have evaluated the work and Finally I will conclude my presentation by highlighting the limitation and future work.
- #4 The security operation centre of an organizations uses a variety of security tools to protect an organization’s information and technology infrastructure. One of the key challenges of SOC is to quickly integrate these security tools to perform operational activities as these security tools are not interoperable and work in silos. To address the challenge, increasing adoption of security orchestration platform has been seen in SOC environment.
- #5 SOAR platforms enable integration, orchestration and automation of the activities performed by security tools and human experts. Deployment of a SOAR platform requires an organization to asses their existing security tools capabilities and prepare an incident response plan. By security tool capability we mean a tools ability to perform an activity such as block an IP and scan endpoint for malicious activities. Emerging threat behaviours cause changes in the deployment and execution environment of SOAR platform such as, change in security tools and incident response plans, thus cause changes in a SOAR platform. However the changes in the orchestration platform are not straightforward.
- #6 Because Existing SOAR platform lack proper abstraction for designing such a platform at the architecture level. Most of the existing platforms are implemented in ad-hoc manner without much attention to the underlying infrastructure. Ther fore it become difficult in embedding agility in a such platform. Also adhoc changes make the architecture complex that make it hard to evolve. We also observered there is a lack of conceptual and practical guidelines for optimal architecture design decisions.
- #7 Heres’ come our research how software architecture can play a role in improving the design practices of a SOAR platform. We found that an architecture centric approach is expected to help in reducing the design complexity of a SOAR by modularizing the functionalities and non functional requirements
- #8 We first propose a concept map of a SOAR platform that defines and relates the key concept of a such a platforms’ design space. The concept maps shows that an Organization generally deploy a SOAR platform on top of existing security tools and infrastructure. A developer of a SOAR platforms design and develop different integration mechanism such as API, plugins and wrapper to integrate security tools. Beside this, a SOAR platform also runs and manages orchestration process generally designed in the form of a set of playbooks.
- #9 Next, We Provide a layered architecture that modularize the key components into six different layers to ensure the functional and non functional requirements of a SOAR platform. We consider two functional requirements – one is a SOAR work as a unifier or hub and another SOAR work as a coordinator. We consider three Quality Attributes Requirements – Integrability, Interoperability and Interpretability. We design the architecture in two level of abstraction . The layers provide the higher level of abstraction and components in each layer provide the lower level of abstraction. From the design space of a SOAR, we found that integrated security tools and orchestration process mainly govern the tasks of a SOAR platform.
- #10 Thus we consider the architecture design decision from process and technology perspective for automatically integrating security tools and interpreting their activities of IRPs. For example, We considered integration process and interpretation process such as how a SOAR platform integrate a security tools and how it can interpret the data generated by different security tools.
- #11 To evaluate the proposed approaches, we have developed a proof of concept system leveraging the architecture centric support. We evaluated the results based on two use case scenarios – for auto Integrating a new tool required and automated execution of IRPS. We consider two types of changes - change in security tools and change in IRPs. We designed the PoC in a way so that it is easily evolvable for future changes. We selected several tools with varied capabilities. We used 24 different capabilities of the selected tools.
- #12 Here we shows some examples security tools capabilities, activities and Incident response plans. We have selected 21 IRPs and slightly modified them to fit the capabilities of the security tools.
- #13 This is our implementation architecture. We consider semantic based integration style as our primary mechanism to integrate security tools. The data from security are accessible through their APIs and wrappers. We designed an ontology to formalize security tools, their capabilities and IRP’s activities to enable semantic interpretation of security tools data. We designed a SPARQL query engine and an interpreter to retrieve the required information from the ontology and interpret the retrieved data for further processing. We designed and implemented scripts to define the automated integration process, which includes selecting the security tools based on activity description, interpreting their capabilities, formulating the input commands and finally invoking the security tool by calling appropriate APIs The orchestrator coordinate the communication.
- #14 An example of selected set of properties of security tool class of an ontology is shown here. Each security tool can execute multiple activities and each activity can be executed by multiple security tools
- #15 Here we show an example of our developed automated interpretation process which is part of the integration process. Here the output of Splunk is sent to LimaCharlie. The orchestrator is required to collect the output of Splunk and then interpret it. All the data generated by Splunk might not be required by LimaCharlie; so, the orchestrator would require to construct the input of LimaCharlie from Splunk’s output to invoke LimaCharlie. Using the automated process, data sharing among the security tools happened seamlessly.
- #16 For automating the integration of new security tools, we have considered MISP as a new tools and different types of integration approaches. With static APIs and wrapper based integration approach integrating a single tool would require development of at least one component and connection of that component with the orchestrator. With the semantic-based integration approach, we only need to update security tools details in an ontology. The connections between the ontology and other components have already been designed and that do not require any changes. Thus, with semantic based integration approach number of components and connections remain constant with the integration of new security tools. This demonstrates that the proposed architecture-based implementation keeps the components and connections lower by reusing the existing components
- #17 For automating the integration of the activities we consider 48 new IRPs We consider two types of implementation. With the non-modular and monolithic implementation, each playbook is designed for a specific IRP which cannot be reused even if the new IRP is a subset of the existing IRPs. Thus, A user requires to modify the existing playbook to execute the new IRP. Developing a playbook would require an understanding of a playbook’s structure, knowledge of the available security tools, developing scripts to access the generated data of the security tools and their specific APIs to execute an activity. With our implemented PoC. As the process for automatically identifying the capabilities required to execute an activity and selecting the security tools are already defined, a user would not require to manually identify the security tools or update the playbook. Thus considering the architecture design decision from the beginning of the design and development of a orchestration platform make it easier and require less overhead compared to the other approaches to execute new incident response plan.
- #18 Our work has some limitation. The PoC is developed based on freely available tools and their capabilities, and we only consider three quality attributes and two scenarios. Our work has laid a foundation for future research on the design space and deployment automation of SOAR platforms. We plan to conduct large scale mapping of the existing SOAR platform and IRPs onto architecture design decision to generate patterns and hide interactions among the different components across multiple technology.
- #19 The key takeway of our work are Exploring and understanding the architectural design decision before designing and implementing a SOAR platform is a valuable task. Capturing the architecture design decision would help developers as well as SOC staff of an organizations to systemize their decision. Based on the development of the proof of concept system, We have observed that considering the principle dimension improves SOAR design practices.
- #20 Here some of the refernces that can be folllwoed.
- #21 I would like to conclude my presentation by Acknowledging the contribution of crest team members for their feedbacks in improving the work.
- #22 Thank you for listening, Questions and suggestions are highly appreciated.