Hold
| On hold. For example the event data source is not in Azure Sentinel, an end system configuration or policy change is required or the use case is causing too many false positives and cannot be tuned sufficiently at this time. |\r\n|Dev
| In development by content author. No Incident stage annotation or annotated as 'Development'. No SOC action. |\r\n|Test
| Being soak tested. Alerts/Events annotated/tagged for \"Testing\". Allows confirmation that Analytic use case is not overly noisy, Use Case and IR procedure are to be updated within the SocRA Watchlist. Ops Lead / Senior Analyst can review Alerts/Events. |\r\n|Approved
| Currently in test but approved for production and awaiting the move to be Incident Enabled. |\r\n|Prod
| In production. Alerts/Events added to Incident and annotated/tagged for \"Triage\". Subject to metrics. SOC Analysts are to respond to Incidents. |\r\n\r\nAZURE SENTINEL Analytics/Detection(s) On-board Tracking Table\r\n \r\nThis is the Use-case/Detection Matrix that lists out all of our Out-Of-The-Box detections, mapping them back to Corresponding Data Sources as well as to MITRE ATT&CK Tactics:\r\n \r\n| \t| NAME | RULE TYPE | DATA SOURCES | MITRE TACTICS |\r\n| : | : | : | : | : |\r\n|1
\t| Advanced Multistage Attack Detection | Fusion\t| Persistence, Lateral Movement, Exfiltration, Command and Control | |\r\n|2
\t| Create incidents based on Microsoft Defender Advanced Threat Protection alerts | Microsoft Security | Microsoft Defender Advanced Threat Protection (Preview) | |\r\n|3
\t| Create incidents based on Microsoft Cloud App Security alerts | Microsoft Security | Microsoft Cloud App Security | |\r\n|4
| Create incidents based on Azure Security Center for IoT alerts | Microsoft Security |\tAzure Security Center for IoT | |\r\n|5
\t| Create incidents based on Azure Security Center alerts | Microsoft Security | Azure Security Center | |\r\n|6
\t| Create incidents based on Azure Advanced Threat Protection alerts | Microsoft Security | Azure Advanced Threat Protection | |\r\n|7
\t| Create incidents based on Azure Active Directory Identity Protection alerts | Microsoft Security | Azure Active Directory Identity Protection | | \r\n|8
\t| (Preview) Anomalous SSH Login Detection | ML Behavior Analytics | Syslog | Initial Access |\r\n|9
\t| User account created and deleted within 10 mins | Scheduled | Security Events\t| Persistence, Privilege Escalation |\r\n|10
| User account added to built-in domain local or global group | Scheduled | Security Events | Persistence, Privilege Escalation |\r\n|11
| Time series anomaly for data size transferred to public internet | Scheduled\t| Cisco ASA +2 | Exfiltration |\r\n|12
| Time series anomaly detection for total volume of traffic | Scheduled | Barracuda Web Application Firewall +6\t| Exfiltration |\r\n|13
| THALLIUM domains included in DCU takedown | Scheduled | DNS (Preview) +3 | Command and Control, Credential Access |\r\n|14
| Suspicious Resource deployment | Scheduled | Azure Activity | Impact |\r\n|15
| Suspicious number of resource creation or deployment activities | Scheduled |Azure Activity | Impact |\r\n|16
| Suspicious granting of permissions to an account | Scheduled | Azure Activity | Persistence, Privilege Escalation |\r\n|17
| Successful logon from IP and failure from a different IP\t| Scheduled | Azure Active Directory | Credential Access, Initial Access |\r\n|18
| SSH Potential Brute Force | Scheduled | Syslog | Credential Access |\r\n|19
| SSH newly internet-exposed endpoints | Scheduled | Syslog | Initial Access |\r\n|20
| Squid proxy events related to mining pools | Scheduled | Syslog | Execution, Impact |\r\n|21
| Squid proxy events for ToR proxies | Scheduled | Syslog | Command and Control |\r\n|22
| Sign-ins from IPs that attempt sign-ins to disabled accounts\t| Scheduled | Azure Active Directory | Initial Access, Persistence |\r\n|23
| SharePointFileOperation via previously unseen IPs | Scheduled | Office 365 | Exfiltration |\r\n|24
| SharePointFileOperation via devices with previously unseen user agents | Scheduled | Office 365 | Exfiltration |\r\n|25
| Sensitive Azure Key Vault operations | Scheduled | Microsoft web application firewall (WAF) | Impact |\r\n|26
| Security Event log cleared | Scheduled | Security Events | Defense Evasion |\r\n|27
| RDP Nesting | Scheduled | Security Events | Lateral Movement |\r\n|28
| Rare subscription-level operations in Azure | Scheduled | Azure Activity | Credential Access, Persistence |\r\n|29
| Rare RDP Connections | Scheduled\t| Security Events | Lateral Movement |\r\n|30
| Rare high reverse DNS count | Scheduled | DNS | Discovery |\r\n|31
| Rare high NXDomain count | Scheduled | DNS | Command and Control |\r\n|32
| Rare application consent | Scheduled | Azure Active Directory | Persistence, Lateral Movement, Collection |\r\n|33
| Rare and potentially high-risk Office operations | Scheduled | Office 365 | Persistence, Collection |\r\n|34
| Process execution frequency anomaly | Scheduled | Security Events | Execution |\r\n|35
| Process executed from binary hidden in Base64 encoded file | Scheduled | Security Events | Execution, Defense Evasion |\r\n|36
| Powershell Empire cmdlets seen in command line | Scheduled | Security Events | Execution, Persistence |\r\n|37
| Potential Kerberoasting | Scheduled | Security Events | Credential Access |\r\n|38
| Palo Alto - potential beaconing detected\t| Scheduled | Palo Alto Networks | Command and Control |\r\n|39
| Palo Alto - possible internal to external port scanning | Scheduled | Palo Alto Networks\t| Discovery |\r\n|40
| Office policy tampering | Scheduled | Office 365 | Persistence, Defense Evasion |\r\n\r\n\r\n## Process Owner\r\nSOC Manager" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "SOC Use Cases" }, "name": "SOC Use Cases Text" } ] }, "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "SOC Analytical Processes & Procedures" }, "customWidth": "75", "name": "SOC Analytical Processes & Procedures Group" }, { "type": 12, "content": { "version": "NotebookGroup/1.0", "groupType": "editable", "items": [ { "type": 1, "content": { "json": "# SOC Business Process & Procedures\r\n\r\n| Processes Name | Procedures | References |\r\n| : | : | : |\r\n| Business Measurement Process (Metrics)| | |\t \t\r\n| | SOC Efficiency Metrics | Primarily intended to monitor SOC key performance indicators. Used to manage the efficiency and effectiveness of the Incident/Alert Traige Processes | \r\n| | SOC Analytics Metrics | Primarily intended to monitor tactical SOC activity. Daily view into events to identify any suspicious activity, active threats, or system health issues |\r\n| Process Improvement | | |\r\n| | Process Maturity | Processes detailing the steps involved in improving the maturity of the SOC |\r\n| | Agile Methodology | Procedures for improving Agile Methodologies |\r\n| | Documentation Standards | Outlining the standards for documentation |\r\n| Compliance Process | | | \t \t \r\n| | Compliance Support | Procedures that provide methods for the SOC in order to adhere to IT security policies & Requirements for the compliance teams to attain the required audit/logging and event notification controls|\r\n| Business Continuity Process | | |\t\r\n| | Business Continuity & Disaster Recovery Plans | Official documentation for business continuity and disaster recovery |" }, "customWidth": "75", "name": "SOC Business Process & Procedures Matrix" }, { "type": 11, "content": { "version": "LinkItem/1.0", "style": "list", "links": [ { "id": "5f0518c7-b62c-4caa-82f6-529880f370d3", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Business Measurement Process (Metrics)", "subTarget": "Business Measurement Process (Metrics)", "style": "primary" }, { "id": "55b434e5-ada1-4fe9-a90d-04c1c657f6ae", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "SOC Efficiency Metrics", "subTarget": "SOC Efficiency Metrics", "style": "secondary" }, { "id": "3c7b0cdb-7321-4910-870b-449078fc3202", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "SOC Analytics Efficiency Metrics", "subTarget": "SOC Analytics Efficiency Metrics", "style": "secondary" }, { "id": "1f277aee-0913-4c83-bf54-1ba322a8b0e2", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Process Improvement", "subTarget": "Process Improvement", "style": "primary" }, { "id": "06caa1a1-f5b3-496b-b542-b8987ebb7057", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Process Maturity", "subTarget": "Process Maturity", "style": "secondary" }, { "id": "83b7086b-3da3-4405-93a7-63aa57dede70", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Agile Methodology", "subTarget": "Agile Methodology", "style": "secondary" }, { "id": "4e1a34ea-4ba0-4413-bd43-d914c32dd3b5", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Documentation Standards", "subTarget": "Documentation Standards", "style": "secondary" }, { "id": "7306c20a-fd48-46cf-bf10-21571dfa2ff5", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Compliance Process", "subTarget": "Compliance Process", "style": "primary" }, { "id": "529939ce-402a-4c51-a2a1-99e621e95ea5", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Compliance Support", "subTarget": "Compliance Support", "style": "secondary" }, { "id": "46eeb3ad-e97f-48bc-a2aa-99c29983059f", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Business Continuity Process", "subTarget": "Business Continuity Process", "style": "primary" }, { "id": "ccda361b-fa8f-4732-a620-fe10068729c2", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Business Continuity & Disaster Recovery Plans", "subTarget": "Business Continuity & Disaster Recovery Plans", "style": "secondary" } ] }, "customWidth": "25", "name": "SOC Business Process & Procedures Tabs", "styleSettings": { "margin": "20", "padding": "20" } }, { "type": 1, "content": { "json": "# Business Measurement Process (Metrics)\r\n\r\n## Purpose \r\nThe purpose of this document is to define recommended metrics for the newly developing Security Operations Center (SOC) at CUSTOMER. These metrics will be used to learn the effectiveness and efficiency of the SOC and will provide tangible documented results that will reveal areas that may require improvement, or areas that are meeting or exceeding goals, objectives and expectations. \r\n\r\nThe goal of the CUSTOMER SOC Metrics Program is at any given time to communicate to stakeholders the current security posture of the SOC. This is accomplished with clearly defined objectives, identified stakeholders and/or audiences, and measurable task and processes. It is also intended to provide insight into general threat and vulnerability trends across the CUSTOMER's enterprise. \r\n\r\n## Scope \r\nThe scope for this Metrics Program is to measure (4) categories defined as Security Awareness, Effectiveness & Efficiency, Technology and Skills & Capabilities. Security Awareness metrics consist of those measurements that are derived from security systems such as Intrusion Detection Systems, suspicious network communication, endpoint security events, etc. These metrics will expose the threat landscape and possibly identify gaps of coverage within the infrastructure. These gaps may be ineffective or lacking processes, technology limitations or unavailable skill sets.\r\n\r\nEffectiveness and Efficiency metrics are those measurements that are derived from day to day task such as number of events annotated, number of cases opened, false positive events, etc. These metrics will identify the SOC’s return on investment (ROI) as well as detect what processes are performing as expected and meeting defined targets, and what processes are creating workflow difficulties. Such difficulties may be the result of ineffective or lacking processes, technology limitations or unavailable skill sets.\r\n\r\nTechnology metrics are those measurements that provide insight to the security infrastructure, such as the total number of monitored devices, total number of raw events, system health events, etc. These metrics define and visualize the volume and scope of monitoring and can identify data choke points, the need to upgrade or modify architecture, reveal onboarding challenges and in conjunction with Effectiveness and Efficiency metrics, predict the probability of man power shortage. These events are outside of the control or direct influence of the analyst.\r\n\r\nSkills and Capabilities metrics are those metrics that identify the SOC team’s strengths and weaknesses as defined by the SOC prioritized proficiency targets and roles and responsibilities. Proficiency targets are various levels of competencies within a skill discipline that are defined by SOC management. Skill disciplines range from IDS skills, Firewall skills, Communication skills, etc. These metrics are used to define educational opportunities, may define career development or increase/decrease the SOC’s vision into the enterprise network infrastructure. \r\n\r\nThe technical scope of this process is limited to discrete data and information that can be collected, analyzed and reported on within Azure Sentinel or other operational support tools in use by the CUSTOMER's SOC. \r\n\r\n## Process Summary \r\nThe SOC Manager and SOC Operations Lead will work with business and security teams to identify requirements, and the Lead Engineer will implement appropriate measurement to support SOC Operations. Business measurement in the SOC will leverage Azure Sentinel and its periodic reporting capabilities. Once a business requirement has been defined, the data sources to be measured will be identified, and the resulting Azure Sentinel content (KQL Queries, Watch Lists, Workbooks, Trends, and Spreadsheets) will be developed. All collected measurements will be reviewed periodically as defined in the Process Improvement Process, as well as by each individual process. \r\n\r\nThere are three main categories of SOC business measurement; Monthly, Weekly and Daily. These three make up the primary subordinate procedures to this process. These are all Key Performance Indicators (KPIs) which are metrics of process effectiveness. A good example of a SOC KPI is calculating the number of Incidents per analyst/hour (IPAH). \r\n\r\nThere are also Executive Summary metrics which are for upward reporting. These are generated on a monthly basis and used by the SOC management to give executive visibility into the types of cases the SOC is dealing with and the workload it is under.\r\n\r\n## Metrics Definition Process \r\n- Define business questions to answer (requirements). \r\n\t○ These will be documented and tracked in an appendix to the metrics procedure. \r\n\t○ These will be identified and called-out in each of the documented SOC processes as required. \r\n- Identify the data sources needed to answer the requirement. \r\n- Analyze the data \r\n- Develop appropriate content to capture the data \r\n- Review metrics content within an appropriate time frame, as documented in each process. \r\n- Incorporate identified improvements. \r\n\r\n## Metrics \r\n- See Subordinate Procedures \r\n\r\n## Roles & Responsibilities \r\n- SOC Manager is responsible for the overall success of this process. The SOC manager ensures that the technology and training is available to support the collection of any data needed for effective business measurement. \r\n- Lead Engineer will take the measurement requirements established by the subordinate procedures and implement them with the Azure Sentinel environment to support the overall business measurement process. \r\n- SOC Lead will work with the SOC Manager to define and document the information requirements and then work with the Azure Sentinel Engineer to solution those requirements with Azure Sentinel Analytic/WatchList/Workbook/Playbook/Notebook content. \r\n- Business Requirement Owner defines a metrics requirement to be satisfied within the Azure Sentinel solution and will be responsible to ensure the resulting content is reviewed and leveraged as needed. \r\n\r\n## Process Linkages \r\n- Subordinate Procedures \r\n\t- Monthly Metrics \r\n\t- Weekly Metrics \r\n\t- Daily Metrics\r\n\t- Executive Metrics\r\n\t\t\r\n## Related Process & Procedures \r\n- Process Improvement \r\n- Reporting Process \r\n\r\n## Process Owner \r\n SOC Manager" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Business Measurement Process (Metrics)" }, "name": "Business Measurement Process (Metrics) Body" }, { "type": 1, "content": { "json": "# Process Improvement\r\n\r\n## Purpose \r\nThe purpose of this document is to provide the framework for the [CUSTOMER] Security Operations Center (SOC) Process Improvement program. This process will include a list of procedures associated with the continuous process improvement program; these will leverage the Carnegie Mellon Software Engineering Institute Capability Maturity Model for Integration (CMMI). The business goal is to enable the on-going assessment of SOC operations and provide feedback to improve service capability over time. \r\n\r\n## Scope \r\nThis process applies to all process and procedures implemented in the [CUSTOMER] SOC. This process supports the assessment of the current state, suggests improvement areas and specific actions to improve service capabilities. The scope of this process is strictly limited to the [CUSTOMER] SOC. \r\n\r\n## Process Summary \r\nThe SOC Manager and the SOC Operations Lead evaluate the maturity and effectiveness of SOC process and procedure on a biannual basis. They use this information to improve SOC service delivery effectiveness. A continuous improvement process will enable the SOC's service delivery to be consistent, predictable, and on a path of continuous improvement. This is important in the field of security operations to guarantee a standardized, repeatable and high quality-of-service in recognizing and responding to critical information security events. \r\n\r\nThe Process Maturity Procedures will document the detailed steps for continuous process improvements. Given the rapid rate of change in the field of information security, this process will also be supported by an Agile Methodology Procedures to ensure that the SOC can effectively respond to new and emerging information security attacks with iterative and rapidly evolving process and procedures. The Agility procedure will also allow the SOC to become operationally effective much faster than traditional waterfall development methodologies. The Documentation Procedures will establish the methodology for drafting and maintaining appropriate documentation to support maturity and agility objectives. \r\n\r\n- Perform initial assessment \r\n- Score assessment, report maturity level and findings \r\n- Identify service maturity goals \r\n- Create action plans to achieve goals \r\n- Execute service improvements \r\n\t\r\nThe [CUSTOMER] SOC will measure process maturity by using the Carnegie Mellon Software Engineering Institute's Capability Maturity Model for Integration. The CMMI is defined to contain the following levels: \r\n\r\n| CMMI LEVEL |\r\n| : | : |\r\n| Level 1 | Ad hoc (Chaotic) |\r\n| Level 2 | Repeatable |\r\n| Level 3 | Defined |\r\n| Level 4 | Managed |\r\n| Level 5 | Optimized |\r\n\r\nThe targeted maturity level for the [CUSTOMER] SOC is Level-3 (Defined): It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. \r\n\r\n## Metrics \r\n- Process Maturity Assessment Results (CMMI) \r\n\r\n## Roles & Responsibilities \r\n- SOC Manager is responsible for the overall success of this process. The SOC manager ensures that the emphasis, technology, training, and budget are available to support the continuous improvement goals. The SOC Manager sets the maturity objectives. \r\n- SOC Operations Lead is responsible to work with the SOC Manager to define action plans, prioritize action plans, track progress, review, and evaluate action plan effectiveness. \r\n- SOC Analyst is responsible to execute action plans to support continuous improvement. \r\n\r\n## Process Linkages \r\n- Subordinate Procedures \r\n\t- Process Maturity \r\n\t- Agile Methodology \r\n\t- Documentation Standards \r\n- Related Process & Procedures \r\n\t- Business Measurement Process (Metrics) \r\n\r\n## Process Owner\r\n SOC Manager" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Process Improvement" }, "name": "Process Improvement Body" }, { "type": 1, "content": { "json": "# Process Maturity\r\n\r\n## Description \r\nThe purpose of this procedure is to detail the steps necessary for process maturity as outlined in Process Improvement Process. The goal of this procedure is to provide the [CUSTOMER] Security Operations Center (SOC) with a continuous process improvement program that adheres to the Carnegie Mellon, Software Engineering Institute, Capability Maturity Model (SEI/CMM) Level-3. This procedure should be performed periodically (as needed) and all processes should be reviewed every 180 days. \r\nThe next scheduled appraisal is planned for: MMM DD, YYYY. \r\n\r\n### Step 1 - Perform Assessments \r\n#### Score Maturity \r\nThe SOC Appraisals will use the Standard CMMI Appraisal Method for Process Improvement (SCAMPI). Method C will be used for internal appraisals, the SOC leadership team will organize the assessment and an employee external to the SOC [CUSTOMER] will conduct the on-site portions of the assessment.\r\n\t\r\n#### Appraisal Method \r\n##### Planning Phase \r\nThe purpose of the planning phase is to review the appraisal methodology (this document) as well as to prepare the logistical aspects for the on-site phase of the appraisal.\r\n- Scope Appraisal - While the scope of appraisals will not change from one appraisal to the next, (scope encompasses the entire SOC), a review of any specific goals, specific deadlines, or results reporting changes should be discussed during this step. Any additional decisions to be made by the SOC sponsors and SOC leadership should be made during this phase as to not impact the appraisal process.\r\n- Plan Appraisal - Plan appraisal involves development of the appraisal plan, establishing the availability of planned interviewees during the on-site period, planning the logistic requirements of the appraisal (meeting rooms, support staff availability, etc.), establishing the roles of appraisal team members, and verifying the appraisal schedule with all affected parties. It also involves verifying who will receive data upon appraisal conclusion.\r\n\t\r\n##### Preparation Phase \r\nThe purpose of the preparation phase is to prepare the appraisal team for the on-site activities and conduct a preliminary gathering and analysis of data through the Appraisal Record Matrix (*ARM*).\r\n- Prepare - Prepare appraisal team involves reviewing the details of the appraisal with the team. The facilitator reviews with the team the SEI-CMMI and appraisal method, appraisal plan, schedule, information regarding the SOC, wiki evidence, goals for the organization, and any additional parameters. Specific responsibilities for each team member are assigned.\r\n- Analyze Evidence - The appraisal team analyzes the data gathered in the Appraisal Record Matrix (*ARM*) and determines areas for practice validation, identifies potential discrepancies in responses, and performs a gap analysis against the SEI-CMMI. This process element results in a set of exploratory questions and anticipated responses for use during the project lead interviews (conducted by an assessor external to the SOC). Anticipated responses will be derived from the ARM and used to correlate the interview responses with OneNote procedures and documentation during the onsite phase.\r\n\t\r\n##### Onsite Phase \r\nThe purpose of the onsite phase is to explore the results of the preliminary data analysis, and provide an opportunity for practitioners at the appraised entity to participate in the data gathering and validation process.\r\n\t\r\n- Interview Practitioners - The interview portion of the appraisal begins with an introductory session with the appraisal participants to review the appraisal process and affirm SOC commitment to the appraisal. Next, the session facilitator introduces the team, explains the purpose of the session, and asks each practitioner the exploratory questions. All referenced documents should be contained on the framework. There is a separate session for each practitioner. This interview typically provides corroborating and clarifying data in relation to the evidence collected (recorded in the Appraisal Record Matrix (*ARM*)).\r\n- Analyze Data Tracking Sheet & Develop Preliminary Findings - The appraisal team analyzes the evidence and consolidates the data tracking sheet. The voting members systematically analyze the data from all sources to generate a list of preliminary findings related to the process areas and capability levels under investigation. Finally, this data consolidation step allows the appraisal team to determine any needed changes in the schedule or outstanding elements of the data gathering process.\r\n- Compile Findings - Develop final findings involves analyzing the preliminary findings and ARM in light of the contents of the capability levels, determining the estimated process capability for each process area investigated, and consolidating the preliminary findings for presentation to the sponsor.\r\n\t\r\n##### Reporting Phase \r\nThe reporting phase is the concluding phase of the appraisal process in which the team performs its final analysis of all data gathered during the previous three phases and presents its findings to the sponsor.\r\n\t\r\n- Finalize Scoring & Report Outcomes - Finalize scoring involves synthesizing the Appraisal Record Matrix (*ARM*) into a rating profile. The team reviews notes and achieves consensus on the capability level for each process area. The findings developed during the onsite phase and analysis of the SOC, are presented and explained to the sponsor by the appraisal team.\r\n- Manage Appraisal Records - Managing appraisal records involves the proper disposal of all materials gathered and created during the appraisal. Most intermediate work products and inputs will be destroyed while the final ARM, findings, and final report are sent to the sponsor.\r\n- Review Results & Report Lessons - Report lessons learned involves synthesizing information about what did and did not work during the appraisal and suggestions for improvement. This step will also incorporate a review of the appraisal results to determine faults in process and potential areas of improvement.\r\n\t\r\n#### Business Process Metrics \r\n- Business Measurement Process (Metrics) - Defines the maturity and process performance measurements. \r\n\t\r\n#### Appraisal Timeline \r\n- The following is the Appraisal Timeline:\r\n\r\n\r\n### Step 2 - Create Action Plan \r\nWithin two weeks of the appraisal, an action plan will be created to address the results of the appraisal. The steps below can be used to create this action plan: \r\n- Determine steps needed to address the appraisal results \r\n\t- Interview and observe analysts to validate the as-is conditions. \r\n\t- Brainstorm ideas for improvement, include SOC Analysts and management. \r\n\t- Document improvement plan (evidence of maturity) \r\n\t- Knowledge Base revisions to document the changes implemented for the improvement process. \r\n\r\n### Step 3 - Execute Improvements \r\nOn the timeline defined by the action plan, improvements will be made to address the results of the appraisal. \r\n- Update process documentation in knowledge base \r\n\t- Document changes in the appropriate knowledge base page utilizing the Documentation Procedures. \r\n\t- Communicate changes to stakeholders (SOC Analysts and Management) \r\n\t- Nightly automated knowledge base change e-mails will notify all shifts of the change. \r\n\t- SOC Analyst verbal communication is to be used to reinforce the process changes made in the knowledge base. \r\n\t- Track progress of change implementation, update knowledge base as necessary. \r\n\t- Ensure successful completion by process and procedure review." }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Process Maturity" }, "name": "Process Maturity Body" }, { "type": 1, "content": { "json": "# Documentation Standard Procedures\r\n\r\n## Description\r\nThis procedure illustrates the process for creating or updating process and procedure documentation on the SOC Knowledge Base. All SOC procedures are maintained within the Knowledge Base; procedure modifications and version control are also handled through the Knowledge Base. The Knowledge Base contains links to other Knowledge Base sections that house Main, Analytical, Operational, Technology, SOC Shift Logs, Tools and Resources, and other SOC related information. \r\n\r\n## Documentation Procedures\r\nThe following procedure describes how to make updates and changes to the SOC Process Framwork Workbook within Azure Sentinel. A flowchart illustration of this process is also available below. \r\n1. Login to Azure Sentinel through the Azure Portal. https://portal.azure.com/ \r\n2. Navigate to the SOC Process Framework Workbook and click \"View Saved Workbook\"\r\n3. Click \"Edit\" to open the workbook in Edit Mode. \r\n\t1. Does desired topic exist? \r\n\t\t- If NO, \r\n\t\t\t1. Create a New Procedure Page using the +Add to add a new Text Page.\r\n\t\t\t2. Use an appropriate and descriptive Title Header as the Topic Name.\r\n\t\t\t3. Set Topic Parent to appropriate Topic Parent - This is a link or Tab on the Main Topic Menue.\r\n\t\t\t4. Skip to Update procedure documentation step \r\n\t3. Select Procedure \r\n\t4. Update procedure documentation \r\n\t\t1. Standardize TOC (Table of Contents)\r\n\t\t2. Modify Description \r\n\t\t\t1. Include brief overview of the procedure and the purpose of the procedure. \r\n\t\t3. Modify Procedure \r\n\t\t\t1. Include descriptive procedure steps \r\n\t\t\t2. Add references as necessary \r\n\t\t\t3. Match procedure steps to flowchart items \r\n\t\t4. Modify Flowchart \r\n\t\t\t1. Update Visio flowchart \r\n\t\t\t2. Save as .jpg file \r\n\t\t\t3. Save .jpg file as an attachment in the Knowledge Base Topic and embed in the procedure document.\r\n4. Click \"Save\"\r\n\r\n![Image Name](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/DocumentationCreateUpdateProcess.png?raw=true\"Documentation Create/Update Process Flow\")\r\n" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Documentation Standards" }, "name": "Documentation Standard Procedures Text" }, { "type": 1, "content": { "json": "# Agile Methodology\r\n\r\n## Summary\r\nThe term Agility is used to describe a business process that is characterized by rapid and iterative execution. The ability to rapidly complete required tasks is critical to the rapid development of the [CUSTOMER] SOC. These practices are well understood and documented in the agile methodology processes (http://martinfowler.com/articles/newMethodology.html). \r\n\r\n## Agile SOC Operations\r\nAgility within Security Operations is not simply the continuous improvement of processes and procedures; this extends also to technology and people. A success organization (or team) continuously refines their operations to obtain increasing better performance across all services. Whether responding to a zero-day exploit, deployment of new technology systems or use cases our objective is to maximize the effectiveness of our operations (People, Process and Technology) to enable the business through security risk management.\r\n\r\n### Awareness: Monitoring and responding\r\n- Organizational Strategy occurs in the first loop. Activities which occur within this loop are central to the success of the organization.\r\n- The organizational strategy must be reflected within the organizations mission and vision statement\r\n\r\n### Balance: Improving existing processes\r\n- Operational Efficiency occurs in the second loop; constant adjustment and fine tuning of standard operating procedures to achieve the best overall performance.\r\n- Detect, identify and errors, gaps and/or areas of improvement-efficiency\r\n\r\n### Agility: Creating new operations (processes, procedures, or capabilities)\r\n- Operational Effectiveness occurs when persons build new capabilities and systems to address new issues, threats or opportunities.\r\n- Occurs when a new issue, threat or opportunity is detected and/or required.\r\n\r\n## Agile procedures\r\n- Rapidly document a first draft of any needed process or procedure. \r\n- Leverage the initial draft process and procedures in daily operations. \r\n- Subject the draft to continuous process improvement (performed by SOC Analysts and management during daily use). \r\n\t- Any analyst that identifies a process improvement or change immediately documents the change in the knowledge base process, i.e. Azure Sentinel Workbook \"SOC Process Framework\". \r\n\t- A full revision history is kept to track and maintain changes. \r\n\t- A nightly e-mail is sent to the SOC analysts and management with all process changes listed. \r\n- Periodic process/procedure reviews are used to maximize Process Maturity and effectiveness. \r\n\t- Use monthly KPI metrics to make improvements / adjustments. " }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Agile Methodology" }, "name": "Agile Methodology Text" }, { "type": 1, "content": { "json": "# Compliance Process\r\n\r\n## Purpose \r\nThe purpose of this document is to provide the process framework for the [CUSTOMER] SOC to comply with internal [CUSTOMER] IT & security policies, and to describe how the [CUSTOMER] SOC supports the broader corporate regulatory requirements. This process includes a list of procedures associated with applicable regulatory compliance and internal standards. \r\n\r\n## Scope \r\nThis process applies to all procedures implemented in the [CUSTOMER] SOC for regulatory compliance and compliance related activities. The scope of this process includes Azure Sentinel application and its defined regulatory Use Cases (see also Compliance Support). The primary regulations that are supported by the SOC are PCI, SOX, HIPAA, and general privacy best practices (PII/Personally Identifiable Information). \r\n\r\n## Process Summary \r\nThe SOC Manager and Lead Engineer will ensure that all systems in use by the [CUSTOMER] SOC are compliant with [CUSTOMER] Policies. The Lead Engineer will design and deploy appropriate Azure Sentinel content to satisfy the regulatory compliance use cases. \r\n\r\nThis process will contain one primary subordinate procedure; Compliance Support Procedures will document how the SOC meets [CUSTOMER]'s internal IT and security policies, corporate regulatory requirements, and will specify, down to individual use cases, how each regulatory requirement (as specified by the compliance owner) is to be met. These procedures will leverage foundational Azure Sentinel and underlying SaaS/PaaS capabilities such as M365 Compliance Manager and Azure Security Center.\r\n\r\n- Regulatory Drivers \r\n\t- Cybersecurity Maturity Model Certification (CMMC): [Cybersecurity Maturity Model Certification (CMMC) (osd.mil)](https://www.acq.osd.mil/cmmc/index.html)\r\n\t- PCI: http://www.pcisecuritystandards.org \r\n\t- Sarbanes-Oxley Act (SOX): http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=107_cong_public_laws&docid=f:publ204.107 \r\n\t- Health Insurance Portability and Accountability Act (HIPAA): http://aspe.hhs.gov/admnsimp/pl104191.htm \r\nGeneral privacy best practices (PII): http://csrc.nist.gov/publications/drafts/800-122/Draft-SP800-122.pdf\r\n\r\n## Compliance Process (High-Level) \r\n1. Develop appropriate Use Case documentation to support the solution to be implemented in Azure Sentinel.\r\n- Leverage Azure Sentinel Workbooks/Reports built-in (Templates) \r\n- Refer to the Use Cases Procedures in Design Process\r\n2. Determine priority for implementation \r\n3. Identify specific content to be generated through Azure Sentinel \r\n4. Design and implement Azure Sentinel Use Case components \r\n5. Validate output and reporting mechanisms \r\n6. Have compliance owner validate output \r\n7. Update components and reporting as requirements change \r\n\r\n## Metrics \r\n- Reports defined - Contract Progress \r\n- Use cases defined & completed - Contract Progress \r\n\r\n## Roles & Responsibilities \r\n- SOC Manager is responsible for the overall success of this process. The SOC manager ensures that the technology, training and budget is available to support SOC compliance. \r\n- Lead Engineer will devise all content as defined in the appropriate use cases and will administer the content within Azure Sentinel in accordance with internal security policies. \r\n- Security Compliance Team is responsible to provide policy and standards; provide reporting requirements; provide SOC related change/problem management of policies and standards; and receive compliance reports. \r\n\r\n## Additional Processes\r\n- Subordinate Procedures \r\n\t- Compliance Support Procedures\r\n- Related Process & Procedures \r\n\t- Business Measurement Process (Metrics)\r\n\t- Process Improvement\r\n\t- Daily Operations Process \r\n\t- Reporting Process \r\n\t- SOC Use Cases \r\n\r\n## Process Owner \r\nSOC Manager\r\n" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Compliance Process" }, "name": "Compliance Process Text" }, { "type": 1, "content": { "json": "# Compliance Support\r\n\r\n## Summary \r\nThe Compliance Procedure is designed to provide the SOC with a standardized method to ensure that [CUSTOMER] IT & security policies are adhered to during daily operations. Small and mid-size organizations may centralize compliance responsibilities into the SOC while larger organizations may have separate risk and compliance organizations with which the SOC will interoperate and collaborate. Organizations of all size significantly increase efficiency and transparency by mapping internal processes to specific external regulatory standards that are in scope for the organization (e.g. CMMC, PCI, HIPAA). Mapping and reporting against a defined international/external standard enables the SOC to dedicate focus on operations and not repeated administrative reporting tasking. \r\n\r\nAs part of [CUSTOMER]'s Information Systems Division, the SOC is expected to adhere to and assist with enforcement of all applicable [CUSTOMER]'s Policies. The requisite policies are listed below. \r\n\r\n## Scope \r\nAll SOC Procedures and Personnel are subject to and required to adhere to the [CUSTOMER] IT & security policies. In addition, where applicable, these policies are to be enforced through system and reporting/alerting design. \r\n\r\n## Procedure Description \r\nThe compliance procedure described below is intended to describe the compliance procedures in place within the SOC to adhere to all [CUSTOMER]'s Policies and applicable legal regulations. \r\n1. An initial review of the [CUSTOMER] Corporate Policies is to be completed and the Applicable Policies & Standards included in the Applicable Policies & Standards listing below. \r\n2. The listing of Applicable Policies & Standards below will be periodically reviewed and updated as defined in the Process Maturity Procedures. \r\n\t- If new policies are released, existing policies are expanded, or the Procedures of the SOC are updated, the listing of applicable policies should also be updated. \r\n\t- In addition, if any applicable legal regulations are added or expanded to include the standard operations of the SOC, those should also be listed below. \r\n3. As SOC Content is developed, the Applicable Policies & Standards listing below is to be consulted and the content developed in accordance with the relevant policies. \r\n4. During SOC operations (normal and abnormal), SOC personnel are expected to adhere to and assist with enforcement of all applicable policies. \r\n5. All Regulatory Compliance procedures are to be included in the Compliance Support topic. \r\n\r\n## Applicable Policies & Standards (Adherence & Enforcement) \r\nThe following internal policies are examples and may include information applicable to the SOC or SOC Operational Procedures:\r\n \r\n- Cybersecurity Maturity Model Certification (CMMC): [Cybersecurity Maturity Model Certification (CMMC) (osd.mil)](https://www.acq.osd.mil/cmmc/index.html)\r\n- FedRAMP/NIST 800-53: [SP 800-53 Rev. 5](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)\r\n- PCI: http://www.pcisecuritystandards.org \r\n- Sarbanes-Oxley Act (SOX): http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=107_cong_public_laws&docid=f:publ204.107 \r\n- Health Insurance Portability and Accountability Act (HIPAA): http://aspe.hhs.gov/admnsimp/pl104191.htm \r\n- General privacy best practices (PII): http://csrc.nist.gov/publications/drafts/800-122/Draft-SP800-122.pdf \r\n\r\n## Process Procedures\r\n- Subordinate Procedures \r\n\t- Validation of O365 Configuration against required compliance framework\r\n\t\t- SOC managers shall leverage O365 Compliance Manager capability to validate both Microsoft and [CUSTOMER] responsible controls\r\n\t\t\t- Assign appropriate user/admin access for Compliance Manager \r\n\t\t\t- Select appropriate Compliance Manager Template (ISO 27001, CMMC Level 3, etc.)\r\n\t\t\t- Review recommended improvement actions and assign as appropriate for completion\r\n\t\t\t- Those responsible for completion shall document implementation and test results in Compliance Manager for customer-responsible controls\r\n\t\t\t- Leverage reporting capabilities of Compliance Manager to report both Microsoft and [CUSTOMER] actions for internal and external requests\r\n\t- Validation of Azure Configuration against required compliance framework\r\n\t\t- Use of Azure Security Center.\r\n\t\t\t- Azure Security Center helps streamline the process for meeting regulatory compliance requirements, using the regulatory compliance dashboard.\r\n\t\t\t- Security Center continuously assesses your hybrid cloud environment to analyze the risk factors according to the controls and best practices in the standards applied to your subscriptions. The dashboard reflects the status of your compliance with these standards.\r\n\t\t\t- When you enable Security Center on an Azure subscription, the Azure Security Benchmark is automatically assigned to that subscription. This widely respected benchmark builds on the controls from the Center for Internet Security (CIS) and the National Institute of Standards and Technology (NIST) with a focus on cloud-centric security.\r\n\t\t\t- The regulatory compliance dashboard shows the status of all the assessments within your environment for your chosen standards and regulations. As you act on the recommendations and reduce risk factors in your environment, your compliance posture improves.\r\n- Related Processes & Procedures\r\n\t- Event Management Process \r\n- See also Azure Sentinel's Workbook: ASC Compliance and Protection\r\n\r\n![Compliance Details](https://techcommunity.microsoft.com/t5/image/serverpage/image-id/183161i87F0E76F8963DC1C/image-dimensions/717x258?v=v2)\r\n\r\n![Regulatory Standards](https://techcommunity.microsoft.com/t5/image/serverpage/image-id/183162iA76FFD0D38E726D8/image-size/large?v=v2&px=999)\r\n\r\n![Baselines](https://techcommunity.microsoft.com/t5/image/serverpage/image-id/183385iFA585E180C84AD61/image-size/large?v=v2&px=999)\r\n\r\n## Detailed Compliance Support Steps\r\n\r\n### Step 1: Receive Compliance Requirements \r\nThe first step involves the compliance team providing the SOC with a set of logging and reporting requirements. \r\n1. Compliance team provides logging & reporting requirements. \r\n2. Determine which needs can be met by the SOC Operational Processes. \r\n\r\n### Step 2: Identify Data Sources \r\nThe second step will also need to be completed with assistance of the data/business owners. \r\n1. Develop listing of data sources necessary to meet requirements collected in Step 1. \r\n2. Identify system owners that maintain data required to meet the logging/reporting requirements (i.e. platform admins, application admins, DB admins). \r\n3. Provide system owners with steps necessary to provide audit/logging information to Azure Sentinel Connectors. \r\n- Note: If all requirements cannot currently be met with Azure Sentinel, notify compliance team and provide alternate recommendations (if available). \r\n\r\n### Step 3: Add Data Sources to Sentinel \r\nThe third step requires support from the system owners & administrators to provide the interfaces necessary for Azure Sentinel to collect the required information. \r\n1. Coordinate with system owners to supply logging/audit information to Azure Sentinel. \r\n2. Provide support as necessary (i.e. links to examples or system documentation) if system owners cannot supply the necessary information. \r\n3. Once system logs are transmitted to an Azure Sentinel, verify that the required field and trace information is available and is being properly indexed in Azure Sentinel. \r\n\r\n### Step 4: Create Reporting \r\n1. From the requirements gathered in Step 1, generate the trends, queries, and reports necessary to meet the reporting criteria. \r\n2. Schedule reports as necessary to provide automatic generation and distribution to the compliance teams, SOC, and system owners. \r\n3. Most reports will be generated on a regular basis; however, it may be necessary to generate some on an 'on-demand' schedule. These reports should be prepared, but not scheduled for automatic execution or distribution. \r\nWork with compliance team and system owners to generate meaningful, useful reports that can aid them with the secure operation of their systems and in meeting the compliance objectives of the organization.\r\n\r\n### Step 5: Review and Approve Reporting Contents & Schedule with Compliance Team \r\n1. Once reports have been generated, verify with compliance team and system owners that the delivered reports are applicable, meaningful, and useful in meeting the organization's compliance objectives. \r\n2. Conduct periodic reviews of compliance reporting (as part of the Process Maturity cycle) to verify that the services and reporting provided to the compliance teams by the SOC are useful.\r\n\r\n## Compliance Status Matrix\r\n\r\n| | SOX | HIPPA - Benefits | HIPPA - PHARMA/Optical | PCI | CMMC | Step Description |\r\n| : | : | : | : | : | : | : |\r\n| Assigned | Matt E. | Randal C. | Beth B. | Edward H. | Rin U. | |\r\n| Step 1 Status | | | | | | Receive Compliance Requirements |\r\n| Step 2 Status | | | | | | Identify Data Sources |\r\n| Step 3 Status | | | | | | Add Data Sources to Azure Sentinel |\r\n| Step 4 Status | | | | | | Enable/Edit or Create Reporting |\r\n| Step 5 Status | | | | | | Review and Approve Reporting |\r\n\r\n## Supporting Processes \r\n- Related Process & Procedures \r\n\t- Internal Compliance \r\n\t- Process Maturity \r\n\r\n## Process Owner \r\nSOC Manager \r\n" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Compliance Support" }, "name": "Compliance Support Text" }, { "type": 1, "content": { "json": "# Business Continuity & Disaster Recovery Process\r\n\r\n## Purpose\r\nThe purpose of this document is to provide the framework for [CUSTOMER]'s Security Operations Center (SOC) Business Continuity and Disaster Recovery plans. This process will include a list of procedures associated with a business continuity plan based on specific scenarios and having detailed disaster recovery plans. The goal is to provide a plan that minimizes impact to service capability in the event of disaster scenario or technology failure.\r\n\r\n## Scope\r\nThis process applies to all procedures implemented in the [CUSTOMER] SOC to minimize disruptions to service or capability. The scope of this process is strictly limited to the [CUSTOMER] SOC. This process will be documented within the BC/DR Procedure page. \r\n\r\n## Process Summary \r\nThe Lead Engineer will provide the appropriate technology configuration for Disaster Recovery and detailed plans for Business Continuity. A business continuity and disaster recovery plan is essential to ongoing service capability as well as overall business security and health. As part of this effort, the Azure infrastructure may be configured for fail-over on all asset pairs. \r\n\r\n## BC/DR Planning Process \r\n- Identify BC/DR scenarios \r\n- Identify impact per scenario \r\n- Develop detailed recovery plans for each scenario and establish objectives. \r\n\t- RTO - Recovery Time Objectives \r\n\t- RPO - Recovery Point Objectives \r\n- Test recovery plans on an annual basis \r\n- Evaluate effectiveness of plans \r\n- Review plan on a quarterly basis \r\n\r\n## Metrics \r\n- Process Maturity Assessment Results \r\n\r\n## Roles & Responsibilities \r\n- SOC Manager is responsible for the overall success of this process. The SOC manager ensures that the technology, training and budget is available to support the BC/DR plans. \r\n- Lead Engineer is responsible for maintaining appropriate technical configurations to meet defined recovery time and point objectives. \r\n- SOC Operations Lead is responsible to work with the SOC Manager to define BC/DR scenarios, plans, test, review, and evaluate plan success. \r\n- SOC Analyst is responsible to identify service capability disruptions, execute BC/DR plans, and provide continuous improvement feedback. \r\n\r\n## Applicable Policies & Standards \r\n- http://url - Insert [CUSTOMER]'s Policies Here \r\n\r\n## Supporting URLs\r\n- [SLA for Log Analytics | Microsoft Azure](https://azure.microsoft.com/support/legal/sla/log-analytics/v1_3/)\r\n- [Service Level Agreements Summary | Microsoft Azure](https://azure.microsoft.com/support/legal/sla/summary/)\r\n\r\n## Supporting Processes\r\n- Related Process & Procedures \r\n\t- Business Measurement Process (Metrics) \r\n\t- Process Improvement \r\n\t- Daily Operations Process \r\n\t- Reporting Process \r\n\r\n## Process Owner \r\nSOC Manager \r\n" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Business Continuity Process" }, "name": "Business Continuity Process Text" }, { "type": 1, "content": { "json": "# Business Continuity & Disaster Recovery Plans\r\n\r\n## Overview \r\nAll BCDR Plans for the [CUSTOMER] and/or SOC are maintained at (insert link here). \r\n\r\nLinks \r\n- https://url Insert [CUSTOMER]'s BC/DR Plans Here \r\n" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Business Continuity & Disaster Recovery Plans" }, "name": "Business Continuity & Disaster Recovery Plans Text" }, { "type": 1, "content": { "json": "# SOC Efficiency Metrics\r\n\r\n## Security operations efficiency workbook\r\nTo complement the SecurityIncidents table, we’ve provided you an out-of-the-box security operations efficiency workbook template that you can use to monitor your SOC operations. The workbook contains the following metrics:\r\n\r\n- Incident created over time\r\n- Incidents created by closing classification, severity, owner, and status\r\n- Mean time to triage\r\n- Mean time to closure\r\n- Incidents created by severity, owner, status, product, and tactics over time\r\n- Time to triage percentiles\r\n- Time to closure percentiles\r\n- Mean time to triage per owner\r\n- Recent activities\r\n- Recent closing classifications\r\n\r\nYou can find this new workbook template by choosing Workbooks from the Azure Sentinel navigation menu and selecting the Templates tab. Choose Security operations efficiency from the gallery and click one of the View saved workbook and View template buttons.\r\n\r\n![SOC Incident Management Metrics](https://docs.microsoft.com/azure/sentinel/media/manage-soc-with-incident-metrics/security-incidents-workbooks-gallery.png)\r\n\r\n![SOC Incident Workbook Metrics](https://docs.microsoft.com/azure/sentinel/media/manage-soc-with-incident-metrics/security-operations-workbook-1.png)\r\n\r\nEvery time you create or update an incident, a new log entry will be added to the table. This allows you to track the changes made to incidents, and allows for even more powerful SOC metrics, but you need to be mindful of this when constructing queries for this table as you may need to remove duplicate entries for an incident (dependent on the exact query you are running)." }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "SOC Efficiency Metrics" }, "name": "SOC Efficiency Metrics Text" }, { "type": 1, "content": { "json": "# SOC Analytics Efficiency Metrics\r\n\r\n## Description\r\nThe modern SOC handles multiple data sources and needs to detect threats and provide insights to the analyst. Since SOC resources are limited, a delicate balance must be struck between maximizing the detection of threats and minimizing the occurrence of false positives.\r\n\r\nIn the Analytics Efficiency Workbook, we try to provide different perspectives on detections.\r\n\r\n- Alert rules - a holistic view of our detections provides us with insights into the detections' overall coverage. In this section, we can see our MITRE ATT&CK framework coverage, overall rules status, rules that require attention, and a view of the detections suite.\r\n- Alerts - in this view, we will look at the alerts created from our detections. Since not all rules will create incidents, we can monitor the noisiness of the detections and see which ones require tuning. In the alerts insights section, we provide insights into detections that are not firing and might require attention and track the load from different providers.\r\n- Incidents - The load on the SOC is determined by the number of incidents we create. Here we can monitor which detections created incidents and the reasons incidents are closed. When looking at the incident load and the closing reason, we can deduce which detections require attention and tuning.\r\n\r\nIterating on all 3 views in a repetitive process will improve our detection efficiency, SOC performance, and, ideally, the organization’s detection suite. This continuous process should adapt our detections to the ever-changing security threat landscape.\r\n\r\n![Analytics Efficiency](https://techcommunity.microsoft.com/t5/image/serverpage/image-id/255498i05BDC150FB36F807/image-size/large?v=v2&px=999)\r\n\r\nThere are two ways to access this workbook –\r\n\r\n1. The workbooks gallery - You can find this new workbook template by choosing Workbooks from the Azure Sentinel navigation menu and selecting the Templates tab. Choose Detection efficiency from the gallery and click one of the View saved workbook and View template buttons.\r\n2. The Analytics pane - You can find the new workbook in the Alert rules action panel at the top of the pane. If a saved workbook were created from the workbook template, the button would lead to the saved workbook. If not, it will lead to the workbook template. More details can be found in the documentation.\r\n" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "SOC Analytics Efficiency Metrics" }, "name": "SOC Analytics Efficiency Metrics Text" } ] }, "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "SOC Business Processes & Procedures" }, "customWidth": "75", "name": "SOC Business Processes & Procedures Group" }, { "type": 12, "content": { "version": "NotebookGroup/1.0", "groupType": "editable", "items": [ { "type": 1, "content": { "json": "# SOC Operational Processes & Procedures\r\n\r\n| Process Name | Procedures | Description/Comments |\r\n| : | : | : |\r\n| Incident Management Process | | |\r\n| | Incident Triage | Describes how a SOC Analyst determines what action to take based on Alerts fired and Incidents Created within Azure Sentinel |\r\n| | Callout / Escalation | Instructions for the SOC Analyst for Incident escalation of all severities |\r\n| | Incident Management Procedure | Documents the step-by-step flow involved in the closed-loop management of Azure Sentinel Incidents |\r\n| | Crisis Response | Documents the steps a SOC Analyst should take in the event a cyber-crisis situation is recognized |\r\n| | Shift Log Management | Instructions for the SOC Analyst describing what information should be provided in a shift log entry |\r\n| | Phone Bridge Details | Instructions on how to start a phone bridge conference |\r\n| | Vulnerability Scanning Schedule | Scanning schedule for vulnerability assessments & pen testing exercises |\r\n| | IP & Domain Blocklisting | Tracking all IP and Domain black lists detected by the SOC |\r\n| Daily Operations Process | | |\r\n| | Daily Ops Meeting | Document all aspects of the daily operations call or meeting for the SOC's situational awareness |\r\n| | Problem Tickets and Change Controls | Procedures that documents how non-emergent processes associated with SOC operations are handled |\r\n| | Shift Staffing Schedule | Procedures to ensure appropriate staffing and establishes standard shift schedules |\r\n| | Shift Turnover | Instructions for conducting a standard shift turn-over |\r\n| Weekly Operational Process | | |\r\n| | Weekly Threat Intelligence Report | Instructions for creating the Weekly Threat Intelligence Report |\r\n| Reporting Process | | |\r\n| | Periodic Reports | Procedures for producing daily and weekly reports in the SOC |\r\n\r\n" }, "customWidth": "75", "name": "SOC Operational Processes & Procedures Text" }, { "type": 11, "content": { "version": "LinkItem/1.0", "style": "list", "links": [ { "id": "bf320ec4-8ae3-47a6-ade5-19e27b21d168", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Incident Management Process", "subTarget": "Incident Management Process", "preText": "", "style": "primary" }, { "id": "87b6dbf5-a466-497a-aa62-bba5324123e1", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Incident Triage", "subTarget": "Incident Triage", "style": "secondary" }, { "id": "c6ef5f51-b129-472e-8fb0-603b37ec0c48", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Callout / Escalation", "subTarget": "Callout / Escalation", "style": "secondary" }, { "id": "2cca5094-4e44-4893-aa8f-4a69cf59b379", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Incident Management Procedure", "subTarget": "Incident Management Procedure", "style": "secondary" }, { "id": "54659f20-8e2e-49de-8b2b-749c6bfe9a07", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Crisis Response", "subTarget": "Crisis Response", "style": "secondary" }, { "id": "5d11f7cc-c055-4c39-a039-07567cbc15a4", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Shift Log Management", "subTarget": "Shift Log Management", "style": "secondary" }, { "id": "d2e08fb3-82e1-47cb-8d35-e6111a26c362", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Phone Bridge Details", "subTarget": "Phone Bridge Details", "style": "secondary" }, { "id": "958ef165-bf8f-4819-915d-6a5ea322cef0", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Vulnerability Scanning Schedule", "subTarget": "Vulnerability Scanning Schedule", "style": "secondary" }, { "id": "617f44c7-24cb-4046-9c18-d2608d8c25ea", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "IP & Domain Blocklisting", "subTarget": "IP & Domain Blocklisting", "style": "secondary" }, { "id": "340d57f0-2567-4991-8ca8-927fb2ccc63c", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Daily Operations Process", "subTarget": "Daily Operations Process", "style": "primary" }, { "id": "039d715e-6804-4071-8a60-a2ccc0445447", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Daily Ops Meeting", "subTarget": "Daily Ops Meeting", "style": "secondary" }, { "id": "b21688f8-2690-47b6-8f41-cb1b9800c660", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Problem Tickets and Change Controls", "subTarget": "Problem Tickets and Change Controls", "style": "secondary" }, { "id": "240a5355-4ded-41f7-834e-b4e5d6eeef4e", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Shift Staffing Schedule", "subTarget": "Shift Staffing Schedule", "style": "secondary" }, { "id": "c085e1c9-0a4f-40f0-9d0c-6151f6cac5cf", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Shift Turnover", "subTarget": "Shift Turnover", "style": "secondary" }, { "id": "8eb257d2-b83a-462a-b5d7-f356752edb9d", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Weekly Oerational Process", "subTarget": "Weekly Operational Process", "style": "primary" }, { "id": "6170d188-0b48-4fd5-ac66-2fb6619c7bab", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Weekly Threat Intelligence Report", "subTarget": "Weekly Threat Intelligence Report", "style": "secondary" }, { "id": "affba0d2-c45f-4083-8dd8-ccf77e424f1d", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Reporting Process", "subTarget": "Reporting Process", "style": "primary" }, { "id": "69269ca7-5948-4ab8-8a0f-2fb6519c3bf0", "cellValue": "Tab", "linkTarget": "parameter", "linkLabel": "Periodic Reports", "subTarget": "Periodic Reports", "style": "secondary" } ] }, "customWidth": "25", "name": "SOC Operational Processes & Procedures Tabs", "styleSettings": { "margin": "20", "padding": "20" } }, { "type": 1, "content": { "json": "# Incident Management Process\r\n\r\n## Purpose \r\nThe purpose of this process is to provide the high-level process and supporting detailed procedures for the handling of all Incident's that occur within Azure Sentinel. \r\n\r\n## Scope \r\nThis process applies to every Incident/Alert/Events that is displayed on the Azure Sentinel Incidents Blade in the [CUSTOMER]'s Security Operations Center (SOC). This process primarily applies to Incidents/Alerts/Events that are tagged with \"Triage\". \r\n\r\n## Process Summary \r\nAll Assigned SOC Analysts will appropriately manage the lifecycle of Incidents/Alerts/Events within Azure Sentinel. An Incident is generated in Azure Sentinel monitored security device within the [CUSTOMER] Enterprise. This event has a number of associated meta tags that further classify, prioritize and define it. Azure Sentinel is monitored 8x5x365 by the SOC. The on duty SOC Intrusion Analyst applies Intrusion Analysis Procedures to these Incidents to further understand them and then executes one of the Incident Management procedures established under this process. \r\n\r\n## Triage Procedure \r\nThe Incident Triage Procedure establishes the responses required for each event by priority and category. This procedure will document items such as category, model confidence, priority and provide a decision matrix that documents appropriate actions. These actions will be; Investigate, Open Problem & Change Ticket, Add to Watch List, Initiate Callout, Open New Incident, or Initiate the Crisis Response Procedure. The triage process will also document the event stages that apply as events are analyzed, triaged and closed. \r\n- Incident evaluation \r\n\t- Initial evaluation of correlated events within Incidents \r\n- Determine further evaluation or initiate action \r\n\t- Expand data set to include detailed records \r\n\t- Execute discovery tools, if required \r\n- Reference triage matrix \r\n- Execute action \r\n\r\n## Callout Procedure \r\nThe Callout Procedures defines the step-by-step process to follow in order to notify an Incident Manager or other appropriate escalation point of contact. \r\n- Determine appropriate communication method \r\n- Reference Triage matrix \r\n- Execute action \r\n\t- Follow Escalation path for out-of-criteria cases \r\n\t- Validate completion \r\n\r\n## Incident Management Procedure \r\nThe Incident Management Procedure documents the step-by-step flow involved in the closed-loop management of opened Incidents within Azure Sentinel for Incidents/Alerts/events requiring management actions as defined in the Triage Procedures. \r\n- Incident Created \r\n- Assign Incident\r\n- Resolve Incident\r\n- Validate Resolution \r\n- Close Incident \r\n- Assign appropriate disposition \r\n\r\n## Crisis Response Procedure \r\nThe Crisis Response Procedures documents the steps the SOC should take in the event a cyber-crisis situation is recognized. This procedure stands up the Crisis action team as documented in the aforementioned procedure. \r\n- SOC initiated \r\n\t- IRT \r\n\t\t- Network Team \r\n\t\t- Server Team \r\n- SOC supported \r\n\t- IRT \r\n\t\t- Command Center \r\n\t\t- Ancillary Teams \r\n\r\n## Incident Management Process Flow \r\nThe Incident Priority Chart is used to determine the priority and urgency of an Incident based on the perceived or actual impact on business functions. For all Incidents/Alerts not defined in the Triage Procedure, use the matrix below to determine the priority and urgency of a new Incident. \r\n\t\r\nFor all Incidents determined to be a SEV1 or SEV2 incident, a Crisis Response will be initiated. The Crisis Response Procedure follows the high level chart below. The SOC is responsible for initiating this flow and verifying with the Incident Manager that the problem has been resolved and the Problem Management Process has been initiated. \r\n\t\r\n## Metrics \r\n- Incidents handled per analyst - Personnel KPIs \r\n- Incidents per total events handled by analyst - Personnel KPIs \r\n- Incidents opened by category by analyst - Personnel KPIs \r\n- Incidents opened by severity - Overall KPIs \r\n- Incidents per analysts hour - Overall KPIs \r\n- Total Incidents by final disposition - Overall KPIs \r\n\r\n## Roles & Responsibilities \r\n- SOC Manager only has high level responsibilities associated with the Incident management process. These are to ensure that appropriate training and resources are provided to the SOC Analysts. \r\n- SOC Operations Lead is responsible for ensuring the accuracy and relevance of this process as well as all associated procedures. \r\n- SOC Analyst is responsible for the appropriate execution of this process and all associated procedures. The SOC Analyst is responsible for ensuring that any procedure initiated is completed in a closed-loop and well documented manner. \r\n- Incident Response Handler is responsible for receiving the appropriate notification and responding in a timely fashion to callouts. The Incident Response Handler is responsible for completing any required investigation and closing the loop with the SOC by closing the opened Incident and informing the SOC of relevant findings for process improvements. \r\n\t\r\n## Process Owner \r\nSOC Manager" }, "customWidth": "75", "conditionalVisibility": { "parameterName": "Tab", "comparison": "isEqualTo", "value": "Incident Management Process" }, "name": "Incident Management Process Text" }, { "type": 1, "content": { "json": "# Incident Triage\r\n\r\n## Description \r\nThis procedure describes how a SOC Analyst determines what action to take based on Alert(s)/Incident(s) observed within Azure Sentinel. Triage is the process of evaluating multiple Incidents to determine which are the most critical and prioritizing your response based on this analysis. This procedure will result in one of the listed response actions. \r\n\r\n### Step 1 - Determine Category Type and Action Needed \r\nApply the decision matrix below using the category type and asset priority. This is used in conjunction with the SOC Rule Response Procedures for the rule triggered. The severities defined below are based on adaptations from the [CUSTOMER's] Threat Matrix.\r\n\r\n| |\r\n| : | : |\t\r\n| SEV-4\t| (Minor) - Informational, some security impact |\r\n| |- Non-critical systems (e.g., associate workstations), OR Non-critical infrastructure