Architecture centric support for security orchestration and automation
•
5 j'aime•373 vues
The presentation was prepared for the University of Adelaide School of Computer Science Research Seminar Series. See the slides to know - what is security orchestration? - what are the key challenges in this domain? - how software architecture can play a role in improving the design decision of security orchestration and automation platform?
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Architecture centric support for security orchestration and automation
Similaire à Architecture centric support for security orchestration and automation (20)
Dernier
Dernier (20)
Architecture centric support for security orchestration and automation
- 1. ARCHITECTURE CENTRIC SUPPORT FOR SECURITY ORCHESTRATION AND AUTOMATION Presented by: Chadni Islam
- 2. About Me Work Experience • Research Fellow, CREST, University of Adelaide, Australia (August 2020 – Present) • Lecturer, Khulna University, Bangladesh (March 2016 – March 2017) • Lecturer, Eastern University, Bangladesh (May 2015 – May 2016) Education • PhD in Computer Science, CREST, University of Adelaide and CSIRO’s Data61, Australia - Thesis Submitted for Examination in July 2020 • MSc and BSc in Computer Science and Engineering, University of Dhaka, Bangladesh - February 2009 - June 2015 Research Expertise • Engineering data-driven system and software • Designing and implementing architecture to support large scale realization of complex system (e.g., security orchestration and automation) • Assessing and evaluating analytical reasoning, natural processing techniques and machine learning approaches to develop intelligent, scalable, secure and self-adaptive software system CREST | University of Adelaide 2
- 3. Centre for Research on Engineering Software Technologies (CREST) • Website • http://crest-centre.net/ • Collaborations with many academia and industry partners CREST | University of Adelaide 3
- 4. Outline PhD work • Security Orchestration and Automation • Challenges, Research Objectives and Aims • Proposed Solutions • Results Ongoing work and student projects • Automated Validation of Security Threat Data • Recommendation System for Security Operation Centre CREST | University of Adelaide 4
- 5. • Thesis • Architecture Centric Support for Security Orchestration and Automation • Supervisors M. Ali Babar CREST, University of Adelaide Australia Surya Nepal CSIRO’s Data61 Australia Cyber Security Artificial Intelligence (AI) My PhD Research Software Engineering CREST | University of Adelaide 5
- 6. Security Incident “A security incident is an unwanted or unexpected event/events that have a significant probability of compromising the security of an organization’s assets. ” 6CREST | University of AdelaideCREST | University of Adelaide
- 7. Root Cause of Security Incident and Impacted Industries 7 Source: https://ridethelightning.senseient.com/2019/04/bakerhostetlers-fifth-annual-data-security-incident-response-report-released.html Five Root Cause 750 Incidents CREST | University of Adelaide
- 8. Global Cost of Cyber Crime 8 Source: https://www.ibm.com/downloads/cas/861MNWN2 41% increase in the cost of data breach in UK in two year. CREST | University of Adelaide
- 9. Overview of an Organization Decision Against Security Incident CREST | University of Adelaide 9 IDS/IPS AnalyzeSystem Activities Response Integrate Validate Update Threat Intelligence Block address Implement & Enforce Policy Configure Analyze Security Operation Centre Investigate SIEM IDS IDS Scenario of an Organization Plan SIEM: Security Information and Event Management IDS: Intrusion Detection System Firewall Alert
- 10. Organizations Plan to Response to a Security Incident CREST | University of Adelaide 10 Example of Incident Response Plan (IRP) for Phishing Attack # Response Task Activity 1 Is this a phishing attack? Determine if this is a phishing attack? In the task, select yes or no in the outcome. 2 Scan endpoint – malware found? After running a scan, determine whether malware was found. In the task, select yes or no in Outcome. 3 Remove malware – success? Determine whether the malware was successfully remove. In the task, select Yes or no in outcome. 4 Wipe and reimage If you did not successfully remove the malware found, this task instruct you to perform a wipe and reimage on the computers infected with the malware. 5 Update email protection software If it was determined that this is a phishing attack, you are prompted to update your email protection software accordingly. 6 Remove unread phishing email in queue – For Perform the steps necessary to remove the phishing email still in the queue for all of your users
- 11. Different Task Performed by Security Team CREST | University of Adelaide 11 MONITOR PROTECT PREVENT DETECT ANALYZE PLAN RESPONSE EVALUATE Network monitoring tool Firewall Intrusion Prevention System Intrusion Detection System SIEM Endpoint Detection & Response … … … Wide Variety of Security Solutions A Wide Range of Multivendor Security Solutions On Average 25 different security tools, that can be more than 100 for some organizations
- 12. Problem with Traditional Approach Security Tools Security Experts CREST | University of Adelaide 12
- 13. Problem with Traditional Approach … Incident Response Timeline CREST | University of Adelaide Source: http://e.bakerlaw.com/rv/ff00498db267a11ce4182d53934889997a36f6d4/p=8213342/ 28Days --- Time to complete forensic investigation 66Days --- Occurrence to Discovery 8Days --- Discovery to Containment 56Days --- Discovery to Notification Occurrence Containment Notification Forensic Investigation Discovery 0 122 Days 13
- 14. Problem with Traditional Approach … CREST | University of Adelaide 14 Cybersecurity skills gap worsens, security teams are understaffed 2018 Source: https://cybersecurity.isaca.org/state-of-cybersecurity 2019
- 15. Solution?? Security Automation ??? 15 | Security Orchestration and Automation Security Automation ???
- 16. Security Orchestration and Automation (SOAR) Connect and Integrate disparate security solutions Streamlines incident response process Bridge the gap between detection and response Pre-requisite for security automation Unification of people, process and technology Instantly perform the repetitive job of a security experts CREST | University of Adelaide 16 Introduction
- 17. Security Orchestration and Automation (SOAR) … MARKET PRICE – 1.6 BILLION USD BY 2021 WIDESPREAD ADOPTION IN LAST COUPLE OF YEARS SEVERAL START UPS AND ACQUISITION HAVE ARRIVED CREST | University of Adelaide 17 Introduction
- 18. Security Orchestration and Automation (SOAR) … Problem CREST | University of Adelaide 18 … … … Lack of Comprehensive view Lack of Common Understanding Lack of research in Academia
- 19. Challenges in Existing SOAR platforms • Lack proper abstraction for designing a platform at architecture level • Designed in ad-hoc manner • Difficult to embed agility in a security orchestration and automation platform • Results in complex and monolithic design that is hard to evolve • Lack of conceptual and practical guideline for optimal architecture design decision CREST | University of Adelaide 19
- 20. Research Aim Architecture-centric support for integrating security tools in a SOAR platform where a SOAR platform works as a hub for security tools and security teams.
- 21. Research Questions (RQs) 1. How has security orchestration been defined and what are the key challenges in security orchestration? 2. How software architecture can play a role in improvising the design practice of security orchestration and automation platform? 3. What kind of tools and techniques can be incorporated to realize the architecture while fulfilling the functional and NFR of the implemented platform? How is it possible to enable semantic interoperability and interpretability among security tools and SOAR platforms? How is it possible to automate the process of integrating security tools in a SOAR platform? How is it possible to hide the internal complexity of a SOAR platform from the security team? CREST | University of Adelaide 21
- 22. Research Overview Background State of the art State of the practice Literature Review (CSUR 2019) Engineering Security Orchestration and Automation Solution Functional Requirements Non-Functional Requirements Key Components Security Orchestration and Automation Architecture (ECSA 2020) Realization of the Architecture Interpretation and Interoperability Security Tool Integration Architectural Complexity Encapsulation Semantic Based Integration (CAiSE 2019) Automated Process for Integration (ICSSP, 2019) AI Enabled Declarative API (In Submission) Key Contribution A Novel Layered architecture of SOAR platform Ontology based Integration Process NLP and NL based Integration Framework Declarative API driven SOAR platform How has security orchestration been defined and what are the key challenges in security orchestration? 22
- 23. A Multi-Vocal Literature Review (MLR) Chadni Islam, Muhammad Ali Babar, and Surya Nepal, “A Multi-vocal Review of Security Orchestration”, ACM Computing Survey, 2019 23 |
- 24. Research Question for MLR What is Security Orchestration? What challenges security orchestration intend to solve? What types of solutions have been proposed? What practices have been reported for adopting security orchestration? What types of tools and techniques researchers and practitioners use, propose, design, and implement in practice? What aspects of architecture security practitioners consider for large-scale deployment of security orchestration? CREST | University of Adelaide 10/6/2020 24
- 25. Multi-Vocal Literature Review - MLR Systematic literature review of state-of-the-arts and state-of-the-practices CREST | University of Adelaide 25 Planning and Designing Conducting Reporting 01 02 03 Legend Main step Activity Sub-step Flow Start/End Sub step Flow Start Conducting MLR Data extraction Data extraction based on RQ Study Selection Data Synthesis and Data Analysis Generalization and categorization Identification of key elements MLR planning and design Inclusion and exclusion criteria Research Identification MLR Goal RQs Search Strategies Selecting Data source Design search strings End Reporting MLR Mapping and review results 10/6/2020
- 26. Multi-Vocal Literature Review – MLR … Study Selection CREST | University of Adelaide 26 | Selection of Grey Literature IEEE ACM Step 2: Screen on basis of title and abstract SCOPUS Step 1: Running search string Step 3: Removing duplicates Step 4: Excluding paper shorter than 6 pages 600 271 1017 IEEE ACM DL SCOPUS N: 271 N: 290 N: 225 N: 37 DBLP N: 19 N: 274 Manual Search Google scholar N: 6 Step 6: Additional search on Google Scholar Running search string Applying eligibility criteria Google Search Engine N: 52 Crawl through Websites N: 43 N: 95 Studies included for qualitative synthesis Selection of Academic Literature Step 5: Articles screened on basis on full text 10/6/2020
- 27. What is Security Orchestration? 27 |
- 28. Security Orchestration “Security Orchestration is the planning, integration, cooperation, and coordination of the activities of security tools and experts to produce and automate required actions in response to any security incident across multiple technology paradigms.” CREST | University of Adelaide 28 Definition 10/6/2020
- 29. Key Functionalities of Security Orchestration • Unify security tools • Determine endpoint for human investigation • Share contextual insight Act as a hub • Translate complex process into streamline workflow • Maintain process consistency across security program • Provide deployment model • Determine appropriate course of action Orchestrate security activities • Automate repetitive and manual task • Automate policy enforcement across disparate solutions Enable automated response CREST | University of Adelaide 10/6/2020 29
- 30. Overview of an Organization Decision Against Security Incident CREST | University of Adelaide IDS Integrate Analyze System Activities Security Experts Validate Alerts Update Threat Intelligence Organization Block address Investigation Plan Update Threat Intelligence Block address Configure With Orchestration Manual Automate Implement & Enforce Policy Orchestration Platform Integrate ValidateAnalyze Configure Without Orchestration Investigate Plan Response CREST | University of Adelaide 30
- 31. Core Components of Security Orchestration Security Orchestration Platform Unification Unit Description Module Collector Pre- processor Dashboard Orchestration Unit Planning Module Threat Intelligence Detection Module Automation Unit Remediation Module Action Performer CREST | University of Adelaide 31
- 32. Key Quality Attributes of Security Orchestration CREST | University of Adelaide 32 | UsabilityAdaptability Flexibility Timeliness AccuracyScalability
- 33. What Challenges Security Orchestration Intend to Solve? 33 |
- 34. Drivers of Security Orchestration CREST | University of Adelaide Socio-technical Issues Technical Issues Challenges Lack of tools and technologies to automate response Lack of Interoperability among isolated security tools Limitation of existing tools to provide required services Lack of collaboration and coordination Lack of skills and expertise Lack of frameworks More responsibility on human experts 34
- 35. What types of solutions have been proposed? 35 |
- 36. Taxonomy of Security Orchestration CREST | University of Adelaide Workflow Scripting Prioritization Learning Plugin Auto-Integration Automation Strategy End point Cloud Data Centre Threat Management Execution Environment Automated Semi -Automated Manual Task Mode Central Distributed Hybrid Deployment Type Security Orchestration Platform 36
- 37. Open Issues CREST | University of Adelaide • Little involvement and collaboration among different level of staffs during the orchestration and automation • Lack of security architect for risk and policy management • No holistic training for staff to understand security orchestration platform, integrated tools and incident response workflow • Insufficient alignment of Incident response process with organizations existing IT operational framework • No clear agreement among vendor what need to orchestrate and what can be automated • No guideline to assess maturity of orchestration process and incorporate automation into the system • Lack of modeling notation and language to support integration of security information at runtime • Increasing diversity of integrated security solutions due to dynamic change of attack patterns • Few research on AI for scalable and flexible security orchestration and integration TechnologyPeople Process 10/6/2020 37
- 38. Research Overview Background State of the art State of the practice Literature Review (CSUR 2019) Engineering Security Orchestration and Automation Solution Functional Requirements Non-Functional Requirements Key Components Security Orchestration and Automation Architecture (ECSA 2020) Realization of the Architecture Interpretation and Interoperability Security Tool Integration Architectural Complexity Encapsulation Semantic Based Integration (CAiSE 2019) Automated Process for Integration (ICSSP, 2019) AI Enabled Declarative API (In Submission) Key Contribution A Novel Layered architecture of SOAR platform Ontology based Integration Process NLP and NL based Integration Framework Declarative API driven SOAR platform How software architecture can play a role in improvising the design practice of security orchestration and automation platform? 10/6/2020 38
- 39. Security Orchestration Architecture 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). 39 |
- 40. Proposed Solution (1/3) A Concept Map of Security Orchestration and Automation CREST | University of Adelaide 40 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
- 41. Proposed Solution (2/3) High-level Architecture for SOAR platform CREST | University of Adelaide 41 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
- 42. 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 CREST | University of Adelaide 42 Dimensions of Design Space
- 43. Prototype Implementation (1/2) • 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 43CREST | University of Adelaide
- 44. Prototype Implementation (2/2) Implementation architecture for security tool integration 44 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 CREST | University of Adelaide
- 45. Research Overview Background State of the art State of the practice Literature Review (CSUR 2019) Engineering Security Orchestration and Automation Solution Functional Requirements Non-Functional Requirements Key Components Security Orchestration and Automation Architecture (ECSA 2020) Realization of the Architecture Interpretation and Interoperability Security Tool Integration Architectural Complexity Encapsulation Semantic Based Integration (CAiSE 2019) Automated Process for Integration (ICSSP, 2019) AI Enabled Declarative API (In Submission) Key Contribution A Novel Layered architecture of SOAR platform Ontology based Integration Process NLP and NL based Integration Framework Declarative API driven SOAR platform What kind of tools and techniques can be incorporated to realize the architecture while fulfilling the functional and NFR of the implemented platform? How is it possible to enable among security tools and SOAR platforms? 10/6/2020 45
- 46. Semantic Based Integration 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 46 |
- 47. Proposed Solution (1/4) Ontological Model to enable Semantic Integration CREST | University of Adelaide 47 Integration framework for Security Orchestration Platform # Response Task Action ac1 Is this a phishing attack? Determine if this is a phishing attack? In the task, select yes or no in the outcome. ac2 Scan endpoint – malware found? After running a scan, determine whether malware was found. In the task, select yes or no in Outcome. ac3 Remove malware – success? Determine whether the malware was successfully remove. In the task, select Yes or no in outcome. ac1 : Is (Verb) this (Det) a (Det) phishing (Verb) Attack (Noun) ? (Punc) = Is (Validate) Phishing Attack Subclass: Validate Validate Phishing Validate Phishing Email 10/6/2020
- 48. Proposed Solution (2/4) CREST | University of Adelaide 48 Semantic Layer: Part of the Ontology Three key classes: Security System, Capability and Activity The Relationship between security system and capability class Instance of Classes 10/6/2020
- 49. Proposed Solution (3/4) CREST | University of Adelaide 49 Automated categorization and annotation of activities of incident response plan Prediction Module
- 50. Proposed Solution (4/4) CREST | University of Adelaide 50 | An interoperability model to select the security tools to automate the execution of sequence of activities in an incident response plan 10/6/2020
- 51. Experiments and Results Preparing the Dataset for Prediction module CREST | University of Adelaide 51 Activity Description Level 1 Level 2 Level 3 Scan endpoint to see whether malware was found Scan ScanEndpoint ScanEndpointMalware Is this a phishing email Validate ValidatePhishing ValidatePhishingEmail Isolate the malicious node from the network Isolate IsolateMalicious IsolateMaliciousNode • 34 categories under level 1 • 67 categories under level 2 • 74 categories under level 3 10/6/2020
- 52. Experiments and Results Implementing the Prediction module CREST | University of Adelaide 52 | 0.926 0.909 0.865 0.93 0.911 0.869 0.833 0.817 0.792 0.918 0.905 0.864 LEVEL 1 LEVEL 2 LEVEL 3 SVM RF NB LR 0.96 0.94 0.9 0.97 0.93 0.87 0.96 0.94 0.9 0.96 0.93 0.88 LEVEL 1 LEVEL 2 LEVEL 3 Accuracy Precision Recall F1-score Validated weighted average of F1-score for optimal configuration of different classifiers, SVM (Support Vector Machine), RF (Random Forest), NB (Naïve Bayes), LR (Linear Regression) Testing results of Random Forest for three levels of class 10/6/2020
- 53. Developing Interoperability Model • Security tools: Snort, Splunk, Limacharlie, Wireshark, Microsoft essential, MISP • 24 different capabilities • Nine Incident response plan with 17 activities CREST | University of Adelaide 53 | Success Rate 90% 10/6/2020
- 54. Research Overview Background State of the art State of the practice Literature Review (CSUR 2019) Engineering Security Orchestration and Automation Solution Functional Requirements Non-Functional Requirements Key Components Security Orchestration and Automation Architecture (ECSA 2020) Realization of the Architecture Interpretation and Interoperability Security Tool Integration Architectural Complexity Encapsulation Semantic Based Integration (CAiSE 2019) Automated Process for Integration (ICSSP, 2019) AI Enabled Declarative API (In Submission) Key Contribution A Novel Layered architecture of SOAR platform Ontology based Integration Process NLP and NL based Integration Framework Declarative API driven SOAR platform How is it possible to automate the process of integrating security tools in a SOAR platform? 10/6/2020 54
- 55. Automated Process for Integration 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 55 |
- 56. Interpretation + Selection + Formulation + Invocation + Execution Auto-integration Process CREST | University of Adelaide 56 |
- 57. Proposed Solution (1/4) • Enable Semantic Interpretability and Interoperability among different Security tools/systems • Formalize diverse activities and capabilities of security system using Ontology CREST | University of Adelaide 57 An Ontology driven Approach to Automate the Process of Integration (OnSOAP) 10/6/2020
- 58. Proposed Solution (2/4) CREST | University of Adelaide 58 | ApplicationLayer SemanticLayer OrchestrationLayer Query Engine Output of Security System Input Constructor Orchestrator Annotated Capability Annotated Artifacts Ontology Security System Collector Output Handler Reasoner Pre-processed Output Editor Extracted Features Execution Command Query Classes Interpreter Incident Response plan 10/6/2020 OnSOAP
- 59. Proposed Solution (3/4) • Process of automating the integration of security systems/ tools performed in four stages: • Interpretation of incident • Identification of activities and functional capabilities required to respond to an incident • Selection of security systems, and • Formulation of command to invoke a security system. CREST | University of Adelaide 59 | Orchestration Layer 10/6/2020
- 60. Proposed Solution (4/4) CREST | University of Adelaide 60 | Orchestration Layer: Automation Process Interpret the Incident Identification of Capability to response an incident 10/6/2020
- 61. Evaluation RQ1: How Effective is OnSOAP’s Process of Automating the Integration of Security Tools/ Systems? RQ2: How Efficient is OnSOAP for Practical Use? CREST | University of Adelaide 61 | Two baseline approach to compare with • BL1: Manual integration • BL2: API based integration process with static interpreter • Developed a set of APIs between security systems to automate the sequence of activities 10/6/2020
- 62. Experiment Design and Setup (1/4) • Gathering input data • Application Environment Setup • Development of the Ontological Model • Development of the Orchestration Layer CREST | University of Adelaide 62 | 10/6/2020
- 63. Three different Security Systems • IDS Snort • SIEM Splunk • EDR LimaCharlie Capabilities of Security Systems • δSplunk = {F2, F3, F4, F9, F10, F11} • δSnort = {F1, F5, F6} • δLimacharlie = {F2, F7, F8, F12} Experiment Design and Setup (2/4) 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 CREST | University of Adelaide 63 https://www.servicenow.com IDS: Intrusion Detection System SIEM: Security Information and Event Management EDR: Endpoint Detection and Response 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 10/6/2020
- 64. Three different Security Systems • IDS Snort • SIEM Splunk • EDR LimaCharlie Capabilities of Security Systems • δ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 Experiment Design and Setup (3/4) CREST | University of Adelaide 64 IDS: Intrusion Detection System SIEM: Security Information and Event Management EDR: Endpoint Detection and Response https://www.servicenow.com 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 10/6/2020
- 65. Three different Security Systems • IDS Snort • SIEM Splunk • EDR LimaCharlie Capabilities of Security Systems • δSplunk = {F2, F3, F4, F9, F10, F11} • δSnort = {F1, F5, F6} • δLimacharlie = {F2, F7, F8, F12} Experiment Design and Setup (4/4) 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 CREST | University of Adelaide 65 | IDS: Intrusion Detection System SIEM: Security Information and Event Management EDR: Endpoint Detection and Response https://www.servicenow.com 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 10/6/2020
- 66. Results (1/2) RQ1: How Effective is OnSOAP’s Process of Automating the Integration of Security Systems? Collect alert logs from Snort Upload the alerts logs into Splunk Identify malicious nodes using Splunk Isolate malicious nodes using Limacharlie CREST | University of Adelaide 66 Incident type Incident response plan (IRP) 𝐼1 DDoS attack 𝑎𝑐2, 𝑎𝑐12, 𝑎𝑐5, 𝑎𝑐3, 𝑎𝑐13, 𝑎𝑐10, 𝑎𝑐7, 𝑎𝑐9 Approach Efforts require BL2 • Different APIs for different functionality (eight APIs for I1) • Different rules to interpret and extract the message of different security systems (Splunk, Limacharlie, Snort) OnSOAP • Similar process to interpret the output of one security systems and formulate the input of other security system The same process can be used to automate a different number of Incident Response Plan with different types of security systems. 10/6/2020
- 67. Results (2/2) RQ2: How Efficient is OnSOAP for Practical Use? Comparison criteria: Amount of efforts for new incidents (I2 and I3) that have new activities, CREST | University of Adelaide 67 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 Approach Effort Required BL2 • Need to select security systems • Developed the APIs • Define rules to automate the process OnSOAP • Define the capabilities of security systems in the ontology to execute the activities Less efforts or changes are required with our proposed approach with the change in Incident Response Plan. 10/6/2020
- 68. Research Overview Background State of the art State of the practice Literature Review (CSUR 2019) Engineering Security Orchestration and Automation Solution Functional Requirements Non-Functional Requirements Key Components Security Orchestration and Automation Architecture (ECSA 2020) Realization of the Architecture Interpretation and Interoperability Security Tool Integration Architectural Complexity Encapsulation Semantic Based Integration (CAiSE 2019) Automated Process for Integration (ICSSP, 2019) AI Enabled Declarative API (In Submission) Key Contribution A Novel Layered architecture of SOAR platform Ontology based Integration Process NLP and NL based Integration Framework Declarative API driven SOAR platform How is it possible to hide the internal complexity of a SOAR platform from the security team? 10/6/2020 68
- 69. AI-Enabled Declarative API Chadni Islam, Muhammad Ali Babar, and Surya Nepal. AI- Enabled Design and Generation of Declarative API for Security Orchestration Platform. In preparation for submission in Journal (JSS, 2020) 69 |
- 70. AI-enabled Declarative API-driven Orchestration, DecOr Knowledge Base Ontology SemOnto Query Engine Security Operation Centre SecurityTools Legend Existing Components Declarative API Proposed Components Modified Components Security Orchestration Platform ExecutionAPI IntegrationAPI Orchestration API SecAPIGen Organisation Infrastructure User Interface 10/6/2020 CREST | University of Adelaide 70
- 71. Key Contributions • A Novel Layered Architecture of SOAR platform • Ontology based integration process • NLP and ML based Integration Framework • Declarative API driven SOAR Platform 10/6/2020 CREST | University of Adelaide 71
- 72. Ongoing Works and Student Projects
- 73. Automated Validation of Security Threat Data • Auto-validation of security alerts using Threat Intelligence: Machine Learning based Approach • Auto-validation of security alerts generated by an Intrusion Detection System • Automated Classification of Security Threat Data, Summer sprint projects of Cyber Security Cooperative Research Centre 10/6/2020 CREST | University of Adelaide 73
- 74. Recommendation System for Security Operation Centre • Automated analysis and recommendation of security incident response plan • Extracting the features of security software from its documentation • Automating Security Data Integration 10/6/2020 CREST | University of Adelaide 74
- 75. Question??? Future Work and Opportunities Chadni Islam CREST, School of Computer Science, University of Adelaide Adelaide, Australia Email: chadni.islam@adelaide.edu.au Website: https://chadniislam.wordpress.com/
Notes de l'éditeur
- The title and abstract covers only one paper but the talk reporting the snapshot of my PhD’s main parts which has been carried in collaboration with Data61 and some collaborative work with CSCRC through smaller projects.
- A security incident is an unwanted or unexpected event/events that have a significant probability of compromising the security of an organization’s assets.
- Lots of reason contribute to this breach - while the dominant reason is considered the phishing or malware, the noticeable part is employees action, even lost of devices are also increasing cyber crimes. More or less every small to medium organization are affected by this including health care, education, government organizations.
- Organizations use a wide variety of security system to protect their information and communication technologies and business applications. Most of these security systems operate indenpendently. A human experts needs to manually integrate and analyze the security events data generated from security centric process (capture traffic data, detect an incident and analyze log) of different software to perform an incident response., Example:
- Example of Activities performed by a wide variety of security systems
- 750 incident BakerHostetler’s privacy and data protection team released its 2019 Data Security Incident Response Report, which leverages the metrics and insights drawn from 750 potential incidents in 2018 to help entities identify and prioritize the measures necessary to address their digital risk posture.
- " Every minute, we are seeing about half a million attack attempt that are happening in cyber space."-Derek Manky, Fortinet global security strategist At the end of each year, ESG conducts a wide-ranging global survey of IT professionals, asking them about challenges, purchasing plans, strategies, etc. As part of this survey, respondents were asked to identify areas where their organization has a problematic shortage of skills. Report 2018 – participants more than 2300 Report 2019 – participant more than 1500
- The proliferation of security solutions and increase in volume, velocity and cyber attacks have pushed the horizon of cyber security towards security orchestration. Security orchestration calls for connecting multivendor security tools to work as a unified whole, that will instantly perform the repetitive job of a security experts. Organization are shifting toward security orchestration platform. A pre-requisite of security automaton. Phantom, Desmito, Komand, Swimlane, IBM resilience FireEye via its invotas acquisition Microsoft plans to buy Hexadite in the security orchestration space
- Change in the underling execution environment, 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.
- 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
- A security orchestration platform aims to minimize the dependency on human experts for a streamlined incident response processs.
- However, most of the existing security orchestration platform cannot automatically adapt to organizational systems' operational processes such as installation of new software, deployment of new servers and rolling out new access control policies. Security team/ staffs needs to manually integrate different security systems with a Security orchestration platform and map their activities into a incident response process.
- 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.
- 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.
- 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.
- 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.
- 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.
- How is it possible to automate the process of integrating security tools in a SOAR platform? How is it possible to hid the internal complexity of a SOAR platform from the security team?
- How is it possible to hid the internal complexity of a SOAR platform from the security team?
- The integration process is a combination of interpretation, selection formulation and invocation.
- Human intervention can be minimized by providing security orchestration platform a formal specification of the security data format, configuration and structural specification of security system to automate the process of integrating different security system
- Our proposed system comprises of three layer. Application layer: Security System, Semantic Layer: Ontology, Orchestration Layer: IRP The application layer provides fine grained information about security system, running processes and current state of an organizations The orchestration layer responsible for invoking appropriate tasks for automating the process of integration of several security system based on the activities of the IRP The semantic layer provides the semantic details about the input, output and activities performed by security system to the orchestration layer. It leverages the ontologies capabilities to represent multi-sourced data taking into account the semantic integration process among heterogeneous data produced by different security system. The semantic layer deploys a Query engine to extract the necessary features from the ontology. The Query engine is responsible for communicating with our ontology. It queries the ontology based on the requirement of the Interpreter . We designed a set of queries for OnSOAP to retrieve the necessary information from the ontology. Our proposed OnSOAP has a Reasoner that uses rule-based reasoning to derive semantic correlation among the activities, security system and capabilities. We have defined various rules within the ontology to provide inferred information and some constraints for error-free integration . These rules help OnSOAP to avoid ambiguity while creating an instance of classes. Based on the rule-based reasoning of the ontology, the Reasoner provides the inferred information The application layer also provides support to integrate the knowledge in the ontology through an ontology Editor. The ontology Editor is deployed in the application layer to create, update and modify the ontology classes. At this stage, we consider a security staff will update the ontology’s details. The orchestrator of the orchestration layer controls the integration process. In the application layer a collector collect the artefacts generated by different security system and assets. These artefacts are forwarded to the lower layer which then extracts the feature from a log. . Raw data are passes through the orchestration layer that applies pre-processing rules to map the raw event onto the classes of the developed ontology (e.g., maps the alerts log to the IDS that generated it) The output handler of orchestration layer receives the output of a security system from the Collector. Upon receiving the alert event, it sends the output (i.e., alert log produced by 𝑠𝑖 Snort) to the Interpreter to interpret the incident type I. Upon receiving the incident, the orchestrator looks for the possible IRP in the incident response playbook. Assuming 𝑖𝑟𝑝𝑘 = {𝑎𝑐1,𝑎𝑐2,𝑎𝑐3} is the IRP for incident I, the Orchestrator extracts the list of activities from 𝑖𝑟𝑝 and invokes the interpreter to identify the functional capability required to perform an incident response against an incident. For each activity, the Interpreter invokes the query engine to run query that returns the functional capability required to execute an activity and send to the Orchestrator The output produced by different security systems and the annotated output of the semantic layer are passed to the orchestration layer. A security orchestration platform executes an orchestration routine to call individual security system to execute an activity. Execution of activities generate artifacts, i.e., system log and alert log. Artifacts are also required before executing the activities
- We describes the process of automating the integration of security systems performed in orchestration layer in four stages: (i) interpretation of incident, (ii) identification of activities and functional capabilities required to respond to an incident (iii) selection of security systems, and (iv) formulation of command to invoke a security system.
- We used two baseline approaches to perform comparative analysis: manual integration process (BL1) and API based integration process with a static interpreter (BL2). In BL1, the response process depends on a human. The security staff performed the tasks using the security system. For example, during the monitoring process, if security staff found alerts, they looked in the playbook for the response actions or used previous experience to investigate the alerts. In BL2 solution, we developed a set of APIs between security systems to automate the sequence of activities. This process needed pre-developed APIs in both directions for each security system, i.e., API to send data from Splunk to Limacharlie, from Snort to Splunk and Limacharlie to Splunk as well. The goal of these APIs was to capture the essential expected capabilities of each security system that allowed the implementation of the interface by any that kinds of security systems. We developed a static interpreter along with output handler to automate response for DDoS attack of Table.
- we describe the experimental setup used for demonstrating and evaluating OnSOAP’s ability to automate the process of integrating various security systems. We have developed the required components based on proposed system.
- We gathered a list of activities and identified the functional capabilities required to execute these activities. The Table shows the part of the activities gathered. The activities were extracted from the IRP for different types of attacks. To set up the application environment, we chose three different types of security systems, Snort as IDS, Splunk as SIEM and Limacharlie as EDR that have the capabilities to execute the activities. Among these security systems, Snort and Limacharlie are open source security systems where Splunk is a commercial one. We used the free trial of Splunk enterprise version due to its wide range of functional capability. We mapped the functional capability of security systems with TABLE II, which gave δSplunk = {F2, F3, F4, F9, F10, F11}, δSnort= {F1, F5, F6} and δLimacharlie = {F2, F7, F8, F12}. Both Limacharlie and Splunk can perform other activities that are not listed here. We used a centralized directory to collect alerts logs produced by Snort, the event and process log sent by a Limacharlie sensor to a Limacharlie cloud and gathered the reports generated by Splunk. We installed Snort and Limacharlie sensor application on the local host. Limachairlie cloud server and Splunk server application were deployed on a virtual machine. We also defined the detection and response rules for Limacharlie and Splunk.
- We can see list of activities for DDoS attacks. Lets focus on the first two activities. ac2 and ac12 which are basically collect alert log and investigate the collected alerts. Here we can see the investigation are run on the alert collected on the previous steps. Now lets see what are the functional capability required for this. both of these activities can be executed by SPlunk
- Now focusing on the next two activities ac5 and ac3, we got the functional capabilities that are of two different security system Splunk and Snort. To execute the activity ac3 that is identify affected system splunk needs the output of the Snort (sniff network packet) as its input. Execution of these sequence of activities require OnSOAP to know the output details of Snort and also the input command details of Splunk
- Motivation: Investigate whether the combination of semantic integration and orchestration results better automate process. RQ1 answers how effective is onSOAP in making security systems interoperable where one system can directly use the output of another system as its input Also investigate whether or not the system interpret the output of a security system to formulate the input of another security system with different capabilities Considering all three approaches use the same IRP, for each alert the security staff first searched for the alert types and then looked for the possible list of actions and based on the list performed the actions. For the standard case, the staff used their previous experience to select security system to perform each activity. For example to perform the activities 𝑎𝑐2 and 𝑎𝑐12 that are collect and investigate alerts logs the security staff collected the alerts generated by Snort, and then uploaded those alerts to Splunk. For this, the experts manually needed to log in to Splunk and upload the alert logs and then defined the rules to investigate alerts. In case the same types of alerts were seen next, security staff needed to go through the same manual process again. The expert also needed to read the reports generated by Splunk and then sent the commands to Limacharlie to isolate the affected nodes. For similar types of alerts, the manual process requires staff to repeat the same sequence of actions, that require huge amount of man-hours and also delays the response process. The BL2 also required to define the APIs for each function before the execution of an IRP. For example, execution of I1 required to design eight different APIs , even though the number of the security systems were three. With OnSOAP, once Snort generated the alerts, the Interpreter automatically identified that the incident as DDoS attack and triggered the incident response process. OnSOAP chose the security system based on their functional capabilities. It gathered the list of the security systems that can perform the activities in the IRP for incident I1. The input command syntax has the command needed by the security systems to run the security software. The commandSyntax has the sequence of the parameters to formulate the commands. Retrieving this information, OnSOAP successfully generated the scripts to run Snort, Splunk and Limacharlie in a different mode.
- During the ontology development process, OnSOAP needs a domain expert to design the classes of security system capabilities. Developing the ontology requires a substantial understanding of security systems being used. Another time-consuming process is designing the incident response plan and orchestration process. If OnSOAP cannot alleviate challenges related to the manual integration process, and substantial efforts needed to build the ontology, the security experts may not be willing to use it in practice. We Introduce new incident I2 and I3 which includes a list of activities. Among these activities some activities were excluded during incident I1 and some are new (the red mark) For new activities we compare the amount of effort requires for OnSOAP in term of the information an experts needed to include in the ontology and the efforts of BL2 in terms of the number of new APIs needed to design. For all the three incidents, the security staff required a substantial understanding of security systems. Also for both BL2 and OnSOAP, the IRP and the automation processes needed to be defined. For BL2, the security staff needed to select security systems, developed the APIs accordingly, and then define the rules to automate the process. For OnSOAP, the staff only need to define the capabilities of security systems to execute those activities. For the already defined capabilities, we do not need to do any further actions. The same integration process of extracting incidents, selecting security systems, interpreting output and formulating input works for executing the IRP for I2 and I3. The evaluation shows that little effort or changes are required in OnSOAP with the change in IRP. For all the three incidents, the security staff required a substantial understanding of security systems. Also for both BL2 and OnSOAP, the IRP and the automation processes needed to be defined. For BL2, the security staff needed to select security systems, developed the APIs accordingly, and then define the rules to automate the process. For OnSOAP, the staff only need to define the capabilities of security systems to execute those activities. For the already defined capabilities, we do not need to do any further actions. The same integration process of extracting incidents, selecting security systems, interpreting output and formulating input works for executing the IRP for I2 and I3. The evaluation shows that little effort or changes are required in OnSOAP with the change in IRP.
- Auto-validation of security alerts using Threat Intelligence: Machine Learning based Approach, Topics in Computer Science, Semester 2, 2019 (co-supervised with Professor M. Ali Babar). Page 3 of 3 • Advanced Topics of Computer Science project, Semester 1, 2019 (co-supervised with Professor M. Ali Babar). • Extracting the features of security software from its documentation, Master of Computing & Innovation Project, Semester 1, 2019. (co-supervised with Professor M. Ali Babar). • Auto-validation of security alerts generated by an Intrusion Detection System, Master of Computing & Innovation Project, Semester 1, 2019 (co-supervised with Professor M. Ali Babar). • Automated Classification of Security Threat Data, Summer sprint projects of Cyber Security Cooperative Research Centre, December 2018 – February 2019 (externally-supervised with Professor M. Ali Babar). • Automating Security Data Integration, Summer sprint projects of Cyber Security Cooperative Research Centre, December 2018 – February 2019 (external supervisor with Professor M. Ali Babar). • Security as a Service - Classifying Threat Intelligence, Software Engineering Research Project, Semester 2, 2018 (co-Supervised with Professor M. Ali Babar). • MidSOC – A middleware for cybersecurity data fusion, Software Engineering Research Project, Semester 2, 2018 (co-supervised with Professor M. Ali Babar).