Azure-Sentinel/Workbooks/SOCProcessFramework.json

{
  "version": "Notebook/1.0",
  "items": [
    {
      "type": 1,
      "content": {
        "json": "#### Author: Rin Ure\r\n\r\n# Welcome to the [CUSTOMER] Security Operations Center\r\n\r\nThe SOC Knowledge Base is a collaborative environment that serves as the centralization point for all documentation concerning the SOC and its ancillary support. A well-structured, highly detailed knowledge base is essential to ensuring the operation of a successful and efficient Security Operations Center. Any new documentation should be added to the SOC Knowledge Base in the appropriate place by SOC personnel.\r\n\r\nTo get started, please use the \"BLUE\" Navigation buttons on the left starting with \"SOC Main\". Each Navigation button takes you to a different section of the Workbook providing you with information pertaining to that section.\r\n\r\nTo Remove the [CUSTOMER] and change it to your SOC Name, simply edit this workbook and use the CTRL-F to Find and Replace the [CUSTOMER] with your desired SOC Name.",
        "style": "success"
      },
      "name": "CUSTOMER Security Operations Center - Workflow"
    },
    {
      "type": 11,
      "content": {
        "version": "LinkItem/1.0",
        "style": "list",
        "links": [
          {
            "id": "c3b91922-4cf2-442f-97cf-b1f2b751f18f",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Main",
            "subTarget": "SOC Main",
            "style": "primary"
          },
          {
            "id": "7b9098a5-6822-4fed-9d45-278b2e61d779",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Contacts",
            "subTarget": "SOC Contacts",
            "style": "primary"
          },
          {
            "id": "3de8dfb1-c307-48c9-98fe-5ca4820d82ef",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Process Hierarchy",
            "subTarget": "SOC Process Hierarchy",
            "style": "primary"
          },
          {
            "id": "98212cec-3255-4a9a-b446-f8ecd0ffbafc",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Roles and Responsibilities",
            "subTarget": "SOC Roles and Responsibilities",
            "style": "primary"
          },
          {
            "id": "4576149b-97d4-4fcc-88a1-0b07e932fc4a",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Incident Response Framework",
            "subTarget": "SOC Incident Response Framework",
            "style": "primary"
          },
          {
            "id": "22bd415d-561b-4539-abd5-48d4d65d40c7",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Incident Response Procedures",
            "subTarget": "SOC Incident Response Procedures",
            "style": "primary"
          },
          {
            "id": "763c09c7-ab3f-4055-a70d-4ac37499db9a",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Analytical Processes & Procedures",
            "subTarget": "SOC Analytical Processes & Procedures",
            "style": "primary"
          },
          {
            "id": "932e5a7c-6ec3-4907-bc61-0b0363c2e96e",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Business Processes & Procedures",
            "subTarget": "SOC Business Processes & Procedures",
            "style": "primary"
          },
          {
            "id": "53170725-a216-4ef0-91e3-2c7ea00a0c27",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Operational Processes & Procedures",
            "subTarget": "SOC Operational Processes & Procedures",
            "style": "primary"
          },
          {
            "id": "52ab5e02-b551-4b25-90a9-78101b3f68ce",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Technology Processes & Procedures",
            "subTarget": "SOC Technology Processes & Procedures",
            "style": "primary"
          },
          {
            "id": "b7010a31-6796-475a-b3d1-824cc9f825ce",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Tools and Resources",
            "subTarget": "SOC Tools and Resources",
            "style": "primary"
          },
          {
            "id": "092b9162-dfe1-4e6f-953f-a2d9e0f59027",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Incident Actions",
            "subTarget": "SOC Incident Actions",
            "style": "primary"
          },
          {
            "id": "096a8368-e5ab-4093-87d2-7e2a97ea99b0",
            "cellValue": "Tab",
            "linkTarget": "parameter",
            "linkLabel": "SOC Training",
            "subTarget": "SOC Training",
            "style": "primary"
          }
        ]
      },
      "customWidth": "20",
      "name": "SOC Workflow Categories",
      "styleSettings": {
        "margin": "150",
        "padding": "100"
      }
    },
    {
      "type": 1,
      "content": {
        "json": "## SOC [MAIN] Mission Statement \r\n\r\n### The mission of the Security Operations Center is to:\r\n\r\n- Identify and alert on all cyber threats and compliance exceptions\r\n- Assist in minimizing the impact of adverse events that do occur\r\n- Achieve rapid situational awareness of current threats and compliance statutes\r\n- Automate manual reporting processes \r\n- Expedite remediation and incident response times\r\n- Continually measure and improve the effectiveness of security and compliance processes\r\n- Automate monitoring and enforcement of security controls\r\n\r\n### Process & Procedures by Category\r\n\r\n| Process & Procedures by Category |\r\n| : | : | : | : | : | : | : |\r\n| SOC Analytical Processes & Procedures | SOC Operational Processes & Procedures | SOC Technology Processes & Procedures | SOC Business Processes & Procedures | SOC Incident Actions | SOC Tools & Resources | SOC Training |\r\n\r\nEvery SOC Analyst is responsible for reading and understanding all process and procedures documented in this knowledge base. After each new analyst reads a process or procedure page, he/she will sign that page in the section labeled Analyst Signatures acknowledging their understanding and acceptance. SOC analysts will automatically receive nightly notifications of all changes made to these process and procedures. \r\n\r\n### Additional Categories\r\n\r\n| Additional Categories |\r\n| : | : | : | : | : |\r\n| Process Hierarchy | Procedure Flow | SOC Roles and Responsibilities | SOC Contacts |\r\n\r\n### Procedure Flow\r\nThis is a visual representation of the procedures that drive Analytics and Operations within the SOC.\r\n\r\nFor example, business functions and compliance requirements drive use cases. SOC Operations and shift changes impact how incidents are triaged. This is a cycle that is fed by the [CUSTOMERS] SOC Analytic, Business, and Operataional processes, Compliance Frameworks, and staffing practices.\r\n\r\n![Image Name](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/Procedure%20Flow%20-%20SOC%20in%20a%20BOX.png?raw=true\"SOC in a BOX\")",
        "style": "info"
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Main"
      },
      "customWidth": "75",
      "name": "SOC Main"
    },
    {
      "type": 1,
      "content": {
        "json": "## SOC Contacts\r\n\r\n| SOC Team Contacts |\r\n| : | : | : | : | : | : | : | : |\r\n| Name | Title | Primary Phone | Secondary Phone | Office Line | User ID | Location | Knowledge Base Pages |\r\n|  |  |  |  |  |  |  |  |  |\r\n\r\n## SOC Workstations\r\n\r\n| SOC Workstations |\r\n| : | : | : | : | : | : | : |\r\n| User | Location | Internal Line | Workstation Name | IP Address | Mac Address | Serial Number |\r\n|  |  |  |  |  |  |  |  |\r\n\r\n## Pager Contact Information for Security\r\n\r\n| Pager Contact Information for Security |\r\n| : | : | : | : |\r\n| Team Name | Pager Info. for Outlook | Phone Number | Manager |\r\n|  |  |  |  |  |\r\n\r\n## General IT & Emergency Contacts\r\n| General IT & Emergency Contacts |\r\n| : | : | : |\r\n| Team Name | Phone Number | Description |\r\n|  |  |  |  |\r\n\r\n## Departmental Contacts\r\n\r\n| Departmental Contacts |\r\n| : | : | : | : | : | : |\r\n| Department | Manager | Individual(s) | Items Responsible | Manager Phone | AD Group |\r\n|  |  |  |  |  |  |  |\r\n\r\n## Email Distribution Lists\r\n\r\n| Email Distribution Lists |\r\n| : | : | : |\r\n| Team Name | Email | Description |\r\n|  |  |  |  |\r\n\r\n## External Contacts\r\n\r\n| External Contacts |\r\n| : | : | : | : | : | : | : |\r\n| Vendor | Contact Name | Position | Area of Expertise | Email | Phone | Alt Phone |\r\n|  |  |  |  |  |  |  |  |\r\n\r\n## Internal Contacts\r\n\r\n| Internal Contacts |\r\n| : | : | : | : | : | : | : |\r\n| Vendor | Contact Name | Position | Area of Expertise | Email | Phone | Alt Phone |\r\n|  |  |  |  |  |  |  |",
        "style": "info"
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Contacts"
      },
      "customWidth": "75",
      "name": "SOC Contacts",
      "styleSettings": {
        "margin": "0",
        "padding": "0",
        "maxWidth": "100"
      }
    },
    {
      "type": 1,
      "content": {
        "json": "# Roles & Responsibilities\r\nThis section provides a high level overview of the needed roles and responsibilities for successfully operating and maintaining a Security Operations Solution to satisfy the business requirements defined.\r\n\r\n### Director – Security Operations\r\nThe Director – Security Operations is responsible for setting the tone and direction of the Security Operations Center (SOC), defining its mission and communicating with senior management and other teams to accomplish its tasks.\r\n\r\nThe Director manages the overall relationships with:\r\n\r\n- First Line Senior Management\r\n- Second Line\r\n- Compliance\r\n- Audit\r\n\r\n### Manager – Security Operations Center (SOC)\r\nThe Manager – Security Analysis is responsible for leading the day to day operations of the SOC analyst staff.  The role coordinates and works with the SOC Analysts to make sure that the analysts processes and technology are meeting the SOC security monitoring, analysis, and escalation objectives, organization service level agreements, objectives, and metrics. \r\n\r\nIn addition, the Manager of SOC Security Analysts will:\r\n\r\n- Ensure daily operational processes effectively support SOC operations objectives.\r\n- Execute continuous process improvement.\r\n- Interface with other SOC and outside teams. \r\n- Manage the process improvement program for SOC processes.\r\n- Ensure that all SOC personnel issues are being addressed. \r\n- Ensure senior management aware of any issues or incidents. \r\n- Ensure all SOC staff receives development guidance in accordance with the practices and standards of the SOC. \r\n- Manage shift scheduling. Manage regular, holiday, illness, vacation and emergency scheduling\r\n- Conducts shift turnovers and briefings.\r\n- Own the successful completion of all daily operational processes and procedures.\r\n- Ensure analysts follow existing procedures and all procedures are documented in accordance with local guidelines.\r\n- Track tactical issues in execution of all SOC responsibilities. \r\n- Document and track analyst training requirements.\r\n\r\n### SOC Level 1 Analyst\r\nA Level 1 SOC Analyst executes daily operations procedures as a matter of daily responsibility. The role of an SOC Analyst is the detailed and repeatable execution of all operational tasks as documented in processes and subordinate procedures. Specifically, the SOC Analyst will be responsible for monitoring the Azure Sentinel Incident Blade for security events/alerts/incidents and closing or escalating those as necessary. SOC Analysts maintain the group email address and distribution lists, answer SOC main phone lines, and update all relevant documentation such as shift logs and tickets.     \r\n\r\nSpecifically, the SOC Level 1 Analyst(s) will:\r\n- Rapidly identify, categorize, prioritize and Triage Incidents as the initial step for the enterprise using all available CUSTOMER's log and intelligence sources to include but not limited to:\r\n- Firewalls\r\n- Systems and Network Devices\r\n- Web Proxies\r\n- Intrusion Detection/Prevention Systems\r\n- Data Loss Prevention\r\n- Antivirus Systems\r\n- OneNote Framework\r\n\t- Monitor incoming event queues for potential security incidents using Azure Sentinel per operational procedures.\r\n\t- Perform initial investigation and triage of potential incidents, and escalate or close Incidents as applicable.\r\n\t- Use available SOC tools for historical analysis purposes as necessary for detected Alerts/Incidents; for example, historical searches using Azure Sentinel Log Analytics.\r\n\t- Monitor SOC e-mail queue for potential event reporting from outside entities and individual users.\r\n\t- Maintain SOC shift logs with relevant activity from analyst shift.\r\n\t- Document investigation results, ensuring relevant details are passed to the Secondary Analysts for final event analysis. \r\n- Update/reference SOC collaboration tool (Wiki, OneNote) as necessary for changes to SOC processes and procedures, and ingest of SOC daily intelligence reports and previous shift logs. \r\n- Conduct research and document Alerts/Events of interest within the scope of IT Security\r\n\r\nAdditionally, Level 1 Analysts who have tenure in security monitoring of more than one year will:\r\n- Track tactical issues in execution of SOC responsibilities\r\n- Mentor junior analysts to improve detection/analytical capabilities within the SOC.\r\n- Manage SOC event and information intake to include gathering intelligence reports, monitoring ticket queues, investigating reported incidents, and interacting with other security and network groups as necessary.\r\n- Coordinate with SIEM Engineers to tune Events and Alerts.\r\n- Serve as shift subject matter experts on incident detection and analysis techniques providing guidance to junior analysts and making recommendations to organizational managers.\r\n \r\n### SOC Level 2 Analyst\r\nThe Level 2 Analyst ensures incidents are detected and tracked in a timely manner.  The Level 2 Analyst owns the successful adherence to all procedures executed during their presence in the SOC including documentation and measurement of all subordinate procedures as well as the continual improvements to them.  As the senior analysts on a shift, SOC Level 2 Analysts have final decision authority for escalation of Incidents inside the SOC and will serve as senior mentor to SOC Level 1 staff.\r\n\r\nAdditionally, the SOC Level 2 Analyst(s) will:\r\n\r\n- Track tactical issues in execution of SOC responsibilities\r\n- Monitor Level 1 Analyst performance investigating incoming Incidents using SOC-available tools.\r\n- Ensure SOC Triage Tagged Incidents are addressed in a timely manner using available reporting and metrics.\r\n- Investigate Level 1 escalated Incidents.\r\n- Mentor Level 1 Analysts to improve detection/analytical capabilities within the SOC.\r\n- Manage SOC event and information intake to include gathering intelligence reports, monitoring ticket queues, investigating reported incidents, and interacting with other security and network groups as necessary.\r\n- Coordinate with SIEM Engineers to tune Alerts and Events.\r\n- Serve as shift subject matter experts on incident detection and analysis techniques providing guidance to junior analysts and making recommendations to organizational managers.\r\n- Drive and monitor shift-related metrics processes ensuring applicable reporting is gathered and disseminated per SOC requirements. \r\n\r\nFinally, the Information Fusion Procedure, where various data inputs are fed to both operations and engineering is primarily driven by the assigned Level 2 Analysts.  These senior analysts will gather information, organize it into an accessible format and ensure its full dissemination.\r\n\r\n### SOC Level 3 Analyst\r\nA Level 3 Analyst is a subject matter expert responsible for managing threats, disseminating information, and handling, responding to, and investigating all incident escalations from the CUSTOMER Security Operations Center.  Level 3 team members are responsible for coordinating with the CUSTOMER CSIRT process when necessary, and managing incidents throughout the event life-cycle. Level 3 team members will further an investigation and ensure root cause and resolution for metrics, tracking, lessons learned are compiled, documented and disseminated in conjunction with the CIRT process.\r\n\r\nThey will provide insight and expertise to examine malicious code (malware), attack vectors, network communication methods, analyze threats against target systems and networks, determine target network capabilities and vulnerabilities, support development and maintenance of new tools and techniques to exploit specific targets, and produce technical after-action reports in support of the SOC. Level 3 members will be the focal point for critical security Alert, Events and Incidents and will serve as subject matter experts in providing recommendations to the SOC Incident Manager and other members of Information Security and IT management for escalation and remediation.\r\nLevel 3 Analysts are also responsible for training and mentoring their Level 2 peers in order to improve SOC Analyst capability.  Finally, Level 3 members will work with the SIEM Engineers to develop and refine use cases within Azure Sentinel focusing on emerging threats.\r\n\r\n### Cyber Intelligence Analyst\r\nThe Cyber Intelligence Analyst role is responsible for intelligence collection, analysis, and dissemination for use in development of specific cyber monitoring capabilities. The Intelligence Analyst conducts research and develops/delivers timely recommendations to the SOC Analysts, incident responders, and SIEM engineers. The analyst will research adversary tactics, techniques, and procedures to determine patterns in network or system activity and associated malware. They will coordinate closely with security engineers and Second Line Intelligence peers to make changes to security tools to detect the latest threats.\r\n\r\nThe Cyber Intelligence Analyst will also:\r\n\r\n- Maintain relationships with the CUSTOMER Corporate Information Security intelligence peers, Industry peers, and law enforcement community to be able to leverage information sharing networks\r\n- Perform proactive research to identify and characterize new emerging threats, vulnerabilities, and risks\r\n- Brief executive management on current threat landscape in written or oral communication\r\n- Develop actionable intelligence to drive countermeasure development\r\n- Share operational threat intelligence with SOC Analyst peers\r\n- Work closely with security analysts to get direct feedback about new, unknown suspicious behavior, and indicators\r\n- Research, analyze, and synthesize large amounts of data and information.\r\n- Work closely with content & policy engineers to provide information on detection pattern for new upcoming threats.\r\n- Participate in an on-call rotation\r\n\r\n### Manager – Incident Response\r\nThe Manager – Incident Response is responsible for leading the IR effort of the SOC.  This role engages with other First Line and Second Line teams to define incident response processes \r\n\r\nIn addition, the Manager – Incident Response will:\r\n\r\n- Ensure security incidents are tracked and documented.\r\n- Interface with other SOC and outside teams. \r\n- Execute continuous process improvement.\r\n- Manage the process improvement program for SOC IR processes.\r\n- Ensure senior management aware of any issues or incidents. \r\n- Lead root cause analysis and post-mortem dialogue after significant Incidents to capture lessons learned and define process or technology improvements\r\n\r\n### Incident Response Analyst\r\nAn Incident Response Analyst is a subject matter expert responsible for managing threats, disseminating information, and handling, responding to, and investigating all incident escalations from the CUSTOMER SOC. Incident Response Analysts are responsible for coordinating with the CUSTOMER Corporate Information Security (CIS) process when necessary, and managing incidents throughout the event life-cycle. Incident Response Analysts will further an investigation and ensure root cause and resolution for metrics, tracking, lessons learned are compiled, documented and disseminated in conjunction with the CIS process.\r\n\r\nThey will provide insight and expertise to examine malicious code (malware) alerts, attack vectors, network communication methods, analyze threats against target systems and networks, determine target network capabilities and vulnerabilities, support development and maintenance of new tools and techniques to exploit specific targets, and produce technical after-action reports in support of the SOC. Incident Response Analysts will be the focal point for critical security Alerts, Events and Incidents and will serve as subject matter experts in providing recommendations to the SOC Incident Manager and other members of Information Security and IT management for escalation and remediation.\r\n\r\nIncident Response Analysts are also responsible for training and mentoring their Security Analyst peers in order to improve SOC analyst capability. Finally, Incident Response Analysts will work with the SIEM Engineers to develop and refine use cases within Azure Sentinel focusing on emerging threats.\r\n\r\n### Forensic Analyst / Investigator\r\nThe Forensic Analyst is responsible for the development and maturity of the forensic and investigations program within the CUSTOMER organization. The Forensics Analyst performs a variety of highly technical analyses and procedures dealing with the collection, processing, preservation, analysis, and presentation of computer related evidence. They will examine malicious code (malware), attack vectors, and network communication methods, and analyze against target systems and networks, determine target network capabilities and vulnerabilities, support development and maintenance of new tools and techniques to exploit specific targets, and produce technical, after-action reports in support of the CUSTOMER. \r\n\r\nAdditional responsibilities include: \r\n\r\n- The Forensic Analyst/Investigator will conduct forensics analysis on systems and ensure root cause and resolution for metrics, tracking and lessons learned are compiled, documented and disseminated. \r\n- Use of forensic tools and investigative methods to find specific electronic data, including internet use history, processing documents, images, and other files. \r\n- The Forensic Analyst is responsible for disseminating and reporting cyber-related activities, conducting vulnerability analyses, conducting risk management of computer systems and recovering information from computers and data storage devices. \r\n- Analyze and review escalated cases until closure; this includes investigating and recommending appropriate corrective actions for data security incidents which includes communicating with the implementation staff responsible. \r\n- Perform post mortem analysis on logs, traffic flows, and other activities to identify malicious activity. \r\n- Research, develop, and keep abreast of testing tools, techniques, and process improvements in support of security event detection and incident response. \r\n- Reverse engineer and analyze binaries, files, and other malicious attack artifacts. \r\n- Establish, maintain and ensure complete chain of custody of forensic evidence. \r\n- Recovers and examines data from computers and other electronic storage devices in order to use the data as evidence in criminal prosecutions. \r\n- When equipment is damaged, the forensic analyst must dismantle and rebuild the system in order to recover lost data. \r\n- Analyst writes up technical reports detailing how the computer evidence was discovered and all of the steps taken during the retrieval process. \r\n- The Analyst also gives testimony in court regarding the evidence he or she collected. The Analyst keeps current on new methodologies and forensic technology, and trains law enforcement officers on proper procedure with regard to computer evidence. \r\n- The Forensic Analyst will contribute to the design and development of innovative research projects and attend and participate in professional conferences to stay abreast of new trends and innovations in the field of information systems and/or cyber security. \r\n- This expert is not only proficient in the latest forensic response and reverse engineering skills, but is astute in the latest exploit methodologies. \r\n- He/she will provide significant input into the design and development of the organizations working information security systems operations and maintain strategy and methodology to comply with the organization’s cyber security standards and mission. \r\n\r\n### SIEM Engineer/Content Developer \r\nThe SIEM Engineer is primarily responsible for the administration, apps & infrastructure, playbooks,azure functions, i.e. architecture, configuration and analytic (KQL) performance within Azure Sentinel. The engineer performs all administration, development, management, configuration, and testing tasks related to Azure Sentinel. SIEM Engineers will be responsible for content development including reports, dashboards, analytic (KQL) rules, filters, and metrics. The SIEM Engineer also develops, implements, and executes standard procedures for the \"front-end\" operation within Azure Sentinel. The SIEM engineer will also communicate with the SOC Manager and Analysts to optimize the KQL (analytics) performance to better meet the needs of the SOC.\r\n\r\nOther duties include:\r\n\r\n1. Developing, implementing, and executing standard procedures for the administration, backup, disaster recovery, and operation of Azure Sentinel including:\r\n\t- Operating system security hardening (vms, azure monitor connectors)\r\n\t- Backup management (azure storage, Azure Data Explorer, other)\r\n\t- Capacity planning (Long-term/Short-term storage)\r\n\t- Change management (Analytic(Detections)/Workbooks/Playbooks/Notebooks versioning)\r\n\t- Version/patch management (vms for azure monitor connectors)\r\n\t- Lifecycle upgrade management\r\n2. Tune Azure Sentinel KQL performance and event data quality to maximize Azure Sentinel efficiency and assists with Data Source correlation using Azure Sentinel.\r\nAdditionally, the SIEM Engineer is responsible to ensure all Azure Sentinel components perform as expected meeting established service level objectives for optimal system uptime.\r\n \r\n### Cybersecurity Data Scientist\r\nThe Cybersecurity Data Scientist role is responsible for design, development, and support of advanced security analytics within the CUSTOMER environment using big data technology solutions.   This role interfaces directly with the intelligence, forensics, and analysis teams. This role will involve working directly with security leaders throughout the CUSTOMER organization to develop solutions to complex predictive analytic problems involving diverse input data sources including real-time data. This role works alongside a team of Hadoop engineers to develop theories using security data, analyze the requirements of our stakeholders and provide expertise in a complex technical environment. The role provides expertise in exploratory data analysis, pattern discovery and advanced analytical techniques to anticipate or detect undiscovered threats as well as aid in historical search for forensic response situations. The role uses LogAnalytics/Azure ML and other Big Data tools to accomplish the applicable tasks.\r\n\r\n### Responsibility Chart\r\n\r\nRACI is an acronym for the four major headings in a responsibility chart:\r\n\r\n| Role | Individual |\r\n| : | : |\r\n| Responsible | Individual or group actively working to achieve the task. This group reports to the individual Accountable for the completion of the task to verify scope and successful completion. |\r\n| Accountable | Individual or group responsible for the completion of a given phase/task. |\r\n| Consulted | Individuals who provide consulting input into the phase/task. The opportunity for the two way communication is provided to the consulted group. |\r\n| Informed | Individuals who are informed of the progress of the phase/task. One way communication is provided to individuals in the informed group. |\r\n\r\n### RACI Matrix\r\n\r\n| Phase/Role | Director - Security Operations | Manager - Security Analysis | Level 1 & Level 2 Analyst | Level 3 Analyst | Cyber Intelligence Analyst | Manager - IR | IR Analyst | Cybersecurity Data Scientist | Forensic Analyst/Investigator | Business Unit Management Teams |\r\n| : | : | : | : | : | : | : | : | : | : | : |\r\n| Watch/Monitor | A | A | R | I | I/C | I | - | - | - | - |\r\n| Investigation | A | A | R | R | I/C | C | A/C | - | C/R | I |\r\n| Assess & Contain | A | A | I | R | I/C | C | A/C | - | C/R | I/A |\r\n| Remediate & Recover | A/C | A/C | I | I | I/C | A/C | A/C | C | C/R | I/A |\r\n| Post Mortem | A/C | A/C | I | I | I/C | A/C | A/C | C | C/R | I/A |\r\n",
        "style": "info"
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Roles and Responsibilities"
      },
      "customWidth": "75",
      "name": "SOC Roles and Responsibilities"
    },
    {
      "type": 1,
      "content": {
        "json": "# SOC Incident Response Procedures\r\n\r\n## Summary\r\n\r\n<strong>What is an Incident?</strong> An incident is defined as a series of events that may compromise the integrity of a large number of systems, multiple organizational zones or networks resulting in catastrophic data loss, prolonged organizational downtime, or major financial impact. The CUSTOMER Security Operations Center organization will continuously work throughout the Incident Response process as a core component of conducting security monitoring and analysis. \r\n\r\nThe IR process describes the activities conducted throughout each response phase. The IR process enables the SOC to transition from each phase in an operationally sound manner, involving analysis, triage, case management, and escalation and ultimately engaging the CUSTOMER Incident Response Team (CUSTOMER -IRT) upon critical/urgent incidents which may impact the business and operations of the Organization, or Business Areas/Units.\r\n\r\n## Purpose\r\nThe purpose of this process is to provide the SOC Analysts with detailed procedures for the handling of all events or incidents that occur within the CUSTOMER Enterprise. Incidents can be categorized as one of the following:\r\n - Any malicious event (hack, leak, breach, compromise, etc.) to IP, PII, confidential data, digital assets, or any element of the network or the digital assets that can be accessed by it. \r\n - Any violation of security or corporate policy by anyone granted legitimate access including vendors, partners, full-time employee (FTE), contingent staffing groups (CSG), guests, interns, contractors, etc. \r\n - Any malicious event resulting in loss or compromise to any IP, PII, confidential data, digital assets or the network (or anything connected to it) caused by anyone granted access to that asset, or who gained access to it through a malicious act (virus, malware, hack, breach, worm, etc.). The daily process and procedures executed by the SOC with this IR process demonstrates how the organization addresses and manages security incidents.\r\n\r\n\r\n## Incident Response Decision Matrix\r\n\t\r\n| IR Decision Matrix |\r\n| : | : | : | : | : |\r\n| Category | Description | Single Workstation | Multiple Workstations / Single HVT / Single HRT | Multiple HVTs / Multiple HRTs |\r\n| Reconnaissance | This category involves the initial communications from a source (external or internal) to a target host.  Common examples of this traffic is scanning activity.  | SEV-3 | SEV-3 | SEV-3 |\r\n| Attack/Delivery | This category involves the delivery/transmission of malware.  For example Phishing, USB Drives, websites hosting malicious content, etc. | SEV-3 | SEV-2 | SEV-1 |\r\n| Host Exploitation | This category involves the possibility or probability than an attempt to deliver malware was successful.  For example AV, IDS, or other security tools events. | SEV-3 | SEV-2 | SEV-1 |\r\n| Binary Installation | This involves advanced attack vectors not monitored by conventional security tools.  For example, additional registry settings, increasing or unidentified windows processes, security tools services terminated, and etc. | SEV-3 | SEV-3 | SEV-2 |\r\n| C2 | This category involves an internal device possibly beaconing out to a control server.  For example firewall logs indicating attempts from internal devices to IP’s identified as currently or at some point in the past, identified with malware. | SEV-3 | SEV-2 | SEV-1 |\r\n| Local Compromise | This category involves the creation of local accounts, privilege escalation, compromise of existing local accounts, unapproved changes made to group policies, unapproved permission changes for file and folder access, and the use of common command line tools in Windows and Unix. | SEV-2 | SEV-2 | SEV-1 |\r\n| Internal Recon | This category involves a compromised host profiling the network for other vulnerable targets which may suggest the use of active security tools such as netcat or is possibly a vulnerability scanner. | SEV-2 | SEV-2 | SEV-1 |\r\n| Lateral Movement | This category involves the movement from the compromised host to other hosts.  Examples in this area look for such events like net login, remote registry, remote WMI communications, remote group policy editor and remote session communications such as file share access, RDP, SSH, HTTP. | SEV-2 | SEV-2 | SEV-1 |\r\n| Established Persistence | This category includes any activity that attackers may use to maintain their presence on a compromised network.  Examples of this behavior are newly spawned communication services between internal hosts, such as HTTPS, between servers that should not provide this service; common unknown processes being found on multiple hosts; and new binaries being added to the compromised host. | SEV-2 | SEV-2 | SEV-1 |\r\n| Stage & Exfiltration | This category involves an attacker taking active steps to steal and exfiltrate data.  Examples of this activity are spikes in normal network traffic, or any other anomalous traffic that deviates from expected network traffic. | SEV-2 | SEV-2 | SEV-1 |\r\n| Business Process | This category involves health events, testing, misconfigured devices, normal business ops. etc. | SEV-4 | SEV-4 | SEV-4 |\r\n| Policy Violation | This category involves user behaviors associated with Policy Violations. | SEV-4 | SEV-4 |SEV-4 |\r\n\r\n\r\n## Scope\r\nThis process applies to all incidents that are presented to all SOC Analysts and also applies to the CUSTOMER's Incident Response Team tasked with monitoring, response and escalation.\r\n\r\n### Definitions\r\n\r\n- A <strong>Security Event</strong> is a change in the everyday operations of an asset/device (i.e. workstation, or server), network or information technology service, indicating that a security policy may have been violated or a security safeguard may have failed. \r\n- A <strong>Security Alert</strong> is a correlation of Security Events together that identify a Security Risk.\r\n- A <strong>Security Incident</strong> is defined as a series of events that may compromise the integrity of a large number of systems, multiple organizational zones or networks resulting in catastrophic data loss, prolonged organizational downtime, or major financial impact.\r\n- A <strong>High-Value Target (HVT)</strong> is a person or asset that an attacker/intruder is attempting to exploit for person gain.\r\n\t- Assets which may contain Personally Identifiable Information (PII), Protected Critical Infrastructure Information (PCII), Intellectual Property (IP), Application and/or Development Source Code/Builds, or Electronic Transactions such as Credit Cards, or Stock trades. \r\n\t- Persons who may have business/company plans such as future acquisitions, new or emerging products/services, competitive product or service pricing and licensing.\r\nThe objective of the SOC is to prioritize events where the High Value Assets are either the target or the source of the alert to conduct further analysis and investigation.\r\n- <strong>Personal Identifiable Information (PII)</strong> is defined as any information that can be used to distinguish or trace an individual‘s identity,such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information. PII data can be sensitive or non-sensitive.\r\n- <strong>Payment Card Industry (PCI)</strong>PCI can be described as a set of security standards that were developed to protect card information during and after a financial transaction.\r\n- <strong>Sarbanes-Oxley (SOX)</strong> compliance is best defined as legislation that was passed by the U.S. Congress to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprise, as well as improve the accuracy of corporate disclosures.\r\n\r\n## Severity Definitions\r\n\r\n| Severity 1 (Critical) |\r\n| : | : |\r\n|   | <strong>Critical Compromise, Major Service disruption or publicly displayed attack</strong> |\r\n|   | - Mission critical systems that support multiple businesses (systems defined as mission critical per Ops/Tech) OR sectors of the critical infrastructure (systems defined as Tier 0 for BCP/DR purposes) <br> - CUSTOMER has experienced a substantial loss of service and/or revenue <br> - Prevents CUSTOMER from making sales, or meeting legal or contractual obligations <br> - Potential regulatory fines or penalties <br> - Critical business impact to the company; competitive edge, reputational, data-privacy breach <br> - All or a substantial portion of CUSTOMER's mission critical data is at a significant risk of loss or corruption <br> - CUSTOMER business operations have been severely disrupted <br> - Potential large financial risk or legal liability <br> - Multiple systems (HVT), significant number of workstations, groups and users affected; high probability of propagation <br> - Mission critical system (e.g., payroll system) to a single business <br> - Significant and immediate threat to human safety <br> - Complete system compromise and possible full data-privacy breach <br> - Law Enforcement assistance is required <br> - Severity 2 events that are not resolved within the established Service-Level Agreements (SLAs) <br> |\r\n|   | <strong>Examples:</strong> |\r\n|   | - Unauthorized access to sensitive systems (HR, Payroll, Finance, etc) <br> - Distributed Denial of Service Attacks or DoS Attacks <br> - Theft of computer systems and/or media containing sensitive/confidential information <br>\t- Malware causing destructive outbreak to a large number of workstations or servers (Zero day attacks) <br>\t- Defacement of CUSTOMER Web Sites <br> - Vulnerability on an CUSTOMER transactional server or subnet |\r\n\t \r\n| Severity 2 (Major) |\r\n| : | : |\r\n|   |<strong>Serious Impact or Compromise, Incident/Attack affects multiple organizations/customers</strong> |\r\n|   | - Operations can continue in a restricted fashion, although long-term productivity might be adversely affected <br> - Organization has lost the ability to provide a critical service to a subset of system users <br> - Single High Value Targets affected or potentially compromised <br> - Impact to company confidential data <br> - Major or business-critical applications are affected <br> - Multiple systems that contain PII or PCI and/or users affected <br> - Critical impact to the organization (reputational) <br>- Severity 3 events that are not resolved within the established Service-Level Agreements (SLAs) |\r\n|   |<strong>Examples:</strong> |\r\n|   | - Improper usage of high-level accounts such as root or administrator <br> - Phishing threats to compromise internal, sensitive data <br> - Vulnerability on a CUSTOMER non-transactional server or subnet <br> - Multiple users/workstations infected by malware <br> - Unauthorized disclosure of CUSTOMER internal or confidential information (i.e. email, blogs, news groups) <br>\t- Spear-phishing attempts targeting CUSTOMER executives <br> - Internal web site was compromised without authorization |\r\n\r\n| Severity 3 (Moderate) |\r\n| : | : |\r\n|   |<strong>Intermittent security alerts, moderate security impact</strong> |\r\n|   | - Non-critical systems (e.g., associate workstations), OR Non-critical infrastructure; internal impact is less than 5% <br> - Medium Severity, typically issues such as policy violations, single system infections and/or whereas the malicious code is known and contained <br> - Escalation directly to the respective Business Unit for remediation <br> - Severity 4 events that are not resolved within the established Service-Level Agreements (SLAs) |\r\n|   |<strong>Examples:</strong> |\r\n|   | - Isolated reconnaissance activities (network) by potential attackers <br> - Password policy violation by an employee <br> - Virus/Malware infection isolated to an individual user <br>\t- Single report of suspicion that someone has gained unauthorized access to his/her/their account <br> - Phishing/spear-phishing threat to compromise customer data <br> - Detection and removal of viruses by a server before it enters the network <br> - Repeated port scanning from same external source |\r\n \r\n| Severity 4 (Minor) |\r\n| : | : |\r\n|   |<strong>Informational, some security impact</strong> |\r\n|   | - Non-critical systems (e.g., associate workstations), OR Non-critical infrastructure <br> - No effect to the organization’s ability to provide all services to all users <br> - No breach of data / information was exfiltrated, changed, deleted, or otherwise compromised <br> - Single systems and/or users affected that contains PII or PCI <br> - Minimal recovery required <br> - Escalation directly to the respective Business Unit for remediation |\r\n|   |<strong>Examples:</strong> |\r\n|   | - Receipt of e-mail expressing “low-level” threat <br> - Discovery of a Phishing event without report of compromise |\r\n\t\t\t \r\n\r\n\r\n## Incident Response Methodology\r\n \r\n### Incident Preparation\r\nIncident response methodologies typically emphasize preparation—not only establishing an incident response capability so that the organization is ready to respond to incidents, but also preventing incidents by ensuring that systems, networks, and applications are sufficiently secure. The SOC should have preparatory measures to ensure that they can respond effectively to security events/incidents. All documentation should be updated/maintained in the SOC Knowledge Base (Wiki, OneNote).\r\n\r\nRecommended actions include:\r\n- Maintain Contact information for team members and others within and outside the organization (primary and backup contacts)\r\n- Maintain escalation procedures (phone numbers & email addresses)\r\n- Assist with maintaining IRT documentation\r\n- Have a War Room available\r\n \r\n### Watch / Monitor Phase (Detection)\r\nThe SOC group should strive to detect and validate security events and incidents rapidly because infections can spread through an organization within a matter of minutes. Early detection can help an organization minimize the number of infected systems, which will lessen the magnitude of the recovery effort and the amount of damage the organization sustains.\r\n\r\nSTART --> Create / Monitor Azure Sentinel Livestream --> Elevate Livestream to Analytic/Detection --> Fires Alert and Creates an Incident\r\n\r\n![Watch and Monitor](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/Watch_and_Monitor.png?raw=true)\r\n\t \r\n### Investigation Phase \r\nA SOC Analyst needs to determine what action to take based on Incidents observed within Azure Sentinel. Triage is the process of evaluating multiple events 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![Investigate](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/IncidentTraigeWorkflow.png?raw=true)\r\n\t \r\n#### Determine Category Type & Action Needed\r\nThe SOC Analyst should apply the decision matrix below using the Category Type and asset priority. This is used in conjunction with the SOC Response Procedures for the rule triggered. The severities defined below are based on adaptations from the CUSTOMER Company Threat Matrix. \r\n\r\n#### Analysts also need to note the following:\r\n- If there is a fast spreading new worm or virus do an immediate callout and include SOC management \r\n- If any security device (FW, IDS/IPS sensor, Web Proxy) fails, notify engineers via Remedy for instructions. \r\n- If traffic appears to be part of a vulnerability scan or penetration test, check the Vulnerability Scan Scheduling page for verification.\r\n\t \r\n### Initiate Action\r\nThe Analysts should initiate appropriate response action based on the outcome of the decision matrix above. If any particular Alert/Incident is dismissed, Analysts should follow Azure Sentinel's Incident Procedures.\r\n- <strong>SEV-1</strong> = Annotate the Incident/Alert and initiate the Critical Call out Procedures with a response time requirement of 15 minutes.\r\n- <strong>SEV-2</strong> = Annotate the Incident/Alert and initiate the Urgent Call out Procedures with a response time requirement of 30 minutes.\r\n- <strong>SEV-3</strong> = Annotate Incident/Alert. Work Incident internally, if a callout is needed promote case to a SEV-2. Azure Sentinel Incidents created will be under the Incident schema\r\n- <strong>SEV-4</strong> = Annotate Incident/Alert. Low priority, work internally, if callout is necessary, promote case to a SEV-2. \r\n\t\t \r\nOnce the SOC Analysts suspects a security event or an incident is occurring or has occurred and has been deemed actionable, it is important to immediately begin documentation of all facts related to that event. Every task completed from initial identification of an event until final resolution, should be documented in detail and time-stamped. \r\n\t\t\r\nThe SOC will open an Azure Sentinel Incident in the Azure Sentinel Incident Blade. At a minimum, the following should be documented in this case: \r\n- Current Status of the Alert/Events or the incident\r\n- Type of Alerts/Events or Incident (e.g., disruption of service, malicious code, unauthorized access, inappropriate usage) \r\n- Full name of the Analyst (will retain case ownership) \r\n- Summary of the event or incident\r\n- Contact information for all involved parties (e.g., system owners, system administrators) \r\n- List of all pertinent logs and technical information gathered \r\n- Cause of the event / incident (e.g., misconfigured application, unpatched host) \r\n- Business impact of the event\r\n- Actions Taken by all SOC Analyst(s) or Incident Response Team\r\n- Contact Information for Other Teams Involved \r\n- Notes/Comments from other Incident Handlers \r\n- Next Steps/Actions to be Taken (e.g., Waiting for system to be re-imaged, waiting for system patch to be applied to vulnerable system) \r\n\t\t\t\t\r\n#### Incident Information\r\nIt has been identified that a standard set of incident related data fields need to be collected for each incident. This will not only facilitate more effective and consistent incident handling, but also assist the organization in meeting applicable incident reporting requirements. The list below provides information to be collected for all incidents. These are not intended to be comprehensive, and more/less information will be collected based on the specific context of the incident.  \r\nIncident Details\r\n- Log of actions taken by all handlers \r\n- Date/time (including time zone) when the incident was discovered \r\n- Estimated date/time (including time zone) when the incident started \r\n- Type of incident (e.g., denial of service, malicious code, unauthorized access, inappropriate usage) \r\n- Physical location of the incident (if known) \r\n- Source/cause of the incident (if known), including hostnames and IP addresses \r\n- Description of the incident (e.g., how it was detected, what occurred) \r\n- Operating system, version, patch level and installed software \r\n- Documentation of all gaps identified during the incident handling. For instance, missing asset information, delivery time of supportive departments, etc. \r\n- Endpoint Threat Protection installed, enabled, and up-to-date (yes/no) \r\n- Description of affected resources (e.g., networks, hosts, applications, data), including systems’ hostnames, IP addresses, and business function \r\n- Estimated technical impact of the incident (e.g., data deleted, system crashed, application unavailable) \r\n- Response actions performed (e.g., shut off host, disconnect host from network) \r\n- Other organizations contacted (e.g., software vendor) \r\n- If any PII was compromised during the incident, what type of PII was it? \r\n- Do the affected systems contain any sensitive data (i.e. PII, PCI or SOX)?\r\n\r\nSigns of an incident that can be categorized as indicators and precursors. \r\n- Precursors are signs that an incident may occur in the future.\r\n- A threat from a hacktivist group stating the group will attack CUSTOMER or CUSTOMER’s customers \r\n\t- An announcement of a new exploit that targets vulnerable CUSTOMER's servers \r\n\t- Web server log entries revealing unauthorized Web vulnerability scanning \r\n\t- Upcoming termination of a CUSTOMER's employee or contingent worker \r\n- Indicators are signs that an incident may have occurred or is actively occurring. \r\n\t- Network IDS/IPS sensor alerts when a buffer overflow attempt occurs against an CUSTOMER server \r\n\t- Endpoint Threat Protection software alerts after detecting malware on a host \r\n\t- Web Server crashes \r\n\t- User complaints regarding poor network connectivity \r\n\t- System Administrator identifies suspicious executable on a CUSTOMER server \r\n- Business Criticality: This analysis will consider potential financial, brand, customer and service impact as the primary criteria for incident prioritization. \r\n\t- Considerations: \r\n\t\t- What is the business purpose of each of the systems that are involved in the incident, attacker and target? \r\n\t\t- Do these systems host a business critical application or are they in the same network zone with systems that are business critical? \r\n\t\t- Do the involved systems store or transmit PCI or PII data?\r\n\r\n### Continue to Monitor Activity\r\nIf necessary, initiate the Focused Monitoring procedures in support of other teams. Using the Focus Monitoring Procedure to initiate a LiveStream to watch for ongoing Alerts or Events as they occure.\r\n\t\r\n### Document Activity in the Shift Log\r\nDocument all activity (including false positives) in the Shift Log using the Shift Log Management guidelines.\r\n\r\n### Follow Up on Activity\r\nEnsure that the appropriate response action is fully executed and the ticketing and closure procedures are completed.\r\n\r\n## Service Level Objectives (SLOs)\r\n\r\nWithin the SOC, several metrics are reported weekly to management.  As part of this process service level objectives must be defined, measured and reported.  A service level objective (SLO) is a key element of a service level agreement (SLA) between a service provider and a customer. While incidents may vary in the length of time needed to resolve, there are several metrics that can be defined.\r\n\r\n### General goals:\r\nEvent annotation – All SOC Analysts will review every Incident in the Incident Blade within Azure Sentinel within 15 minutes of the Alert/Incident receipt time during normal business hours.  All events from off hours will be analyzed within 4 hours of an analyst coming on duty.\r\n\r\n### Incident management goals:\r\nIncident Triage – All Incidents in \"Open or Active\" in the Incidents blade of Azure Sentinel will be triaged within 15 minutes of them being created and moved into the Secondary Analyst structure.\r\n\r\nInvestigations will be started on all Incidents within the following times based off of their priority: (All times are assuming business hours)\r\n- <strong>Severity 1: Immediately</strong>\r\n- <strong>Severity 2: Within 10 minutes of triage</strong>\r\n- <strong>Severity 3: Within 60 minutes of triage</strong>\r\n- <strong>Severity 4: Within 24 hours of triage</strong>\r\n\r\n## Remediation SLOs\r\n\r\n| Incident Severity Table |\r\n| : | : | : |\r\n| Description |\tScope |\tSystem Criticality |\r\n| Severity 1 – Critical | Pervasive | Critical |\r\n| Severity 2 - Major | Wide | High |\r\n| Severity 3 – Moderate\t| Significant |\tMedium |\r\n| Severity 4 – Minor | Narrow | Low |\r\n\t\r\n- <strong>Severity 1 (SEV-1)</strong> – A Severity 1 Incident is worked as the matter of highest Severity until completely resolved. These cases are often handled with a war room response and can require a round the clock response. \r\n- <strong>Severity 2 (SEV-2)</strong> – A Severity 2 Incident is worked as a matter of high Severity until completely resolved. These are handled at any time of the day or night as they are detected or reported, but after initial triage may be delayed until business hours if appropriate. \r\n- <strong>Severity 3 (SEV-3)</strong> – A Severity 3 Incident is worked urgently during business hours until resolved. \r\n- <strong>Severity 4 (SEV-4)</strong> – A Severity 4 Incident is worked best effort on business days until resolved.\r\n\r\n\r\n## Notification SLOs\r\n\r\n| Severity | Who | When | How |\r\n| : | : | : | : |\r\n| Sev-1 | - ALL SOC Analysts <br> - IR Team <br> - SOC Manager <br> - Director of IT Security <br> - CISO | <strong>First Notification:</strong> Immediately <br> <strong>Subsequent notifications:</strong> 15 minutes or as announced | Teams <br> Teams / Phone & Encrypt Email <br> Teams / Phone & Encrypt Email <br> Encrypted Email <br> Teams WarRoom / Phone|\r\n| Sev-2 | - ALL SOC Analysts <br> - IR Team <br> - SOC Manager | <strong>First Notification:</strong> 10 Minutes <br> <strong>Subsequent notifications:</strong> 30 minutes or as announced | Teams <br> Teams <br> Teams |\r\n| Sev-3 | - ALL SOC Analysts <br> - SOC Manager | <strong>First Notification:</strong> 60 minutes <br> <strong>Subsequent notifications:</strong> Daily or as announced | Teams <br> Teams |\r\n| Sev-4 | - ALL SOC Analysts | <strong>First Notification:</strong> 24 Hrs <br> <strong>Subsequent notifications:</strong> Daily or as announced | Teams |\r\n\r\n\r\n### Dependencies within the Organization\r\n\r\nIt is important to identify other groups within this organization that may be needed to participate in incident handling so that their cooperation can be solicited before it is needed. Every incident response team relies on the expertise, judgment, and abilities of others, including:\r\n\r\n- Management: Management invariably plays a pivotal role in incident response. In the most fundamental sense, management establishes incident response policy, budget, and staffing. Ultimately, management is held responsible for coordinating incident response among various stakeholders, minimizing damage, and reporting. Without management support, an incident response team is unlikely to be successful. \r\n- Cyber Security: Members of the information security team are often the first to recognize that an incident has occurred or is occurring and may perform the initial analysis of incidents. In addition, information security staff members may be needed during other stages of incident handling—for example, altering network security controls (e.g., firewall rules) to contain an incident. \r\n- IT Support: IT technical experts (e.g., system administrators, network administrators, and software developers) not only have the needed technical skills to assist during an incident but also usually have the best understanding of the technology with which they deal on a daily basis. This understanding can facilitate decisions such as whether to disconnect an attacked system from the network.\r\n\r\n## Additional IR Phases\r\n\r\n### Mobilize\r\nDuring the Mobilize phase, the CUSTOMER Security Operations Center will engage the SOC Manager, the Incident Manager and members of the Incident Response Team (Level 3) if a critical incident or any event that has been escalated from all SOC Analysts that has occurred. Additionally, they will provide all of the pertinent information that was gained from the previous phases. \r\n\r\nThe SOC-IM will reassess the severity/criticality of the incident prior to mobilization of the IRT. The SOC-IM will own and manage the incident moving forward. First, the SOC-IM will prepare an incident summary to inform the IRT and the senior management team that an incident has occurred and that the IR plan has been enacted. \r\n\r\nNext, the SOC-IM will determine whether additional information or coordination with external teams is required. If all information gathered confirms the occurrence of a high severity incident, then the SOC-IM will notify the IRT and open a communications line to coordinate efforts.\r\n\r\nAn incident response team is typically composed of the SOC-IM and IRT; IT operations, network operations, business stakeholders, and executive management. In some instances, legal and public relations (PR) organizations will also collaborate as necessary.\r\n\r\n![Mobilize](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/Mobilize.png?raw=true)\r\n\r\n### Assessment and Containment\r\n\r\nAn incident may need to be contained and/or quarantined to keep it from spreading and to prevent further damage or loss from occurring. During this phase, efforts should be taken to keep potential evidence intact, while balancing the need of the system owner and the incident investigator. In some cases, it may be necessary to either remove the system from the attacker’s ability to access it, or to contain it in some way that is not detectable. Failure in this regard can result in serious damage to the system and related infrastructure as the attacker recognizes the actions you are taking. It is important to consider that some attacks may cause additional damage when contained and/or quarantined, so the SOC should not assume that because a host has been removed from the network, further damage to the host has been prevented.\r\n- Containment Considerations:\r\n\t- Is the incident currently on-going? \r\n\t- What is the business impact?\r\n\t- Is stolen information stored on the compromised system? If so this system may be monitored by the attacker and there may be automated routines to delete evidence which would likely destroy the system. \r\n\t- What is the production impact if you pull the network cable or remove the system from production status? \r\n\t- Does the containment strategy affect our ability to preserve evidence? \r\n\t- What effect does the strategy have on service availability (e.g., network connectivity, services provided to external parties)? \r\n\t- What amount of time and resources are needed to implement the strategy? \r\n\t- What is the effectiveness of the strategy (e.g., partial containment, full containment)?\r\n\t- What is the duration of the solution (e.g., emergency workaround, temporary workaround, permanent solution)?\r\n\r\n![Assess and Contain](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/Assess_and_Contain.png?raw=true)\r\n\r\n\t\r\n## Technical Root Cause Analysis \r\n\r\n### Purpose: \r\nThe purpose of the technical root cause analysis is to determine the mechanism of attack, the modus operandi (M.O.) of the attacker and the extent of the compromise within the CUSTOMER Enterprise. \r\n- Task 1 - Gather all technical information needed to research the details of the incident. \r\n\t- Potential Technical Information to Review:\r\n\t\t- Operating system logs (Windows/*NIX)\r\n\t\t- Firewall logs \r\n\t\t- Router logs \r\n\t\t- Application logs \r\n\t\t- Proxy logs\r\n\t\t- IDS/IPS logs\r\n\t\t- Endpoint Threat Protection logs\r\n\t\t- DLP logs\r\n\t\t- The image of any virtual servers \r\n\t\t- Network packet captures \r\n\t\t- Any other information as discovered in the course of the investigation. \r\n\t- Obtain digital evidence from Windows Systems \r\n\t- Obtain digital evidence from Unix/Linux Systems  \r\n- Task 2 - Conduct a thorough technical review of collected technical information to determine the mechanism of the attack. \r\n\t- Analyzing Unknown Binaries with Bit9 and/or Carbon Black \r\n\t- Conducting Basic Static/Dynamic Malware Analysis with a known good Sandbox\t \r\n- Task 3 - Review of the sequence and context of the attack to understand the Modus Operandi of the attacker. \r\n- Task 4 - Review peer and similar systems to identify if more systems involved in the incident. \r\n- Task 5 - Identify and document any systemic weaknesses observed within the CUSTOMER Enterprise network.\r\n\r\n### Remediation & Recovery\r\n\r\nOnce an incident has been contained and/or quarantined, it is necessary to eliminate components that allowed the incident to occur, as well as identify and mitigate all vulnerabilities that were exploited. During this phase, it is crucial to identify all affected hosts within the CUSTOMER Enterprise network, so that they can be remediated appropriately.\r\n- Task 1 - Complete a peer review of incident details and proposed remediation to ensure consensus on the recommended approach and the details of the attack as documented in the security case. \r\n- Task 2 - Conduct a remediation conference call (if needed), to disseminate and discuss recommended and required actions to remediate the incident. \r\n- Task 3 - Add all IP addresses and/or host names involved in the incident to the Azure Sentinel  compromised and/or hostile WatchList(s) to increase Incident Severity on any subsequent events/alerts detected. This connects directly to the focused monitoring procedures from the SOC team. \r\n- Task 4 - Confirm remediation actions have been completed and conduct a final vulnerability assessment of the redeployed system, to prevent reinfection.\r\n\r\nDuring the remediation and recovery phase, systems must be restored to normal operation. Depending on the nature of a particular incident, corrective actions could be related to technology, policies and procedures, and/or personnel.\r\n\t \r\nDue to the nature of Advanced Persistent Threats (APTs), multiple attack vectors and the sophisticated nature of cyber-attacks, whereas attackers may leave behind undetected malware, or legitimate executable(s) which may contain a vulnerability or a backdoor on the compromised systems. To combat this threat, the SOC may require the impacted systems to be flattened, formatted,and reinstalled (FFR/wipe and reinstate) to restore the systems trust.\r\n\r\n![Remediation and Recover](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/RemediateRecover.png?raw=true)\r\n\r\n#### Remediation Scenarios/Options:\r\n- Simple changing of all passwords or removal of infected files. \r\n- Minor modification to applicable applications and/or operating system reconfiguration. \r\n- System restore from a clean backup.     \r\n- Completely rebuilding a system/asset; flattened, formatted, and reinstalled (FFR).\r\n \r\n#### General Recovery Guidance:\r\n- Data should be restored from a trusted source and validated. \r\n- The operating system and all applications should be updated wherever possible, patched, and all unnecessary services disabled. \r\n- For purpose-built devices (i.e., routers, switches, and security appliances) consult the vendor for information on security conscious configurations. \r\n- All system passwords should be changed and hosts with which the compromised system shared a trust relation examined for possible signs of compromise. \r\n- If the root cause for the compromise has been determined, appropriate steps should be implemented to mitigate the risks. \r\n- Focused Monitoring should be increased following an intrusion. Post compromise monitoring of a network will often reveal additional probes and may help identify additional compromised resources.\r\n\t\t \r\n\tNote: Remediation & Recovery should be conducted in a phased approach so that remediation steps are prioritized appropriately. During the early phases, the intent should be to increase the security posture with quick, high value changes to prevent future incidents and further outbreaks. The later phases should be focused on long term changes (i.e., infrastructure changes) and ongoing efforts to keep the CUSTOMER Enterprise network as secure as possible. \r\n\t \r\n### Post Mortem (Lessons Learned)\r\n\t\r\n#### Purpose: \r\nOne of the most important parts of the incident management process is also the most often omitted: learning and improving. The CUSTOMER SOC will conduct a “lessons learned” meeting with all involved parties after a major incident, and periodically after lesser incidents. Doing so is extremely helpful in improving security measures and the incident handling process itself. This meeting provides a chance to achieve closure with respect to an incident by reviewing what occurred,what was done to intervene, and how well intervention worked.\r\n\r\n#### Questions to be answered in the lessons learned meeting include: \r\n- Exactly what happened, and at what times? \r\n- How well did the staff and management perform in dealing with the incident? Were the documented procedures followed? Were they adequate? \r\n- What information was needed sooner? \r\n- Were any steps or actions taken that might have inhibited the recovery? \r\n- What would the staff and management do differently the next time a similar incident occurs? \r\n- What corrective actions can prevent similar incidents in the future? \r\n- What additional tools or resources are needed to detect, analyze, and mitigate future incidents?\r\n\t\r\nIn addition, the SOC will compile a Post Mortem Report. The report shall describe the incident, investigation methods, general conclusion, recommendations to avoid future related incidents and, if appropriate, lessons learned from the investigation.\r\n\r\n![Post Mortem](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/PostMortem.png?raw=true)\r\n\r\n\t\r\n#### Recommendations\r\n- Small incidents need limited post incident analysis, with the exception of incidents performed through new attack methods that are of widespread concern and interest.\r\n- Updating incident response policies and procedures is another important part of the lessons learned process. Postmortem analysis of the way an incident was handled will often reveal a missing step or an inaccuracy in a procedure, providing motivation for change.\r\n- The response to an incident that has been resolved can be analyzed to determine how effective it was. The following are examples of performing an objective assessment of an incident: \r\n\t- Reviewing logs, forms, reports, and other incident documentation for adherence to established incident response policies and procedures \r\n\t- Identifying which precursors and indications of the incident were recorded to determine how effectively the incident was logged \r\n\t- Determining if the incident caused damage before it was detected \r\n\t- Determining if the actual cause of the incident was identified \r\n\t- Identifying which measures, if any, could have prevented the incident.\r\n",
        "style": "upsell"
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Incident Response Procedures"
      },
      "customWidth": "75",
      "name": "SOC Incident Response Procedures 1"
    },
    {
      "type": 1,
      "content": {
        "json": "# SOC Actions\r\n\r\nDetected by Azure Sentinel\r\n\r\n\r\n## Suspicious PowerShell Command Line\r\n#### Actions to Take:\r\n\t1. Examine the PowerShell command line to understand what commands were executed. Note: the content may need to be decoded if it is Base64-encoded.\r\n\t2. Search the script for more indicators to investigate - for example IP addresses (potential C&C servers), target computers etc.\r\n\t3. Explore the timeline of this and other related machines for additional suspect activities around the time of the alert.\r\n\t4. Look for the process that invoked this PowerShell run and their origin. Consider submitting any suspect files in the chain for deep analysis for detailed behavior information.\r\n\t5. Escalate and contact your incident response team for potential forensics analysis and remediation.\r\n\r\n## An Anomalous Scheduled Task was Created\r\n#### Actions to Take:\r\n\t1. Validate the alert, collect artifacts, and determine scope \r\n\t2. Inspect the file or URL/IP for suspicious characteristics – is it digitally signed? How prevalent is it? Where is it located? Do the domain registration and hosting history look normal?  \r\n\t3. Review the machine timeline for suspicious activities that may have occurred before and after the time of the alert. \r\n\t4. Look for the presence of relevant artifacts on other systems. Identify commonalities and differences between potentially compromised systems. \r\n\t5. Submit relevant files for deep analysis and review resulting detailed behavioral information. \r\n\t6. If alert characteristics and machine behavioral evidence constitute a true positive escalate and contact your incident response team for potential forensic analysis and remediation. \r\n\r\n## Initiate containment & mitigation\r\n#### Actions to Take:\r\n\t1. Record all relevant artifacts to be used in mitigation rules and as new threat intel \r\n\t2. Contact the user to check if the observed behavior was intended. \r\n\t3. Update AV signatures and run a full scan. The scan might reveal and remove previously-undetected malware components. \r\n\t4. Ensure that the machine has the latest security updates. In particular, ensure that you have installed the latest software, web browser, and Operating System versions. \r\n\t5. If credential theft is suspected, reset all relevant users passwords. \r\n\t6. Disconnect the machine from the network to prevent any threat attack progression. \r\n\t7. Block communication with relevant URLs or IPs at the organization’s perimeter.\r\n\t8. If initial investigation confirms suspicions, escalate and contact your incident response team for forensic analysis.\r\n\r\n## An Uncommon File was Created and Added to a Run Key\r\n#### Actions to Take:\r\n\t1. Examine the file in question. Do you recognize it?\r\n\t2. Check the machine timeline for the machine in question. Do you see evidence of a breach?\r\n\t3. Update AV signatures and run a full scan. This may uncover previously undetected indicators of compromise.\r\n\t4. If you determine this may be an attack, reset all relevant user passwords, disconnect the machine from the network to prevent any threat attack progression, escalate, and contact your incident response team for potential forensics analysis and remediation. \r\n\t5. Work with your incident response team and Remove the registry key and file in question.\r\n\r\n## PowerShell dropped a Suspicious File on the Machine\r\n#### Actions to Take:\r\n\t1. Investigate the machine timeline for any other indicators around the time of this alert \r\n\t2. Validate contextual information about the relevant components such as file prevalence, other machines it was observed on etc. \r\n\t3. Run a full malware scan on the machine, this may reveal additional related components.\r\n\t4. Consider submitting the relevant file(s) for deep analysis for detailed behavioral information. \r\n\t5. If initial investigation confirms suspicions, escalate and contact your incident response team for forensic analysis.\r\n\r\n## Device tried to access a phishing site\r\n#### Actions to Take:\r\n\t1. Investigate the machine timeline for any other indicators around the time of this alert \r\n\t2. Validate contextual information about the relevant components such as file prevalence, other machines it was observed on etc. \r\n\t3. Run a full malware scan on the machine, this may reveal additional related components.\r\n\t4. Consider submitting the relevant file(s) for deep analysis for detailed behavioral information. \r\n\t5. If initial investigation confirms suspicions, escalate and contact your incident response team for forensic analysis.\r\n\r\n## MDE detected malware\r\nMalware and unwanted software are undesirable applications that perform annoying, disruptive, or harmful actions on affected machines. Some of these undesirable applications can replicate and spread from one machine to another. Others are able to receive commands from remote attackers and perform activities associated with cyber-attacks. A malware is considered active if it is found running on the machine or it already has persistence mechanisms in place. Active malware detections are assigned higher severity ratings. Because this malware was not remediated and is active, take precautionary measures and check for residual signs of infection.\r\n\r\n#### Actions to Take:\r\n\t1. Validate the alert and scope the suspected breach.\r\n\t\ta. Find related machines, network addresses, and files in the incident graph.\r\n\t\tb. Check for other suspicious activities in the machine timeline.\r\n\t\tc. Locate unfamiliar processes in the process tree. Check files for prevalence, their locations, and digital signatures.\r\n\t\td. Submit relevant files for deep analysis and review file behaviors.\r\n\t\te. Identify unusual system activity with system owners.\r\n\t2. If you have validated the alert, document the suspected breach.\r\n\t\ta. Record relevant artifacts, including those you need in mitigation rules.\r\n\t3. Escalate - Contact & work with your incident response team, or contact Microsoft Support for investigation and remediation services. NOTE: If you don’t have an incident response team, contact Microsoft Support for architectural remediation and forensic.\r\n\t\ta. Stop suspicious processes. Block prevalent malware files across the network.\r\n\t\tb. Isolate affected machines.\r\n\t\tc. Identify potentially compromised accounts. If necessary, reset passwords and decommission accounts.\r\n\t\td. Block relevant emails, websites, and IP addresses. Remove attack emails from mailboxes.\r\n\t\te. Update antimalware signatures and run full scans.\r\n\t\tf. Make sure the machine is completely updated and all your software has the latest patch.\r\n\t\tg. Deploy the latest security updates for Windows, web browsers, and other applications.\r\n\r\n#### Additional Actions to Consider:\r\n\t1. Install and run Microsoft’s Malicious Software Removal Tool (see https://www.microsoft.com/download/malicious-software-removal-tool-details.aspx).\r\n\t2. Run Microsoft’s Autoruns utility and try to identify unknown applications that are configured to run at login (see https://technet.microsoft.com/sysinternals/bb963902.aspx).\r\n\t3. Run Process Explorer and try to identify unknown running processes (see https://technet.microsoft.com/sysinternals/bb896653.aspx).\r\n\r\n## Internal Brute-Force Attack\r\n#### Actions to Take:\r\n\t1. Check with account owners to determine if the logon attempts were legitimate.\r\n\t2. Review processes responsible for the logon attempts. If the processes are unfamiliar and corresponding executables are not signed system files, submit the files for deep analysis and review detailed behavioral information from the analysis results.\r\n\t3. Review the machine timeline for any suspicious activities that have occurred around the time of the alert. Identify and review other affected machines.\r\n\t4. If the attempts were malicious, review all successful attempts from the affected accounts. Contain and mitigate the breach—stop suspicious processes, isolate affected machines, decommission compromised accounts or reset their passwords, block IP addresses and URLs, and install security updates.\r\n\t5. Escalate and contact your incident response team, or contact Microsoft support for forensic analysis and remediation services.\r\n\r\n## Unusual sequence of failed logons\r\nhttps://docs.microsoft.com/azure/active-directory/identity-protection/howto-identity-protection-simulate-risk\r\n\r\n#### Actions to Take:\r\n\t1. Validate and scope the alert.\r\n\t\ta. Check the source of the failed logon attempts. Contact system and account owners to identify unexpected activity.​\r\n\t\tb. Check other machines for suspicious network communications from the same location.​\r\n\t\tc. Check the timelines of all involved machines for other suspicious activities.​\r\n\t\td. Check the process tree of all involved machines for unfamiliar processes. Check files for prevalence, their locations, and digital signatures.​\r\n\t\te. Submit relevant files for deep analysis and review file behaviors. ​\r\n\t2. Escalate - Contact & work with your incident response team, or contact Microsoft support for investigation and remediation services.\r\n\t3. Contain and mitigate the breach. \r\n\t\ta. Stop suspicious processes, isolate affected machines, decommission compromised accounts or reset passwords, block IP addresses and URLs, and install security updates.​\r\n\r\n## Impossible Travel Activity\r\nhttps://docs.microsoft.com/azure/active-directory/identity-protection/howto-identity-protection-simulate-risk\r\n\r\n#### Actions to Take:\r\n\t1. Validate and scope the alert.\r\n\t\ta. Check the source of the failed logon attempts for the user. Contact system and account owners to identify unexpected activity.​\r\n\t\tb. Check the location where the performed failed sign in activities came from. Check whether they originated outside of the users standard login location and how long before a login was noticed from their normal location. Within how many minutes?\r\n\t\tc. Check If the IP addresses are known and safe, add them in the IP address range page to improve the accuracy of the alerts. Otherwise if Malicious, add them to the ThreatIntelligence as Indicators/IOCs.\r\n\t2. If the Identity has been compromised, escalate and work with your incident response team, or contact Microsoft support for forensic analysis and remediation services.\r\n\r\n## Suspicious Attachment Opened\r\n#### Actions to Take:\r\n\t1. Validate the alert.\r\n\t\ta. Inspect the attachment. Review the process that opened it and its behaviors.\r\n\t\tb. Check for other suspicious activities in the machine timeline.\r\n\t\tc. Locate unfamiliar processes in the process tree. Check files for prevalence, their locations, and digital signatures.\r\n\t\td. Submit relevant files for deep analysis and review file behaviors.\r\n\t\te. Identify unusual system activity with system owners.\r\n\t2. Scope the incident. Find related machines, network addresses, and files in the incident graph.\r\n\t3. Escalate and work with your incident response team, or contact Microsoft support for investigation and remediation services.\r\n\t\ta. Contain and mitigate the breach. Stop suspicious processes, isolate affected machines, decommission compromised accounts or reset passwords, block IP addresses and URLs, and install security updates.\r\n\r\n## Unfamiliar Sign-in Properties\r\nhttps://docs.microsoft.com/azure/active-directory/identity-protection/howto-identity-protection-simulate-risk\r\n\r\n#### Consideration:\r\n\tThis risk event type considers past sign-in properties (e.g. device, location, network) to determine sign-ins with unfamiliar properties. The system stores properties of previous locations used by a user, and considers these \"familiar\". The risk event is triggered when the sign-in occurs with properties not already in the list of familiar properties. The system has an initial learning period of 30 days, during which it does not flag any new detections. We also run this detection for basic authentication (or legacy protocols). Because these protocols do not have modern properties such as client id, there is limited telemetry to reduce false positives. We recommend our customers to move to modern authentication. For more information - https://go.microsoft.com/fwlink/?linkid=2016528\r\n\r\n## Password Spray\r\nhttps://www.microsoft.com/microsoft-365/blog/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/\r\n\r\n#### Actions to Take:\r\nFour easy steps to disrupt password spray attacks...\r\n\t1. Use Cloud Authentication - In the cloud, we see billions of sign-ins to Microsoft systems every day. Our security detection algorithms allow us to detect and block attacks as they’re happening. Because these are real time detection and protection systems driven from the cloud, they are available only when doing Azure AD authentication in the cloud (including Pass-Through Authentication).\r\n\t2. If your using AAD, then your covered with Smart Lockout. If your using ADFS, enable Smart Lockout - https://docs.microsoft.com/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-smart-lockout-protection.\r\n\t3. Use Attack Simulator to proactively evaluate your security posture and make adjustments - https://techcommunity.microsoft.com/t5/microsoft-security-and/announcing-the-public-preview-of-attack-simulator-for-office-365/ba-p/162412.\r\n\t4. Work with your Identity Global Admin and Enable MFA. A password is the key to accessing an account, but in a successful password spray attack, the attacker has guessed the correct password. To stop them, we need to use something more than just a password to distinguish between the account owner and the attacker. The three ways to do this are below:\r\n\t\ta. Risk-based MFA\r\n\t\tb. Always-on MFA\r\n\t\tc. Azure MFA as Primary Auth\r\n\t5. NOTE: We strongly recommend enabling always-on multi-factor authentication for all admins in your organization, especially subscription owners and tenant admins. Seriously, go do this right now. For the best experience for the rest of your users, we recommend risk-based multi-factor authentication, which is available with Azure AD Premium P2 licenses. Otherwise, use Azure MFA for cloud authentication and ADFS. In ADFS, upgrade to ADFS on Windows Server 2016 to use Azure MFA as primary authentication, especially for all your extranet access.\r\n\t6. If an Identity has been compromised, escalate and work with your incident response team, or contact Microsoft support for forensic analysis and remediation services.\r\n\r\n## Anonymous IP Address\r\nhttps://docs.microsoft.com/azure/active-directory/identity-protection/howto-identity-protection-simulate-risk\r\nThis risk event type indicates sign-ins from an anonymous IP address (e.g. Tor browser, anonymizer VPNs). Such IP addresses are commonly used by actors who want to hide their login telemetry (IP address, location, device, etc.) for potentially malicious intent. For more information - https://go.microsoft.com/fwlink/?linkid=2016442\r\n\r\n#### Actions to Take:\r\n\t1. Validate that the IP Address is Malicious.\r\n\t2. Run Playbook Get-IPReputation - This pulls down known malicious info about the IP from Virus Total.\r\n\t3. If no results return, IP is not listed. Validate the login with the User.\r\n\t4. If results from VT are malicious, run VT Query in Sentinel.\r\n\t\ta. Create a Bookmark, assign entities.\r\n\t\tb. Attach Bookmark to current Incident.\r\n\t\tc. Make notes of what known IOC's are associated with the IP Address.\r\n\t5. Validate the login with the User.\r\n\t6. After validation, if the login was malicious, have the user reset their password.\r\n\t7. If an Identity has been compromised, escalate and work with your incident response team, or contact Microsoft support for forensic analysis and remediation services.\r\n\r\n## Adaptive application control policy violation was audited\r\n#### Actions to Take:\r\n\t1. Review the list of applications that were run.\r\n\t2. Review the application control policy that is applied to this machine by visiting the Adaptive Application Controls section in the Azure Security Center portal.\r\n\t3. Review the list of existing rules in each of the rule collections (publisher/path/hash), and identify the rules that have triggered an audit event for the above applications.\r\n\t4. If you have identified a rule that should allow the above applications to run, review the users that ran them.\r\n\t5. In case you wish to allow them and change the application control policy applied to this machine policy group, make sure to add them to the appropriate rules that you have identified in step #3. Otherwise - contact the specific user and escalate this alert for further investigation.\r\n\t6. If the above applications are not currently allowed by one of the rules that you have identified in step #3, and in case that you wish to allow them, make sure to add a new rule to this machine policy group.\r\n\r\n## Suspicious authentication activity\r\n#### Actions to Take:\r\n\t1. Validate the login with the User.\r\n\t2. Enforce the use of strong passwords and do not re-use them across multiple resources and services.\r\n\t3. In case this is an Azure Virtual Machine, set up an NSG allow list of only expected IP addresses or ranges. (see https://azure.microsoft.com/documentation/articles/virtual-networks-nsg/) \r\n\t4. In case this is an Azure Virtual Machine, lock down access to it using network JIT (see https://docs.microsoft.com/azure/security-center/security-center-just-in-time)\r\n\t5. If an Identity has been compromised, escalate and work with your incident response team, or contact Microsoft support for forensic analysis and remediation services.\r\n\r\n## Failed SSH Brute Force Attack\r\n#### Actions to Take:\r\n\t1. In case this is an Azure virtual machine, add the source IP to NSG block list for 24 hours (see https://azure.microsoft.com/documentation/articles/virtual-networks-nsg/)\r\n\t2. Use SSH Keys where possible instead of Passwords for SSH Access to your VMs and Linux Machines (see Use SSH keys to connect to Linux VMs - Azure Virtual Machines | Microsoft Docs)\r\n\t3. If you are using Passwords instead of SSH Keys, then enforce the use of strong passwords and do not re-use them across multiple resources and services (see http://windows.microsoft.com/Windows7/Tips-for-creating-strong-passwords-and-passphrases) \r\n\t4. In case this is an Azure virtual machine, Create an allow list for SSH access in NSG (see https://azure.microsoft.com/documentation/articles/virtual-networks-nsg/)"
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Incident Actions"
      },
      "customWidth": "75",
      "name": "SOC Incident Actions"
    },
    {
      "type": 1,
      "content": {
        "json": "## Leverage Microsoft Learn for Role-Based Training for Information Security Professionals in Azure\r\n\r\n![Image Name](https://docs.microsoft.com/learn/modules/intro-to-security-in-azure/media/1-heading.png \"Microsoft Learn\")\r\n\r\n### Protect against security threats on Azure\r\n![Image Name](https://docs.microsoft.com/learn/achievements/review-security-tools-features.svg \"Protect against Security Threats on Azure\")\r\n\r\n&nbsp; &nbsp; &nbsp; <a href=\"https://docs.microsoft.com/learn/modules/protect-against-security-threats-azure/1-introduction/\">Start Here</a>\r\n\r\n#### 25 min - Module - 8 Units\r\nLearn how Azure can help you protect the workloads that you run both in the cloud and in your on-premises datacenter.\r\n\r\nLearning objectives\r\nAfter completing this module, you'll be able to:\r\n\r\n- Strengthen your security posture and protect against threats by using Azure Security Center.\r\n- Collect and act on security data from many different sources by using Azure Sentinel.\r\n- Store and access sensitive information such as passwords and encryption keys securely in Azure Key Vault.\r\n- Manage dedicated physical servers to host your Azure VMs for Windows and Linux by using Azure Dedicated Host.\r\n\r\n### Cloud-native security operations with Azure Sentinel\r\n\r\nThis learning path describes basic architecture, core capabilities, and primary use cases of its products. You'll also learn about differences and Get familiar with Azure Sentinel, a cloud-native, security information and event management (SIEM) service.\r\n\r\n![Image Name](https://docs.microsoft.com/learn/achievements/security-ops-sentinel.svg \"Sentinel Learn Achievement\")\r\n\r\n#### 6hrs 19min / Learning Path / 7 Modules\r\nPrerequisites\r\nFamiliarity with security operations in an organization\r\nBasic experience with Azure services\r\nBasic knowledge of operational concepts such as monitoring, logging, and alerting\r\nAn Azure Sentinel instance in your Azure subscription\r\n\r\n![Image Name](https://docs.microsoft.com/learn/achievements/intro-to-azure-sentinel.svg \"Introduction to Azure Sentinel\") ![Image Name](https://docs.microsoft.com/learn/achievements/deploy-azure-sentinel-and-connect-data-sources.svg \"Deploy Azure Sentinel and Data Connectors\") ![Image Name](https://docs.microsoft.com/learn/achievements/analyze-data-in-sentinel.svg \"Threat Detection with Azure Sentinel Analytics\") ![Image Name](https://docs.microsoft.com/learn/achievements/incident-management-sentinel.svg \"Security Incident Management in Azure Sentinel\") ![Image Name](https://docs.microsoft.com/learn/achievements/hunt-threats-sentinel.svg \"Threat Hunting with Azure Sentinel\") ![Image Name](https://docs.microsoft.com/learn/achievements/threat-response-sentinel-playbooks.svg \"Threat Response with Azure Sentinel Playbooks\") ![Image Name](https://docs.microsoft.com/learn/achievements/query-data-sentinel.svg \"Query, Visualize, and Monitor data in Azure Sentinel\")\r\n\r\n<a href=\"https://docs.microsoft.com/learn/modules/intro-to-azure-sentinel/1-introduction/\">Intro to Sentinel</a> &nbsp; &nbsp; <a href=\"https://docs.microsoft.com/learn/modules/azure-sentinel-deploy-configure/\">Deploy Sentinel</a> &nbsp; <a href=\"https://docs.microsoft.com/learn/modules/analyze-data-in-sentinel/\">Threats in Sentinel</a> &nbsp; <a href=\"https://docs.microsoft.com/learn/modules/incident-management-sentinel/\">Incident Mangmnt</a> &nbsp; <a href=\"https://docs.microsoft.com/learn/modules/hunt-threats-sentinel/\">Threat Hunting</a> &nbsp; <a href=\"https://docs.microsoft.com/learn/modules/threat-response-sentinel-playbooks/\">Threat Response</a> &nbsp; &nbsp; <a href=\"https://docs.microsoft.com/learn/modules/query-data-sentinel/\">Query & Visualize</a>\r\n\r\n## Additional Sentinel Learning Modules and Badges!\r\n\r\n| Sentinel Learning Modules |\r\n| : | : |\r\n| [SC-200 part 4](https://docs.microsoft.com/learn/paths/sc-200-utilize-kql-for-azure-sentinel/) | SC-200 part 4: Create queries for Azure Sentinel using Kusto Query Language (KQL) |\r\n| [SC-200 part 5](https://docs.microsoft.com/learn/paths/sc-200-configure-azure-sentinel-environment/) | SC-200 part 5: Configure your Azure Sentinel environment |\r\n| [SC-200 part 6](https://docs.microsoft.com/learn/paths/sc-200-connect-logs-to-azure-sentinel/) | SC-200 part 6: Connect logs to Azure Sentinel |\r\n| [SC-200 part 7](https://docs.microsoft.com/learn/paths/sc-200-create-detections-perform-investigations-azure-sentinel/) | SC-200 part 7: Create detections and perform investigations using Azure Sentinel |\r\n| [SC-200 part 8](https://docs.microsoft.com/learn/paths/sc-200-perform-threat-hunting-azure-sentinel/) | SC-200 part 8: Perform threat hunting in Azure Sentinel |\r\n\r\n![](https://docs.microsoft.com/learn/achievements/utilize-kql-for-azure-sentinel.svg) ![](https://docs.microsoft.com/learn/achievements/configure-your-azure-sentinel-environment.svg) ![](https://docs.microsoft.com/learn/achievements/connect-logs-to-azure-sentinel.svg) ![](https://docs.microsoft.com/learn/achievements/azure-sentinel-detection.svg) ![](https://docs.microsoft.com/learn/achievements/perform-threat-hunting-in-azure-sentinel.svg)"
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Training"
      },
      "customWidth": "75",
      "name": "SOC Training"
    },
    {
      "type": 1,
      "content": {
        "json": "## Incident Response Framework: Security Operations Center\r\n\r\n## Description\r\nThis diagram describes how Sentinel is used from the initial monitoring of data sources through the Incident Response process to incident remediation, recovery and post mortem.\r\n\r\n![Image Name](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/Incident%20Response%20Framework%20SOC%20-%20vs%201.1.png?raw=true\"IR Framework SOC\")"
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Incident Response Framework"
      },
      "customWidth": "75",
      "name": "SOC Incident Response Framework"
    },
    {
      "type": 12,
      "content": {
        "version": "NotebookGroup/1.0",
        "groupType": "editable",
        "items": [
          {
            "type": 1,
            "content": {
              "json": "# SOC Tools and Resources",
              "style": "info"
            },
            "customWidth": "75",
            "name": "SOC Tools and Resources Header"
          },
          {
            "type": 1,
            "content": {
              "json": "## Technical Resources\r\n\r\n| Topic | URL Link | Description/Comments |\r\n| : | : | : |\r\n| Networking |   |   |\r\n|   | [IPv4 Subnetting](https://packetlife.net/media/library/15/IPv4_Subnetting.pdf) | Details around IPv4 Subnetting & CIDR Notation |\r\n|   | [IPv6 Subnetting](https://ftp.apnic.net/apnic/training/eLearningHandouts/2017/20170215/20170215-IPv6-AaS-Handouts.pdf) | Details around IPv6 Subnetting to include packet details |\r\n|   | [Network Address Translation](https://en.wikipedia.org/wiki/Network_address_translation) | NAT Details |\r\n|   | [Common Internet Ports](https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers) | Common Internet Ports for SOC Analysts |\r\n| Linux |   |   |\r\n|   | [Linux Networking](https://tldp.org/LDP/nag2/nag2.pdf) | Linux Network Administrators Guide |\r\n|   | [Common Linux Commands](https://appletree.or.kr/quick_reference_cards/Unix-Linux/Linux%20Command%20Line%20Cheat%20Sheet.pdf) | General Linux Commands |\r\n|   | [Intrusion Analysis with Linux](https://www.sans.org/media/score/checklists/ID-Linux.pdf) | Linux Intrusion Discovery Guide |\r\n| Security Guides |   |   |\r\n|   | [SANS Glossary](http://www.sans.org/security-resources/glossary-of-terms/) | SANS Glossary of Security Terms |\r\n|   | [Threat Encyclodpedia](http://www.trendmicro.com/vinfo/us/threat-encyclopedia/) | Search through Threat Encyclodpedia |\r\n|   | [Sophos Threatsaurus](https://www.sophos.com/medialibrary/PDFs/other/sophosthreatsaurusaz.pdf?la=en) | The A-Z Guide to Security Threats |\r\n|   | [TCPDump](https://cdn.comparitech.com/wp-content/uploads/2019/06/tcpdump-cheat-sheet-1.pdf) | TCPDump Cheat Sheet |\r\n|   | [Wireshark User's Guide](https://www.wireshark.org/docs/wsug_html/) | How-to-guide on Wireshark |\r\n|   | [Wireshark Filters](https://wiki.wireshark.org/DisplayFilters) | Wireshark Display Filters |\r\n|   | [Metasploit Guide](https://www.exploit-db.com/docs/english/44040-the-easiest-metasploit-guide-you%E2%80%99ll-ever-read.pdf) | Metasploit User's Guide |\r\n|   | [Netcat Guide](https://cdn.comparitech.com/wp-content/uploads/2019/07/netcat-Cheat-Sheet.pdf) | Netcat Cheat Sheet |\r\n|   | [Network DDoS Guide](https://us-cert.cisa.gov/sites/default/files/publications/DDoS%20Quick%20Guide.pdf) | DDoS Incident Cheat Sheet |\r\n|   | [Memory Forensics Guide](https://digital-forensics.sans.org/media/volatility-memory-forensics-cheat-sheet.pdf) | Memory Forensics Cheat Sheet |\r\n|   | [NMAP Guide](https://www.stationx.net/nmap-cheat-sheet/) | NMAP Cheat Sheet |\r\n|   | [Log Review - Security Incidents](https://www.sans.org/brochure/course/log-management-in-depth/6) | Critical Log Review Checklist for Security Incidents |\r\n|   | [Keylogger Applications](https://usa.kaspersky.com/resource-center/definitions/keylogger) | Understanding Keylogger Applications |\r\n|   | [P2P File Sharing](https://en.wikipedia.org/wiki/Peer-to-peer_file_sharing) | Understanding Peer-2-Peer File Sharing Applications |\r\n|   | [Security Incident Questionnaire](https://zeltser.com/media/docs/security-incident-questionnaire-cheat-sheet.pdf) | Security Incident Questionnaire Checklist |\r\n|   | [Microsoft Logon Types](https://docs.microsoft.com/windows-server/identity/securing-privileged-access/reference-tools-logon-types) | Microsoft Logon Codes Explained |\r\n|   | [Analyzing Malicious Documents](https://digital-forensics.sans.org/media/analyzing-malicious-document-files.pdf) | Reverse Engineering Malicious Documents Guide |\r\n|   | [Reverse Eng Malware](https://zeltser.com/media/docs/malware-analysis-cheat-sheet.pdf) | Reverse Engineering malware Cheat Sheet |\r\n|   | [Building a Cybersecurity Strategy](https://resources.sei.cmu.edu/asset_files/Newsletter/2021_102_001_651837.pdf) | Six Key Cybersecurity Engineering Activities for Building a Cybersecurity Strategy |"
            },
            "customWidth": "75",
            "name": "SOC Tools and Resource Links"
          },
          {
            "type": 1,
            "content": {
              "json": "## Threat intelligence Sources\r\n\r\n| Topic | URL Link | Description/Comments |\r\n| : | : | : |\r\n| IP / URL / Domain Reputation |   |   |\r\n|   | [IP Blocklist Check](https://whatismyipaddress.com/blacklist-check) | Verify the IP Address hasn't been blocklisted |\r\n|   | [Project Honey Pot](http://www.projecthoneypot.org/search_ip.php) | Project Honey Pot - System for Identifying Spammers and Spambots |\r\n|   | [DShield lookup](http://www.dshield.org/sources.html) | Internet Storm Center IP & Ports lookup |\r\n|   | [MX Lookup](http://mxtoolbox.com) | Lists MX Records for a Domain in Priority Order |\r\n|   | [Website Reputation](http://urlvoid.com) | Website Reputation Checker Tool |\r\n|   | [Research IPs](http://robtex.com) | Research IPs, DNS, Spammers |\r\n|   | [Virus Total](https://www.virustotal.com/) | Online Service that analyzes IPs, Domains, URL, and Files for malware |\r\n|   | [Validate HTTP Requests](http://www.rexswain.com/httpview.html) | See Exactly what an HTTP request returns to your Browser |\r\n|   | [Malware Domain List](http://www.malwaredomainlist.com/mdl.php) | Tool for determining if Domains are associated with Malware |\r\n| Real-time Threat Monitoring |   |   |\r\n|   | [Malware URL](http://www.malwareurl.com/) | Tool for tracking suspicious URLs |\r\n|   | [Security Wizard](http://www.securitywizardry.com/radar.htm) | Security Wizard for Cyber Threat intelligence |\r\n|   | [Threat Descriptions](https://www.f-secure.com/en/web/labs_global/threat-descriptions) | F-Secure Labs - Threat Descriptions |\r\n|   | [Shadow Server](https://www.shadowserver.org/wiki/pmwiki.php/Main/HomePage) | Intelligence on the darker side of the Internet |"
            },
            "name": "text - 2"
          }
        ]
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Tools and Resources"
      },
      "customWidth": "75",
      "name": "SOC Tools and Resources Group"
    },
    {
      "type": 1,
      "content": {
        "json": "# SOC Process Hierarchy\r\n\r\n## Purpose\r\nThis diagram shows how each Process & Procedure is mapped and outlined.\r\n\r\n## Description\r\n<strong>Business processes are the foundation of the Process and Procedure Pyramid that drives Technology and Operational processes. At the top are customized Analytic use cases, that result in Detection and Remediation.</strong>\r\n\r\n![Image Name](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/AZSentinelProcessHierarchySOC.png?raw=true\"SOC Process Hierarchy\")\r\n",
        "style": "info"
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Process Hierarchy"
      },
      "customWidth": "75",
      "name": "SOC Process Hierarchy Diagram"
    },
    {
      "type": 12,
      "content": {
        "version": "NotebookGroup/1.0",
        "groupType": "editable",
        "items": [
          {
            "type": 1,
            "content": {
              "json": "# SOC Analytical Processes & Procedures\r\n\r\n| Process Name | Procedures | Description/Comments |\r\n| : | : | : |\r\n| Intrusion Analysis Process |  |  |\r\n|  | Incident Triage Workflow & Narrative | Procedures for the SOC Analyst as Incidents enter the Azure Sentinel Incidents Blade |\r\n|  | Incident Analysis | How analysts should utilize internal and external resources to perform security threat research |\r\n|  | Information Fusion\t| How analysts should look at Incidents that are presented to them within the Azure Sentinel Incidents Blade |\r\n|  | Focused Monitoring | How analysts should focus on specific Events/fields in order to broaden the search to find out more about what an IP, host, user, etc. is doing |\r\n|  | SOC Use Cases | Use Cases designed, built and deployed for the SOC |\r\n| Host Analysis Process\t|  |  |\r\n| Subtle Event Process |  |  |\r\n|  | Data Exploration | Procedures for using Azure Sentinel or other tools to visually review security events for abnormalities |\r\n"
            },
            "customWidth": "75",
            "showPin": false,
            "name": "SOC Analytical Processes & Procedures Header"
          },
          {
            "type": 11,
            "content": {
              "version": "LinkItem/1.0",
              "style": "list",
              "links": [
                {
                  "id": "c4ab9a2d-7821-4fac-9c38-3625651b2b1f",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Intrusion Analysis Process",
                  "subTarget": "Intrusion Analysis Process",
                  "style": "primary"
                },
                {
                  "id": "1712f666-f40f-4f11-b759-75e93e639640",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Incident Triage Workflow & Narrative",
                  "subTarget": "Incident Triage Workflow & Narrative",
                  "style": "secondary"
                },
                {
                  "id": "b487fbce-3595-461d-abf0-9b779e3bec75",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Incident Analysis",
                  "subTarget": "Incident Analysis",
                  "style": "secondary"
                },
                {
                  "id": "c4e45a9f-180c-48fb-8de7-2ab80f767c8b",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Information Fusion",
                  "subTarget": "Information Fusion",
                  "style": "secondary"
                },
                {
                  "id": "31ad3f79-950e-4be1-a72b-993b8a43c9ca",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Focused Monitoring",
                  "subTarget": "Focused Monitoring",
                  "style": "secondary"
                },
                {
                  "id": "ece262b7-b2e3-4773-be25-339b534eebf4",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "SOC Use Cases",
                  "subTarget": "SOC Use Cases",
                  "style": "secondary"
                },
                {
                  "id": "088385d0-5736-4f61-a1cf-98430b5096bc",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Host Analysis Process",
                  "subTarget": "Host Analysis Process",
                  "style": "primary"
                },
                {
                  "id": "b945b099-40ae-4bde-826b-1ec1517e94cf",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Subtle Event Process",
                  "subTarget": "Subtle Event Process",
                  "style": "primary"
                },
                {
                  "id": "bd9f3c8f-e2c0-4d74-b947-9ad52bdb7928",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Data Exploration",
                  "subTarget": "Data Exploration",
                  "style": "secondary"
                }
              ]
            },
            "customWidth": "25",
            "name": "SOC Analytical Processes & Procedures Nav",
            "styleSettings": {
              "margin": "20",
              "padding": "20"
            }
          },
          {
            "type": 1,
            "content": {
              "json": "## Intrusion Analysis Process\r\n\r\n### Purpose \r\nThe purpose of this process is to support the SOC Analysts with a structured approach to the discipline of intrusion analysis and operational event management. \r\n\r\n### Scope \r\nThis process applies to all Incidents that are presented with the tag <strong>Triage</strong>, as this is the accountable tag for SOC operations. This also applies to all SOC Analysts tasked with monitoring, recognition and escalation. \r\n\r\n### Process Summary \r\nAll SOC Analysts will monitor the Azure Sentinel Incident Blade for Security Alerts turned Incident. They will evaluate and investigate these Incidents to determine if they represent significant security concerns.\r\n\r\nAn information security device detects some form of traffic that conforms to a suspicious pattern and then generates an event which is normalized, annotated, aggregated, correlated and displayed on the Azure Sentinel Incident Blade. The on-duty analyst(s) must then decide if this Incident warrants further analysis or some level of response. The process of analyzing this Incident is the subject of the procedures subordinate to this process. Once an Incident or series of Incident(s) has been analyzed and a decision made as to its validity, threat, and criticality, the Incident Triage Procedures provides a decision matrix to determine the appropriate level of response. \r\n\r\nThe Information Fusion Procedures spells out the detailed steps taken to ensure that all analysts have a comprehensive view of the current state of information security threats and vulnerabilities across the globe as well as within the CUSTOMER enterprise. This procedure will spell out the steps involved in the collection, analysis and dissemination of analytical security information. This procedure will result in a well-informed community of intrusion analysts. All SOC Analysts are primarily responsible for the execution of this procedure. \r\n\r\nThe Incident Analysis Procedures documents the step-by-step approach to analyzing the signature, context, appropriateness, and specifics of a given information security event displayed in the Azure Sentinel Incidents Blade. The procedure will result in the appropriate escalation of significant Incidents, Alerts, and Events, as well as the effective handling of less critical Incidents, Alerts, and Events. This procedure is primarily the responsibility for all SOC Analysts."
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Intrusion Analysis Process"
            },
            "name": "Intrusion Analysis Process Text"
          },
          {
            "type": 1,
            "content": {
              "json": "## Incident Triage Workflow & Narrative\r\n\r\n### Incident Annotation Stages\r\nThe various steps that make up a collaborative workflow for  annotations are called Stages. Individual Incidents can be assigned to the various stages by an analyst investigating Incidents. Stages are assigned to individual Incidents using tagged annotations. You can assign stages or tags to an Incident by by clicking on an Incident and click the \"+\" under Tags to add your annotation/tag.\r\n \r\nThe SOC will report on Incidents and the resulting Azure Sentinel Incidents generated from the analysis they conduct. It is very important to tag/annotate Incidents properly in order to ensure that SOC activity reporting is correct. \r\n \r\nThese Incident annotation stages that can be used by the SOC Analyst within the Azure Sentinel Logs view are listed below with a description for each.\r\n\r\n#### Workflow Diagram:\r\n![Image Name](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/IncidentTraigeWorkflow.png?raw=true\"Incident Triage Workflow\")\r\n\r\n| Incident Annotation Stages by Tags | DESCRIPTION |\r\n| : |  : |\r\n| Queued | Azure Sentinel Incidents by default are queued by Creation date and contain all Alerts/Events that come into Azure Sentinel. |\r\n| Triage | The first custom stage of the SOC workflow, Triage will be used by all SOC Analysts to move Incidents/Alerts/Events of interest from the Queued stage to a separate queue for further investigation. This helps to provide a lower false positive rate. |\r\n| Update Incident | This stage is used to update existing Azure Sentinel Incidents that have been previously Opened and Triaged by SOC Analysts. |\r\n| Incident Previously Created | This stage is used to denote that we have a duplicate Incident/Alert which is already being worked.  This allows analysts to identify Incidents/Alerts/Events which are not necessarily false positives, but do not need to have new Incidents created or do not need to be added to the existing Incident because the Alerts/Events are repeat Alerts/Events. |\r\n| Under Investigation | This stage will be used by SOC Analysts to conduct additional analysis on Incidents/Alerts/Events that were moved out of the Triage Stage. |\r\n| False Positive / No Further Action | This stage can be used at any point in the workflow to close an Incident with corresponding Alerts/Events that are either false positives or have completed their lifecycle. |\r\n\r\n### Azure Sentinel Incident Stage Management\r\nAll of the Incident stages should be reviewed periodically.  The priority of the Incidents will dictate which needs to be addressed first, so the order listing in this narrative is just for functional purposes.\r\n\r\n### Azure Sentinel Incident Traige Stages\r\n\r\n| Incident Triage Stages by Tags | Description |\r\n| : | : |\r\n| Open | If determination is made that an Incident is considered to be actionable, this stage will be used. This stage will be used for tracking of incidents throughout the Incident lifecycle. NOTE: SOC Incidents might want be tied into an external ticketing systems (i.e. Archer) when engaging other teams for escalation and/or remediation. For example, the Archer ticket should be entered into the SOC case so someone can tie the two together in an audit or review. |\r\n| Open/Escalated - Awaiting Information | Incidents that have been escalated to an External Team by way of the Incident Response Team. This will allow another set of eyes on a particular Incident or group of Incidents to assist with the investigations process. |\r\n| Closed - False Positive | This stage is to be used when and Incident has been deemed a false positive and no further action is required. |\r\n| Closed - Remediated | Incidents that have been fully examined and the Analyst has provided remediation. |\r\n| Closed - Insufficient Data | Incidents that were closed as a result of insufficient data to support the investigation. These Incidents need further review to understand what data is needed to further support the investigation of these Incidents. |\r\n| Closed - No Risk | Incidents that have been identified where there was no risk to the Enterprise. (i.e. misconfigured device, authorized scanning) |\r\n| Closed - Other | Incidents that have been closed that don’t match the previously identified closure codes (i.e. FP, Remediated, Insufficient data, etc). |\r\n\r\n### Incident Triage Process (Primary Analyst)\r\n1. An Alert/Incident fires into the Incidents Blade within Azure Sentinel.  If there is more than one SOC Primary Analyst triaging, they will select the Incidents they wish to investigate and then change the Incident annotation stage to <strong>“Under Investigation”</strong>. The Incident should then be assigned to the Analyst. The Primary Analyst has 5 - 15 minutes to examine the Incident and determines if the Incident is an ‘Incident of interest’. If the Incident is NOT of interest, then it has been determined to be a false positive. The Analyst shall change the Incident Annotation stage to <strong>\"False Positive/No Further Action\"</strong>. The Incident is then closed and updates the Daily Shift Log. If content can be created and/or modified to eliminate the false positive that information needs to be submitted to the SIEM engineers as a Content Change Request. If the Azure Sentinel content doesn’t need to be modified, a SOC Analyst will note the reason for the false positive (i.e. passwords expire, system misconfiguration, etc.) in the daily shift logs.\r\n2. If an Incident has been deemed <strong>“actionable”</strong>, the Primary Analyst will conduct additional analysis and compile more information about the Incident. The Primary Analyst then checks to see if a new Azure Sentinel Incident or if an existing Incident needs to be updated. If a new Incident is needed, the Analyst gathers the necessary details, opens an Incident and adds all relevant event(s)/bookmark(s) to the Incident. The Analyst changes the Incident stage to <strong>“Open”</strong>. An Incident should only be opened if the analyst is fairly confident that the event(s) is not a false positive. The Primary Analyst notifies a Secondary Analyst (“off-channel”) via email or Teams or another method that there is an Incident opened and tags that Incident with <strong>“Open”</strong>.\r\n3. If the event(s) triaged/hunted and bookmarked are part of an existing Azure Sentinel Incident, the Analyst updates the details of that Incident and adds all event(s)/bookmark(s) to the existing Incident. The Incident is then tagged with <strong>“Add to Incident”</strong> stage. The Primary Analyst notifies a Secondary Analyst (“off-channel”) via email that there is an Incident opened and also tags that Incident <strong>“Open”</strong>.  \r\n4. Once an Incident is opened, it is the responsibility of the Incident owner/creator to manage the Incident to closure, unless it is escalated to the Secondary Analysts or the Incident Response Team.\r\n\t\r\n### Secondary Analyst - Investigation Process\r\n1. The Secondary Analysts need to routinely filter within the Incidents blade of Azure Sentinel for the Incidents Tagged <strong>\"Open\"</strong> to identify any Incidents that need to be further investigated. Escalations from the Primary Analysts will be sent via Teams to the Secondary Analysts. The Analyst that would be responsible for “Incident ownership” will move the Incident Taggs from <strong>“Open”</strong> to <strong>\"Under Investigation\"</strong> and assign the Incident to themselves.\r\n2. In the event that their investigation leads to a False Positive, the Analyst needs to document within the Incident the conclusion and change the Incident stage to <strong>“Closed – False Positive”</strong>. The Analyst then closes the Incident and transfers the knowledge of their findings to the Primary Analysts. The Secondary Analysts will also update the Shift log(s) with those findings. If content can be created and/or modified to eliminate the false positive that information needs to be submitted to the SIEM engineers as a Content change.\r\n3. If the Incident has been determined to be valid and no escalation is required, the Analyst will conduct further analysis and continue resolving the Incident. Once the issue has been remediated the Analysis will update the Incident details and then change the Incident to <strong>“Closed – Remediated”</strong>.\r\n4. The Analyst then documents within the Incident the conclusion and changes the Incident tagged stage to <strong>“Closed – Remediated”</strong> (with other appropriate closure notes). The Analyst then closes the Incident and transfers the knowledge of their findings to the Primary Analysts.  The Secondary Analysts will also update the Shift log(s) with their findings.\r\n5. If the incident requires escalation, the Analyst proceeds with moving the Incident to the <strong>“Escalated to IR”</strong> by tagging the Incident. A SOC Analyst notifies a member of the Incident Response Team via Teams or Email.\r\n\t\r\n### Incident Response Team - Triage Process\r\n1. The Incident Response Team needs to routinely check the Incidents tagged with “Escalated to IR” within the Azure Sentinel Incidents Blade to identify any Incidents that need to be further investigated. Escalations from the Secondary Analysts will be sent via Teams or an email to the Incident Response Team. \r\n2. In the event that their investigation leads to a False Positive, the Analyst needs to document within the Incident the conclusion and change the Tagged stage to <strong>“Closed – False Positive”</strong>. The Analyst then closes the Incident and transfers the knowledge of their findings to the Primary & Secondary Analysts and updates the Shift Log(s). If content can be created and/or modified to eliminate the false positive that information needs to be submitted to the SIEM engineers as a Content change.\r\n3. If the Incident has been determined to be valid, the Incident Responder determines if External Teams are needed to assist with the investigation. If no other team is needed, then IR proceeds with following the pre-defined Incident Response plan. The IR Team member that is responsible for investigating the incident will declare <strong>“Incident ownership”</strong> and assign the Incident to themselves.\r\n4. Once the issue has been remediated, the Analyst then documents within the Incident the conclusion and changes the Incident Tagged stage to <strong>“Closed – Remediated”</strong> (with other appropriate closure notes). The Analyst then closes the Incident and provides a knowledge transfer with their findings to the Primary & Secondary Analysts.  The IR Team will also update the Shift log(s) with their findings.\r\n5. If an Incident has been determined to be valid and there is an External Team needed to assist with the investigation, a member of the IR Team re-tags the Case to <strong>“Open - Awaiting Information”</strong>. The IR Team member that is responsible for the investigation will declare “Incident ownership” and assigns the Incident to themselves.\r\n\t\r\nThe IR Team also identifies which external team the incident needs to be escalated to. After escalation has been established, the necessary team will continue to resolve the incident. Once the issue has been remediated, the Analyst then documents within the Incident the conclusion and re-tags the Incident with the tagged stage of <strong>“Closed – Remediated”</strong> (with other appropriate closure notes). The Analyst then Closes the Incident and provides a knowledge transfer with their findings with the Primary & Secondary Analysts.  The IR Team will also update the Shift log(s) with their findings.\r\n\t\r\n### Incident Closure Workflow \r\n1. Once an Incident is closed, review the details of the Incident, the indicators of compromise, the attack vector and the root cause.\r\n2. With the information above, determine if an update is needed to the knowledgebase and update as needed.\r\n3. Update the Final Incident, review details with informative knowledge and make sure the Incident has been tag/annotated closed.\r\n4. With the information above, determine if content needs to be updated or new content created."
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Incident Triage Workflow & Narrative"
            },
            "name": "Incident Triage Workflow & Narrative Text"
          },
          {
            "type": 1,
            "content": {
              "json": "## Incident Analysis Procedures\r\n\r\n### Description\r\nThe Incident Analysis procedure is the basic analytical process a SOC Analyst must use to determine if a series of Azure Sentinel Incidents are critical, warrant some level of callout, or are insignificant and warrant no action. A Primary Analyst will monitor the Azure Sentinel Incident Blade for Incidents tagged with <strong>\"Triage\"</strong>. The Primary Analyst will monitor for a period of 2 or 4 hours according to the Monitoring Schedule. \r\n- A Primary Analyst has 5 - 15 minutes from the time an Incident populates the Azure Sentinel Incidents Blade to triage and tag Incidents of interest with the <strong>\"Triage\"</strong> tag, in accordance with the SOC SLA. SLA tracking is monitored by SOC Leadership. A Secondary Analyst will monitor the Azure Sentinel Incidents tagged with <strong>\"Triage\"</strong>. The Secondary Analyst will monitor for a period of 2 or 4 hours according to the Console Monitoring Schedule. \r\n- The Secondary Analyst has an 8-hour SLA to resolve these Incidents. This is so the analyst has sufficient time to review and triage Incidents that merit more in-depth analysis. \r\n\t\t \r\nIt may be necessary to monitor the Incidents blade for additional taggs based on new requirements such as virus outbreaks, new 0-days, etc. This notification will be provided to the Primary SOC Analysts by the SOC Leadership as necessary. \r\n\r\n### Step 1: Group Events for Analysis\r\nThe Primary Analyst will review all Incidents and tag and triage them as necessary for review or close them. If analysis on any of the Incidents is expected to take longer than 5 - 15 minutes, the Primary Analyst will escalate the Incident(s) with the <strong>\"Triage\"</strong> tag for review by the Secondary Analyst.\r\n\t \r\n### Step 2: Understanding the Attack\r\nThe Primary Analyst should gather and understand the full context of the cyber-event. Use a tool like notepad to record the following information (this will be transferred to the event annotation notes):\r\n\r\n<strong>Identify Source IP / Destination IP Addresses</strong>\r\n- Use Nslookup (Windows DNS), Search <Customer> OneNote, Wiki to identify the asset.\r\n\r\n<strong>Identify Host/Asset Type</strong>\r\n- Workstation or Server\r\n- Type - Enterprise, Production or Development\r\n\r\n<strong>Identify Accounts</strong>\r\n- If a service account? Who is the owner of the service account?\r\n- What is the SID of the account that was locked?\r\n- Which Domain does this account belong to?\r\n- What permissions / privileges have been assigned to this account? Were permissions elevated\r\n\r\n<strong>Identify if the Host is Internal or External</strong>\r\n- What is the MAC Address? DHCP enabled?\r\n\t- If external, use the following tools:\r\n\t\t- Use Threat Analytics Search to make a quick assessment of the reputation\r\n\t\t- www.Centralops.net\r\n\t\t- www.Tcpiputils.com \r\n\t\t- Other (public) Threat intel sources\r\n\t- Identify Source / Destination Hostname(s)\r\n\t- Identify Target Hostname(s)\r\n\t- Identify affected Source / Destination Port(s)\r\n\t- Identify Operating System and affected services\r\n\r\n<strong>Identify the attack vector</strong>\r\n- Email, Instant Messaging, IRC, etc\r\n- Malicious websites/browser redirects\r\n- OS, Application, or Browser vulnerabilities (or feature/functionality)\r\n- Host configuration; services, shares, accounts/passwords, etc\r\n\r\n<strong>Research the Context of the attack</strong>\r\n- Research the detected malware type(s)\r\n\t- What does it do? How does it infect a host? Name of malware?\r\n\t- Does is disable services? (i.e FW, AV/AS, HIPS)\r\n\t- Does it drop files? if so where?\r\n\t- What’s the propagation method?\r\n\t\t- Email delivery? (is the actual email in the logs?)\r\n\t\t- Web delivery (can you identify the domain?)\r\n\t- Is there a System level or share-level infection?\r\n\t- What’s the probability of other infections?\r\n\t- What is the file path & name?  This can indicate the infection vector (e.g. filename.msg may infer it was via email, C:\\Users\\jdoe\\AppData\\Local\\Microsoft\\Windows\\Temporary Internet Files\\ may infer it was via web browser.\r\n\t- Are there mitigation steps required? Did AV successfully \"clean\" the infection? \r\n\t- Detailed Indicators of Compromise (IoC's) associated with the security event(s)\r\n\r\n<strong>Identify if any <Customer's> devices are attempting communications with \"malicious IP's\"</strong>\r\n- Did the host call back to a known bad command and control site?\r\n- Identify Network protection (Firewalls, IDS/IPS, Endpoint Threat Protection, Sink Hole, Proxy)\r\n- Identify all known vulnerabilities (CVE, AV DAT version, recent exploits, etc.)\r\n- All activity with similar Source or Destination address in last 5-30 days \r\n- Detailed definitions of relevant signatures\r\n- Any correlating information from external sources (immediately known Intel)\r\n- Run a KQL to search for both the offending IP/domain and for the specific indicator to see if any other hosts are making similar connection attempts.\r\n\t\t\t \r\n### Step 3: Analyze and Assess the Impact of the Attack\r\nThe Analysts should investigate any Attack by using any/all internal and external tools and resources. \r\n\r\n<strong>Additionally, all Analysts should be prepared to answer the following:</strong>\r\n- Was the attempt successful?\r\n- How many hosts are involved?\r\n- Was the IP blocked by the FW or Proxy?\r\n- Were any Customers impacted?\r\n\r\n<strong>What was the origin and/or details about the attacker IP?</strong>\r\n- WhoIs, Domain tools\r\n- Spoofed IP (pcap analysis is required)\r\n- Skill of attacker (automated scripts vs. obfuscation attempts)\r\n- Country, ISP, Business (what is the net block)\r\n\r\n<strong>What was attacked?</strong>\r\n- DMZ\r\n- Corporate systems\r\n- Database(s)\r\n- [CUSTOMER's] Application(s) - Web?\r\n\r\n<strong>What did they do (or try to do)?</strong>\r\n- Identify names of IDS signatures or alarms, as well as definitions of the various signatures. \r\n- What broad categories do all the events fit in? (Web, OS, Application, SQL, etc...) \r\n\r\n<strong>When did they do it?</strong>\r\n- Identify all date-time-groups (DTG), attack timeline (fast/slow), time of day in source IP time zone. \r\n- Identify a series of subtle events or rash of attacks (fast/slow)\r\n- Same time of day vs. various times\r\n\r\n<strong>Where did they attack from?</strong>\r\n- Identify the IP address of attacked system(s), external/internal/DMZ, applications, open ports, vulnerabilities, and usernames (if any). \r\n\r\n<strong>Why did they do it?</strong>\r\n- Identify the purpose of the attack. Targeted or random?\r\n- Web Defacement\r\n- Admin access\r\n- Reconnaissance \r\n- Dos/DDoS or other outage\r\n\r\n<strong>How did they go about it?</strong>\r\n- Identify the tool used (vulnerability scanner, port scanner), hand crafted, type of attack (buffer overflow, SQL injection, format string), protocol used, flags set, or other details. \r\n\t \r\n### Step 4: Determine What Action is Needed\r\nDepending on the severity of the Incident, an analyst may need to report the Incident in several manners. The outcome of the analysis should prompt the analyst to perform one or more of the following actions. Once one of the below actions are taken, the Incident(s) should be tagged using the appropriate tags as detailed in the Incident Triage Workflow Procedures.\r\n\r\n#### Close Incidents\r\n- If the Incident(s) are either false positives or do not warrant further attention, the Incident(s) should be closed.\r\n- This may be the case when traffic is blocked by a proxy device or firewall or if the traffic is normal traffic that is triggering false positives.\r\n- If an Incident is concluded to be a false positive, a filter request should be completed in the Shift Logs section.\r\n\r\n#### Report Incidents in Shift Logs\r\n- If the Incidents should be noted for future analysis or operational meetings, the Incident should be reported in the Shift Logs section.\r\n- A shift log entry should be created using the Shift Log Management Procedures.\r\n\r\n#### Escalating Incidents\r\n- If the Incidents should be escalated for further analysis by other teams or internal SOC analysts, the Incidents should be escalated per the Incident Triage Procedures.\r\n\r\n#### Creating Incidents\r\n- The SOC Analyst has determined that an Alert or series of Alerts/Events appear to be related and warrant further investigation.\r\n- Refer to these procedures in order to open a Incident."
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Incident Analysis"
            },
            "name": "Incident Analysis Text"
          },
          {
            "type": 1,
            "content": {
              "json": "## Information Fusion Procedures\r\n\r\n### Description\r\nThe Information Fusion Procedure is important in that it assures that all SOC Analysts are properly informed of the latest global security threats. \r\n\r\n### SOC Analyst Procedures\r\nAll SOC Analysts should perform the following tasks: \r\n- Read current Intelligence Reports. \r\n- The Daily Intelligence Report will cover the latest threats, external news and operational news. \r\n- Query Azure Sentinel for internal events that may correlate with news provided by Intelligence Reports. \r\n- Review all news and messages sent via email. \r\n- Relay all news of significant events and messages provided by other [Customer]'s Teams via email and update the shift log report. \r\n\r\n### Sr. SOC Analyst Procedures\r\nAll Senior SOC Analysts will create the Daily Intelligence Report, Weekly Intelligence Reports and other reports as defined in the Roles and Responsibilities. These reports will provide necessary information to all analysts within the SOC.  Senior SOC Analysts own the following reports and processes:\r\n\r\n| Report | Description |\r\n| : | : |\r\n| Daily Intelligence Report | The Daily Intelligence Report is produced to inform Analysts of Threats, External News and Operational News. |\r\n| Weekly Threat Report | The Weekly Threat Report is produced to inform analysts of key issues and other significant metrics for each week. |\r\n\r\n\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Information Fusion"
            },
            "name": "Information Fusion Procedures Text"
          },
          {
            "type": 1,
            "content": {
              "json": "## Focused Monitoring Procedures\r\n\r\n### Description\r\nOnce an Incident has been created, the Focused Monitoring procedure is initiated. This procedure is designed to ensure that the SOC is closely monitoring a previously recognized situation for further expansion of its scope or character. \r\n- Ensure all Source IPs are added to an Azure Sentinel Livestream for continued monitoring. (Example below) \r\n- Ensure all Destination IPs are added to an Azure Sentinel Livestream for continued monitoring. \r\n- Gather all relevant historical information from any Entities listed from within the Incident and add history to the Incident comments. \r\n- Any Incident-relevant events/alerts triggered by the same source should be noted in the Incident comments. \r\n- Any events/alerts originating from internal Source IPs, which were previously Destination IPs in the original attack, should be added to the Incident comments. \r\n\r\nFocused Monitoring is leveraged during an incident and/or monitoring of a series of alerts or events for business impact analysis; network, operations, service levels, productivity and to monitor for further propagation or to monitor to determine if the incident/issue is increasing or decreasing in scope.\r\n\r\n### Procedure\r\n- Create an Azure Sentinel Livestream based upon varying details or perspectives;\r\n\t- Example using Entity type Source/Destination IPs:\r\n\t\t- Ensure all Source IPs are added to an Azure Sentinel Livestream for continued monitoring.\r\n\t\t- Ensure all Destination IPs are added to an Azure Sentinel Livestream for continued monitoring.\r\n\t\t- Ensure that the Incident gets updated and that the appropriate team members are appraised\r\n\t- Gather all relevant historical information from any Entities listed from within the Incident and add history to the Incident comments.\r\n\t- Any Incident-relevant events/alerts triggered by the same source should be noted in the Incident comments. \r\n\t- Additional, you must update the applicable Incident documentation sections; i.e. Follow-up, Analyst Comments, etc\r\n\t- Any events/alerts originating from internal Source IPs, which were previously Destination IPs in the original attack, should be added to the Incident comments. \r\n- Update the SOC Shift Logs.\r\n\r\n### An Example\r\nBelow is an example for creating an Azure Sentinel Livestream.\r\n\t\r\n#### To create a livestream session from scratch:\r\n1. Select the Livestream tab\r\n1. Click + New livestream.\r\n1. On the Livestream pane:\r\n\t- If you started livestream from a query, review the query and make any changes you want to make.\r\n\t- If you started livestream from scratch, create your query.\r\n1. Select Play from the command bar.\r\n\t- The status bar under the command bar indicates whether your livestream session is running or paused. In the following example, the session is running:\r\n\r\n![Livestream Session](https://docs.microsoft.com/azure/sentinel/media/livestream/livestream-session.png)\r\n\r\nSelect Save from the command bar.\r\n- Unless you select Pause, the session continues to run until you are signed out from the Azure portal.\r\n\t\r\n#### To View your livestream sessions:\r\n1. In the Azure portal, navigate to Sentinel > Threat management > Hunting > Livestream tab.\r\n2. Select the livestream session you want to view or edit.\r\nFor example:\r\n\r\n![Livestream Tab](https://docs.microsoft.com/azure/sentinel/media/livestream/livestream-tab.png)\r\n\r\nYour selected livestream session opens for you to play, pause, edit, and so on.\r\n\t\t\r\n#### To receive notifications when new events occur:\r\n1. Because livestream notifications for new events use Azure portal notifications, you see these notifications whenever you use the Azure portal. For example:\r\n\r\n![Livestream Notification](https://docs.microsoft.com/azure/sentinel/media/livestream/notification.png)"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Focused Monitoring"
            },
            "name": "Focused Monitoring Procedures Text"
          },
          {
            "type": 1,
            "content": {
              "json": "## Host Analysis Process\r\n\r\n### Summary\r\nHost Analysis is a vital and cautious part of the Security Operations Center response processes. This process extends into the research and analysis for malicious code, social engineering and/or unauthorized system modification down to the endpoint. Particular caution must be taken in this process as not to violate privacy laws either domestic or international. Additionally, the analysts objectives is to not to render forensic evidence inadmissible in the event of legal litigation.\r\n\r\nThe intent of this document is to provide consistent, repeatable, and objective guidance in performing host investigation to include information gathering, anomaly analysis, triage and escalation for a potentially compromised Business Unit asset.\r\n\r\n### Scope\r\nThe process and procedures defined in this document must be conducted on the [Customer] and it's subsidiaries assets;\r\n\r\n- To confirm validity and severity of a detection via Azure Sentinel with Defender for Endpoints  (via use cases or raw analysis). \r\n- To confirm validity and severity of symptoms and behavior reported by an [Customer] team member. \r\n- To confirm validity of abuse complaints. \r\n- Determine the points of entry and type of compromise. \r\nIdentification of areas for further investigation and issues for attention.\r\n\r\n### Inappropriate Content\r\nIf suspicious or malicious Content is discovered during the course of the host investigation, the analyst is to immediately disengage from the host investigation and follow the escalation procedure for engaging the SOC Manager and/or IR Team. HR. The escalation to SOC Manager must also include the Incident information relative to the investigation for potential system compromise; logic which triggered alert, Incident notes, steps taken thus far, directories accessed, tools used, and a summary of the current state of the system.\r\n\r\n- Do not take screenshots of said content \r\n- Do not modify the file/folder of said content \r\n- Do not copy, modify or delete the files and/or folders in which said content is located. \r\n- Do not engage a [Customer] Team Member nor their respective manager\r\n\r\n### International Privacy Concerns\r\nPlease be aware of differing international requirements and restrictions which are potentially applicable in regards to responding and investigating a host for potential compromise. For the purpose of this section we will focus on the following countries related to EU privacy law; France, Germany, & Sweden. Other countries may be applicable; however, as a rule of thumb, when in doubt refer to the SOC Manager and respectively your legal representatives.\r\n\r\n- Do not access folder(s) that are labeled as private; or confidential located in the team member's user profile. \r\n- Do not access folders that contain user's personal information. \r\n- If there is definitive cause and justification to access the restricted folder; you must escalate to the Office of Legal Compliance.\r\n\t- For example, malicious code may reside in the users\\appdata\\local\\temp or rogue COM files may have been placed into Temporary Internet Settings.\r\n\r\n### Malicious Content\r\nMalicious content must always be stored in a password protected, encrypted ZIP files. The password applied to the Zip container must be determined by your SOC Manager.\r\n\r\n### Pre-Requisites\r\n- Investigate entities on devices using Defender for Endpoints \"live response\"\r\n- Before you can initiate a session on a device, make sure you fulfill the following requirements:\r\n\t- Verify that you're running a supported version of Windows.\r\n\t- Devices must be running one of the following versions of Windows\r\n\t\t- Windows 10\r\n\t\t\t- Version 1909 or later\r\n\t\t\t- Version 1903 with https://support.microsoft.com/help/4515384/windows-10-update-kb4515384\r\n\t\t\t- Version 1809 (RS 5) with https://support.microsoft.com/help/4537818/windows-10-update-kb4537818\r\n\t\t\t- Version 1803 (RS 4) with https://support.microsoft.com/help/4537795/windows-10-update-kb4537795\r\n\t\t\t- Version 1709 (RS 3) with https://support.microsoft.com/help/4537816/windows-10-update-kb4537816\r\n\t\t- Windows Server 2019 - Only applicable for Public Preview\r\n\t\t\t- Version 1903 or with https://support.microsoft.com/help/4515384/windows-10-update-kb4515384 or later\r\n\t\t\t- Version 1809 with https://support.microsoft.com/help/4537818/windows-10-update-kb4537818\r\n\t- Enable Live Response from the Advanced Setting Page.\r\n\t\t- You will need to enable the Live Response capability in the (Advanced Features Settings) https://docs.microsoft.com/microsoft-365/security/defender-endpoint/advanced-features?view=o365-worldwide page.\r\n\t\t- NOTE: Only users with Manage Security or Global Admin roles can edit these settings.\r\n\t- Ensure that the device has an Automation Remediation level assigned to it.\r\n\t\t- You'll need to enable, at least, the minimum Remediation Level for a given Device Group. Otherwise you won't be able to establish a Live Response session to a member of that group.\r\n\t- Ensure that you have the appropriate permissions.\r\n\t\t- Only users who have been provisioned with the appropriate permissions can initiate a session. For more information on role assignments, see (Create and manage roles) https://docs.microsoft.com/microsoft-365/security/defender-endpoint/user-roles?view=o365-worldwide.\r\n\t\t- Depending on the role that's been granted to you, you can run basic or advanced live response commands. Users permissions are controlled by RBAC custom role.\r\n\r\n### Initiate a Live Response Session on a Device\r\n1. Sign in to Microsoft Defender Security Center.\r\n2. Navigate to the devices list page and select a device to investigate. The devices page opens.\r\n3. Launch the live response session by selecting Initiate live response session. A command console is displayed. Wait while the session connects to the device.\r\n4. Use the built-in commands to do investigative work. For more information, see Live Response Commands listed below.\r\n5. After completing your investigation, select Disconnect session, then select Confirm.\r\n\r\nNOTE: (Basic Live Response Commands) https://docs.microsoft.com/microsoft-365/security/defender-endpoint/live-response?view=o365-worldwide#live-response-commands\r\n\r\nNOTE: (Advanced Live Response Commands) https://docs.microsoft.com/microsoft-365/security/defender-endpoint/live-response?view=o365-worldwide#advanced-commands\r\n\r\n### Download a file in the Background\r\nTo enable your security operations team to continue investigating an impacted device, files can now be downloaded in the background.\r\n\t\r\n- To download a file in the background, in the live response command console, type \r\n\tdownload <file_path> &.\r\n- If you are waiting for a file to be downloaded, you can move it to the background by using \r\n\tCtrl + Z.\r\n- To bring a file download to the foreground, in the live response command console, type \r\n\tfg <command_id>.\r\n\r\nHere are some examples:\r\n\r\nDOWNLOAD A FILE IN THE BACKGROUND\r\n\r\n| Command | What it Does |\r\n| : | : |\r\n| Download \"C:\\windows\\some_file.exe\" & | Starts downloading a file named some_file.exe in the background. |\r\n| fg 1234 | Returns a download with command ID 1234 to the foreground. |\r\n\r\n### Put a file in the library\r\nLive response has a library where you can put files into. The library stores files (such as scripts) that can be run in a live response session at the tenant level.\r\nLive response allows PowerShell scripts to run, however you must first put the files into the library before you can run them.\r\nYou can have a collection of PowerShell scripts that can run on devices that you initiate live response sessions with.\r\n\r\n### To upload a file in the library\r\n1. Click Upload file to library.\r\n2. Click Browse and select the file.\r\n3. Provide a brief description.\r\n4. Specify if you'd like to overwrite a file with the same name.\r\n5. If you'd like to be, know what parameters are needed for the script, select the script parameters check box. In the text field, enter an example and a description.\r\n6. Click Confirm.\r\n7. (Optional) To verify that the file was uploaded to the library, run the library command.\r\n\r\n### Additional Commands & Running Scripts see the URL\r\nhttps://docs.microsoft.com/microsoft-365/security/defender-endpoint/live-response?view=o365-worldwide\r\n\r\n### Roles & Responsibilities\r\n- <strong>SOC Analysts</strong>: to conduct host investigation within the parameters of the defined procedure, providing a detailed account of their investigation and findings.\r\n- <strong>SOC Manager</strong>: is responsible for the successful execution of process and procedures of his/her respective team members.\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Host Analysis Process"
            },
            "name": "Host Analysis Process Text"
          },
          {
            "type": 1,
            "content": {
              "json": "## Subtle Event Process\r\n\r\n### Purpose \r\nThe purpose of this process is to describe the procedures SOC Analysts will use to detect subtle events. \r\n\r\n### Scope \r\nSubtle events are those security events that are difficult to detect during operational monitoring due to extended time or other tactics used to disguise attacks. This process applies to all Incidents/Alerts/Events that are presented within the Azure Sentinel Incidents Blade. \r\n\r\n### Process Summary \r\nAll SOC Analysts are responsible for detecting significant intrusions and attempts that are missed in standard operational monitoring. A subtle event is an attack that is intentionally crafted to be difficult to detect. These include; unknown signatures, low & slow, IDS evasion, and other attack patterns that are difficult to detect in operational time (5-15 minutes). Operational time is the time frame from the first appearance of an Incident/Alert/Event in the Azure Sentinel Incidents Blade until the SOC Analyst clears it, either by tagging it for review or by closing it out. Highly skilled attackers will often conduct attacks that happen over much larger time windows than any individual Incident/Alert/Event will remain through monitoring, thus once operational time is exhausted there exists a set of analytical disciplines that are meant to discover these attacks by looking at larger sets of data. The primary purpose of this process is to discover highly skilled attackers and to recognize patterns of attack that are not widely recognized. \r\n\r\nAll SOC Analysts are responsible for conducting weekly analysis using Azure Sentinel's Hunting Blade.\r\n\r\nThe Data Exploration procedure defines the analytical methodologies for SOC Analysts to look at larger security datasets and to conduct exploratory data analysis. This procedure will leverage the Hunting Blade and Hunting KQL Queries provided within Azure Sentinel. This procedure documents the mechanics of interacting with large datasets but cannot fully capture the complete analysis process as that is guided by the ingenuity of the individual analyst. \r\n\r\n### Roles & Responsibilities \r\n- SOC Manager owns the successful completion of all daily operational processes and procedures. The SOC manager is also responsible for ensuring these daily operational process effectively support SOC operations and for continuous process improvement. \r\n- SOC Analysts executes daily operations procedures as a matter of daily responsibility and owns the successful completion of all procedures executed during his/her presence in the SOC. SOC Analysts own the documentation and measurement of all subordinate procedures as well as the continual improvements to them.  The role of a SOC Analyst is the detailed and repeatable execution of all operational tasks as documented in this process and its subordinate procedures. \r\n\t\r\n### Additional Processes \r\n- Subordinate Procedures \r\n\t- Data Exploration\r\n- Related Process & Procedures \r\n\t- Reporting Process \r\n\t- Intrusion Analysis Process \r\n\r\n### Process Owner's Names \r\nSOC Manager \r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Subtle Event Process"
            },
            "name": "Subtle Event Process Text"
          },
          {
            "type": 1,
            "content": {
              "json": "## Data Exploration Procedures\r\n\r\n### Description \r\nThis topic describes the procedures for using Azure Sentinel's Hunting Blade to review security events for abnormalities. Data Exploration is concerned with the identification of IOCs that were previously unknown or the hidden within data sets. These IOCs can then be addressed or operationalized for situational awareness.\r\nIf you're an investigator who wants to be proactive about looking for security threats, Azure Sentinel powerful hunting search and query tools to hunt for security threats across your organization's data sources. But your systems and security appliances generate mountains of data that can be difficult to parse and filter into meaningful events. To help security analysts look proactively for new anomalies that weren't detected by your security apps, Azure Sentinel' built-in hunting queries guide you into asking the right questions to find issues in the data you already have on your network.\r\n\r\n### Hunt for threats\r\nWith Azure Sentinel hunting, you can take advantage of the following capabilities:\r\n\r\n- Built-in queries: To get you started, a starting page provides preloaded query examples designed to get you started and get you familiar with the tables and the query language. These built-in hunting queries are developed by Microsoft security researchers on a continuous basis, adding new queries, and fine-tuning existing queries to provide you with an entry point to look for new detections and figure out where to start hunting for the beginnings of new attacks.\r\n- Powerful query language with IntelliSense: Built on top of a query language that gives you the flexibility you need to take hunting to the next level.\r\n- Create your own bookmarks: During the hunting process, you may come across matches or findings, dashboards, or activities that look unusual or suspicious. In order to mark those items so you can come back to them in the future, use the bookmark functionality. Bookmarks let you save items for later, to be used to create an incident for investigation. For more information about bookmarks, see Use bookmarks in hunting.\r\n- Use notebooks to automate investigation: Notebooks are like step-by-step playbooks that you can build to walk through the steps of an investigation and hunt. Notebooks encapsulate all the hunting steps in a reusable playbook that can be shared with others in your organization.\r\n- Query the stored data: The data is accessible in tables for you to query. For example, you can query process creation, DNS events, and many other event types.\r\n- Links to community: Leverage the power of the greater community to find additional queries and data sources.\r\n\r\n### Start Hunting\r\n1. In the Azure Sentinel portal, click Hunting.\r\n\t\r\n![Start Hunting](https://docs.microsoft.com/azure/sentinel/media/tutorial-hunting/hunting-start.png)\r\n\t\r\n2. When you open the Hunting page, all the hunting queries are displayed in a single table. The table lists all the queries written by Microsoft's team of security analysts as well as any additional query you created or modified. Each query provides a description of what it hunts for, and what kind of data it runs on. These templates are grouped by their various tactics - the icons on the right categorize the type of threat, such as initial access, persistence, and exfiltration. You can filter these hunting query templates using any of the fields. You can save any query to your favorites. By saving a query to your favorites, the query automatically runs each time the Hunting page is accessed. You can create your own hunting query or clone and customize an existing hunting query template.\r\n3. Click Run query in the hunting query details page to run any query without leaving the hunting page. The number of matches is displayed within the table. Review the list of hunting queries and their matches. Check out which stage in the kill chain the match is associated with.\r\n4. Perform a quick review of the underlying query in the query details pane or click View query result to open the query in Log Analytics. At the bottom, review the matches for the query.\r\n5. Click on the row and select Add bookmark to add the rows to be investigated - you can do this for anything that looks suspicious.\r\n6. Then, go back to the main Hunting page and click the Bookmarks tab to see all the suspicious activities.\r\n7. Select a bookmark and then click Investigate to open the investigation experience. You can filter the bookmarks. For example, if you're investigating a campaign, you can create a tag for the campaign and then filter all the bookmarks based on the campaign.\r\n8. After you discovered which hunting query provides high value insights into possible attacks, you can also create custom detection rules based on your query and surface those insights as alerts to your security incident responders.\r\n\r\n### Additional Context can be found here\r\nhttps://docs.microsoft.com/azure/sentinel/hunting\r\n\r\n### Process Owner's Names \r\nSOC Manager \r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Data Exploration"
            },
            "name": "Data Exploration Process Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# SOC Use Cases\r\n\r\n## Description\r\nThe [CUSTOMER] Security Operations Center (SOC) is leveraging the SANS: Critical Controls for Effective Cyber Defense Framework & MITRE ATT&CK Framework to provide both a roadmap for future capabilities as well as establishing a reporting standard to drive security awareness and risk management. The Use Case library below contains the SANS CC aligned to the specific SOC Use Cases outlined within each respective MITRE ATT&CK Tactic.\r\n\r\nWhile partial or not all of the Critical Controls are within scope, the Security Operations Center in coordination with cross functional organizations and resources will continue to on-board additional devices/technologies, recommend additional security controls and/or capabilities of new or existing technologies to improve and mature the security posture, and continuously develop and refine use cases for both detection and reporting purposes.\r\n\r\nUtilize the Use Case Documentation Template to properly document all use cases.\r\n\r\n<strong>AZURE SENTINEL FUSION USE-CASES</strong>\r\n \r\nThese scenarios combine two of the fundamental logs used by security analysts: \r\n- Firewall logs from Palo Alto Networks and end-point detection logs from Microsoft Defender ATP. In all of the scenarios listed below, a suspicious activity is detected in the end point that involves an external IP address, then, this is followed by anomalous traffic from the external IP address back into the firewall. In Palo Alto logs, Azure Sentinel focuses on threat logs, and traffic is considered suspicious when threats are allowed (suspicious data, files, floods, packets, scans, spyware, URLs, viruses, vulnerabilities, wildfire-viruses, wildfires).\r\n\t- Network request to TOR anonymization service followed by anomalous traffic flagged by Palo Alto Networks firewall. https://docs.microsoft.com/azure/sentinel/fusion#network-request-to-tor-anonymization-service-followed-by-anomalous-traffic-flagged-by-palo-alto-networks-firewall\r\n\t- PowerShell made a suspicious network connection followed by anomalous traffic flagged by Palo Alto Networks firewall. https://docs.microsoft.com/azure/sentinel/fusion#powershell-made-a-suspicious-network-connection-followed-by-anomalous-traffic-flagged-by-palo-alto-networks-firewall\r\n\t- Outbound connection to IP with a history of unauthorized access attempts followed by anomalous traffic flagged by Palo Alto Networks firewall. https://docs.microsoft.com/azure/sentinel/fusion#outbound-connection-to-ip-with-a-history-of-unauthorized-access-attempts-followed-by-anomalous-traffic-flagged-by-palo-alto-networks-firewall\r\n- Using advanced multistage attack detection, Azure Sentinel supports the following scenarios that combine anomaly events from Azure Active Directory Identity Protection and Microsoft Cloud App Security:\r\n\t- Impossible travel to atypical location followed by anomalous Office 365 activity. https://docs.microsoft.com/azure/sentinel/fusion#impossible-travel-to-atypical-location-followed-by-anomalous-office-365-activity\r\n\t- Sign-in activity for unfamiliar location followed by anomalous Office 365 activity. https://docs.microsoft.com/azure/sentinel/fusion#sign-in-activity-for-unfamiliar-location-followed-by-anomalous-office-365-activity\r\n\t- Sign-in activity from infected device followed by anomalous Office 365 activity. https://docs.microsoft.com/azure/sentinel/fusion#sign-in-activity-from-infected-device-followed-by-anomalous-office-365-activity\r\n\t- Sign-in activity from anonymous IP address followed by anomalous Office 365 activity. https://docs.microsoft.com/azure/sentinel/fusion#sign-in-activity-from-anonymous-ip-address-followed-by-anomalous-office-365-activity\r\n\t- Sign-in activity from user with leaked credentials followed by anomalous Office 365 activity. https://docs.microsoft.com/azure/sentinel/fusion#sign-in-activity-from-user-with-leaked-credentials-followed-by-anomalous-office-365-activity\r\n \r\n\r\n### On-Board Anlytics Key\r\n\r\n| Status |\tUse Case is... |\r\n| : | : |\r\n| <p style=\"background-color:Tomato;\">&nbsp; Hold &nbsp;</p> | 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| <p style=\"background-color:Orange;\">&nbsp; Dev &nbsp;</p> | In development by content author. No Incident stage annotation or annotated as 'Development'.  No SOC action. |\r\n| <p style=\"background-color:LightGray;\">&nbsp; Test &nbsp;</p> | 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| <p style=\"background-color:MediumSeaGreen;\">&nbsp; Approved &nbsp;</p> | Currently in test but approved for production and awaiting the move to be Incident Enabled. |\r\n| <p style=\"background-color:DodgerBlue;\">&nbsp; Prod &nbsp;</p> | 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\n<strong>AZURE SENTINEL Analytics/Detection(s) On-board Tracking Table</strong>\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| <p style=\"background-color:DodgerBlue;\">1</p>\t| Advanced Multistage Attack Detection | Fusion\t| Persistence, Lateral Movement, Exfiltration, Command and Control |   |\r\n| <p style=\"background-color:DodgerBlue;\">2</p>\t| Create incidents based on Microsoft Defender Advanced Threat Protection alerts | Microsoft Security | Microsoft Defender Advanced Threat Protection​ (Preview) |   |\r\n| <p style=\"background-color:DodgerBlue;\">3</p>\t| Create incidents based on Microsoft Cloud App Security alerts | Microsoft Security | Microsoft Cloud App Security |   |\r\n| <p style=\"background-color:DodgerBlue;\">4</p> | Create incidents based on Azure Security Center for IoT alerts | Microsoft Security |\tAzure Security Center for IoT |   |\r\n| <p style=\"background-color:DodgerBlue;\">5</p>\t| Create incidents based on Azure Security Center alerts | Microsoft Security | Azure Security Center |   |\r\n| <p style=\"background-color:DodgerBlue;\">6</p>\t| Create incidents based on Azure Advanced Threat Protection alerts | Microsoft Security | Azure Advanced Threat Protection |   |\r\n| <p style=\"background-color:DodgerBlue;\">7</p>\t| Create incidents based on Azure Active Directory Identity Protection alerts | Microsoft Security | Azure Active Directory Identity Protection |   |  \r\n| <p style=\"background-color:DodgerBlue;\">8</p>\t| (Preview) Anomalous SSH Login Detection | ML Behavior Analytics | Syslog | Initial Access |\r\n| <p style=\"background-color:DodgerBlue;\">9</p>\t| User account created and deleted within 10 mins | Scheduled | Security Events\t| Persistence, Privilege Escalation |\r\n| <p style=\"background-color:MediumSeaGreen;\">10</p> | User account added to built-in domain local or global group | Scheduled | Security Events | Persistence, Privilege Escalation |\r\n| <p style=\"background-color:MediumSeaGreen;\">11</p> | Time series anomaly for data size transferred to public internet | Scheduled\t| Cisco ASA +2 | Exfiltration |\r\n| <p style=\"background-color:MediumSeaGreen;\">12</p> | Time series anomaly detection for total volume of traffic | Scheduled | Barracuda Web Application Firewall +6\t| Exfiltration |\r\n| <p style=\"background-color:MediumSeaGreen;\">13</p> | THALLIUM domains included in DCU takedown | Scheduled | DNS (Preview) +3 | Command and Control, Credential Access |\r\n| <p style=\"background-color:MediumSeaGreen;\">14</p> | Suspicious Resource deployment | Scheduled | Azure Activity | Impact |\r\n| <p style=\"background-color:MediumSeaGreen;\">15</p> | Suspicious number of resource creation or deployment activities | Scheduled |Azure Activity | Impact |\r\n| <p style=\"background-color:MediumSeaGreen;\">16</p> | Suspicious granting of permissions to an account | Scheduled | Azure Activity | Persistence, Privilege Escalation |\r\n| <p style=\"background-color:MediumSeaGreen;\">17</p> | Successful logon from IP and failure from a different IP\t| Scheduled | Azure Active Directory | Credential Access, Initial Access |\r\n| <p style=\"background-color:MediumSeaGreen;\">18</p> | SSH Potential Brute Force | Scheduled | Syslog | Credential Access |\r\n| <p style=\"background-color:MediumSeaGreen;\">19</p> | SSH newly internet-exposed endpoints | Scheduled | Syslog | Initial Access |\r\n| <p style=\"background-color:MediumSeaGreen;\">20</p> | Squid proxy events related to mining pools | Scheduled | Syslog | Execution, Impact |\r\n| <p style=\"background-color:Tomato;\">21</p> | Squid proxy events for ToR proxies | Scheduled | Syslog | Command and Control |\r\n| <p style=\"background-color:Tomato;\">22</p> | Sign-ins from IPs that attempt sign-ins to disabled accounts\t| Scheduled | Azure Active Directory | Initial Access, Persistence |\r\n| <p style=\"background-color:Tomato;\">23</p> | SharePointFileOperation via previously unseen IPs | Scheduled | Office 365 | Exfiltration |\r\n| <p style=\"background-color:Tomato;\">24</p> | SharePointFileOperation via devices with previously unseen user agents | Scheduled | Office 365 | Exfiltration |\r\n| <p style=\"background-color:LightGray;\">25</p> | Sensitive Azure Key Vault operations | Scheduled | Microsoft web application firewall (WAF) | Impact |\r\n| <p style=\"background-color:LightGray;\">26</p> | Security Event log cleared | Scheduled | Security Events | Defense Evasion |\r\n| <p style=\"background-color:LightGray;\">27</p> | RDP Nesting | Scheduled | Security Events | Lateral Movement |\r\n| <p style=\"background-color:LightGray;\">28</p> | Rare subscription-level operations in Azure | Scheduled | Azure Activity | Credential Access, Persistence |\r\n| <p style=\"background-color:LightGray;\">29</p> | Rare RDP Connections | Scheduled\t| Security Events | Lateral Movement |\r\n| <p style=\"background-color:LightGray;\">30</p> | Rare high reverse DNS count | Scheduled | DNS | Discovery |\r\n| <p style=\"background-color:LightGray;\">31</p> | Rare high NXDomain count | Scheduled | DNS | Command and Control |\r\n| <p style=\"background-color:LightGray;\">32</p> | Rare application consent | Scheduled | Azure Active Directory | Persistence, Lateral Movement, Collection |\r\n| <p style=\"background-color:LightGray;\">33</p> | Rare and potentially high-risk Office operations | Scheduled | Office 365 | Persistence, Collection |\r\n| <p style=\"background-color:LightGray;\">34</p> | Process execution frequency anomaly | Scheduled | Security Events | Execution |\r\n| <p style=\"background-color:LightGray;\">35</p> | Process executed from binary hidden in Base64 encoded file | Scheduled | Security Events | Execution, Defense Evasion |\r\n| <p style=\"background-color:LightGray;\">36</p> | Powershell Empire cmdlets seen in command line | Scheduled | Security Events | Execution, Persistence |\r\n| <p style=\"background-color:Orange;\">37</p> | Potential Kerberoasting | Scheduled | Security Events | Credential Access |\r\n| <p style=\"background-color:Orange;\">38</p> | Palo Alto - potential beaconing detected\t| Scheduled | Palo Alto Networks | Command and Control |\r\n| <p style=\"background-color:Orange;\">39</p> | Palo Alto - possible internal to external port scanning | Scheduled | Palo Alto Networks\t|  Discovery |\r\n| <p style=\"background-color:Orange;\">40</p> | 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: <strong>ASC Compliance and Protection</strong>\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 <strong>Incident Triage Procedure</strong> 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 <br> - No effect to the organization’s ability to provide all services to all users <br> - No breach of data / information was exfiltrated, changed, deleted, or otherwise compromised <br> - Single systems and/or users affected that contains PII or PCI <br> - Minimal recovery required <br> - Escalation directly to the respective Business Unit for remediation |\r\n|    | Examples: |\r\n|    | &nbsp; &nbsp; &nbsp; - Receipt of e-mail expressing “low-level” threat <br> &nbsp; &nbsp; &nbsp; - Discovery of a Phishing event without report of compromise |\r\n\r\n|   |\r\n| : | : |\r\n| SEV-3 | (Moderate) - Intermittent security alerts, moderate security impact |\r\n|    | - Non-critical systems (e.g., associate workstations), OR Non-critical infrastructure; internal impact is less than 5% <br> - Medium Severity, typically issues such as policy violations, single system infections and/or whereas the malicious code is known and contained <br> - Escalation directly to the respective Business Unit for remediation <br> - Severity 4 events that are not resolved within the established Service-Level Agreements (SLAs) |\r\n|    | Examples: |\r\n|    | &nbsp; &nbsp; &nbsp; - Isolated reconnaissance activities (network) by potential attackers <br> &nbsp; &nbsp; &nbsp; - Password policy violation by an employee <br> &nbsp; &nbsp; &nbsp; - Virus/Malware infection isolated to an individual user <br> &nbsp; &nbsp; &nbsp; - Single report of suspicion that someone has gained unauthorized access to his/her account <br> &nbsp; &nbsp; &nbsp; - Phishing/spear-phishing threat to compromise customer data <br> &nbsp; &nbsp; &nbsp; - Detection and removal of viruses by a server before it enters the network <br> &nbsp; &nbsp; &nbsp; - Repeated port scanning from same external source |\r\n\r\n|   |\r\n| : | : |\r\n| SEV-2 | (Major) - Serious Impact or Compromise, Incident/Attack affects multiple customers |\r\n|    | - Operations can continue in a restricted fashion, although long-term productivity might be adversely affected <br> - Organization has lost the ability to provide a critical service to a subset of system users <br> - Single High Value Targets affected or potentially compromised <br> - Impact to company confidential data <br> - Major or business-critical applications are affected <br> - Multiple systems that contain PII or PCI and/or users affected <br> - Critical impact to the organization (reputational) <br> - Severity 3 events that are not resolved within the established Service-Level Agreements (SLAs)  |\r\n|    | Examples: |\r\n|    | &nbsp; &nbsp; &nbsp; - Improper usage of high-level accounts such as root or administrator <br> &nbsp; &nbsp; &nbsp; - Phishing threats to compromise internal, sensitive data <br> &nbsp; &nbsp; &nbsp; - Vulnerability on a [CUSTOMER]'s non-transactional server or subnet <br> &nbsp; &nbsp; &nbsp; - Multiple users/workstations infected by malware <br> &nbsp; &nbsp; &nbsp; - Unauthorized disclosure of [CUSTOMER]'s internal or confidential information (i.e. email, blogs, news groups)  <br> &nbsp; &nbsp; &nbsp; - Spear-phishing attempts targeting [CUSTOMER]’s executives <br> &nbsp; &nbsp; &nbsp; - Internal web site was compromised without authorization |\r\n\r\n\r\n|   |\r\n| : | : |\r\n| SEV-1 | (Critical) - Critical Compromise, Major Service disruption or publicly displayed attack |\r\n|    | - Mission critical systems that support multiple businesses (systems defined as mission critical per Ops/Tech) OR sectors of the critical infrastructure (systems defined as Tier 0 for BCP/DR purposes) <br> - [CUSTOMER] has experienced a substantial loss of service and/or revenue <br> - Prevents [CUSTOMER] from making sales, or meeting legal or contractual obligations <br> - Potential regulatory fines or penalties <br> - Critical business impact to the company; competitive edge, reputational, data-privacy breach <br> - All or a substantial portion of [CUSTOMER]'s mission critical data is at a significant risk of loss or corruption <br> - [CUSTOMER]'s business operations have been severely disrupted <br> - Potential large financial risk or legal liability <br> - Multiple systems (HVT), significant number of workstations, groups and users affected; high probability of propagation <br> - Mission critical system (e.g., payroll system) to a single business <br> - Significant and immediate threat to human safety <br> - Complete system compromise and possible full data-privacy breach <br> - Law Enforcement assistance is required <br> - Severity 2 events that are not resolved within the established Service-Level Agreements (SLAs)  |\r\n|    | Examples: |\r\n|    | &nbsp; &nbsp; &nbsp; - Unauthorized access to sensitive systems (HR, Payroll, Finance, etc) <br> &nbsp; &nbsp; &nbsp; - Distributed Denial of Service Attacks or DoS Attacks <br> &nbsp; &nbsp; &nbsp; - Theft of computer systems and/or media containing sensitive/confidential information <br> &nbsp; &nbsp; &nbsp; - Malware causing destructive outbreak to a large number of workstations or servers (Zero day attacks) <br> &nbsp; &nbsp; &nbsp; - Defacement of [CUSTOMER]'s Web Sites <br> &nbsp; &nbsp; &nbsp; - Vulnerability on an [CUSTOMER]'s transactional server or subnet |\r\n\t\r\n### Step 2 - Initiate Action \r\nInitiate appropriate response action based on the outcome of the decision matrix above. \r\n\t\r\n|   |\r\n| : |\r\n| <strong>SEV1</strong> Annotate-Tag the Incident |\r\n| A Senior SOC  Analyst contacts the SOC manager with notification of potential callout. After review,confirmation, approval. Initiate the Critical Callout /Escalation Procedures  with a response time requirement of [10] minutes. |\r\n| Teams or Email contents of potential callout <br> - Time/Azure Sentinel Incident Number # <br> - 0730/20140312-007 (S1) Covered information disclosure <br> - Include your name as well as a phone number in any Teams or Email message |\r\n\r\n|   |\r\n| : |\r\n| <strong>SEV2</strong> Annotate-Tag the Incident |\r\n| A Senior SOC  Analyst contacts the SOC manager with notification of potential callout. After proper review, confirmation, approval. Initiate the Critical Callout /Escalation Procedures with a response time requirement of [20] minutes. |\r\n| Teams or Email contents of potential callout <br> - Time/Azure Sentinel Incident Number # <br> - 1830/20100312-004 (S2) IIS Directory Traversal <br> - Include your name as well as a phone number in any email |\r\n\r\n|   |\r\n| : |\t\t\r\n| <strong>SEV3</strong> Annotate-Tag Incident |\r\n| Work Incident internally, if a callout is needed promote case to a SEV-2. Follow appropriate rule response procedures. |\r\n\r\n|   |\r\n| : |\t\t\r\n| <strong>SEV4</strong>\tAnnotate-Tag Incident |\r\n| Low priority, work internally, if callout is necessary, promote case to a SEV-2. Follow appropriate rule response procedures. |\r\n\r\n### Step 3 - Document Activity in the Shift Log \r\nDocument the activity in the Shift Log using the Shift Log Management guidelines. \r\n\r\n### Step 4 - Continue to Monitor Activity \r\nInitiate the Focused Monitoring Procedures in support of other teams. \r\n\r\n### Step 5 - Follow Up on Activity \r\nEnsure that the appropriate response action is fully executed and the Incident, IR Ticketing and/or Closure procedures are completed.\r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Incident Triage"
            },
            "name": "Incident Triage Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Callout / Escalation\r\n\r\n## Description \r\nThe callout procedure is initiated once the on-duty SOC Analyst has completed the Incident Triage Procedures and determined that a callout is warranted. This procedure defines how the SOC notifies the Incident Response Team (IRT) of the recognized incident. Any SEV1 or SEV2 incident will always be escalated to the IRT as a first point of contact. This procedure falls under the Incident Management Process. After callout has been performed, annotate the Incident and Tag it to the proper stage (Senior Analyst escalation). \r\n\r\n## Flash Notification \r\n- Time/Azure Sentinel Incident Number #\r\n- 1830/20100312-004 (S2) IIS Directory Traversal\r\n- Summary - What happened?\r\n- Risk - Why do we care?\r\n- Actions - Escalations?\r\n- Include your name as well as a phone number in any Teams or Email message \r\n\r\n## Steps \r\n<strong>Critical Callout (SEV-1)</strong> \r\n- Open the Azure Sentinel Incident via Incident Management Procedures.\r\n- Notify the Incident Response Team (IRT) via Teams or the telephone\r\n- Wait 10 minutes for acknowledgement\r\n\t- On-Call / On-duty IRT team member is messaged by Teams or emailed upon Incident being Tagged SEV-1. \r\n\t- Wait 5 minutes for acknowledgement \r\n\t- Call on-duty back up again \r\n\t- Wait 5 minutes for acknowledgement \r\n- Call Incident Response Management\r\n- Continue to cycle until acknowledgement received \r\n\t\t\r\n<strong>Urgent Callout (SEV-2)</strong> \r\n- Notify the Incident Response Team (IRT) via Teams or the telephone\r\n\t- Wait 20 minutes for acknowledgement \r\n\t- Call on-duty team member \r\n\t- Wait 10 minutes for acknowledgement \r\n\t- Call on-duty back up\r\n\t- Wait 10 minutes for acknowledgement \r\n- Call Incident Response Management\r\n- Continue to cycle until acknowledgement received \r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Callout / Escalation"
            },
            "name": "Callout / Escalation Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Incident Management Procedure\r\n\r\n## Description\r\nThe Incident Management Procedure is initiated once the SOC Analyst has determined that an Incident or series of Incidents appear to be related and warrant further investigation. This page details the steps an Analyst should take in order to create an informed and standardized Incident. Azure Sentinel definition: An Azure Sentinel Incident is a container for information about a specific Alert(s), usually with one or more Entities, Alerts, and Events attached. An Incident is used to track, investigate, and resolve Alert(s) of interest or a series of raw and correlated events that created an Alert that need further investigation. An Incident should be created any time an analyst is looking into events of interest through a KQL Query.\r\n\r\n## Azure Sentinel Incidents\r\n- <strong>SOC Incidents / New</strong>: For newly identified cases before being assigned to the SOC Analysts or the IR team. \r\n- <strong>SOC Incidents / Active - SOC Assigned</strong>: For Incidents analysts are working on internally. Only Incidents that are updated daily by a SOC Tier 1/Tier 2 Analyst.\r\n- <strong>SOC Incidents / Active - IR Assigned & Tagged</strong>: Used by the Incident Response Team investigators to manage their Incidents.\r\n- <strong>SOC Incidents / Active - ExT Assigned & Tagged</strong>: Used by External Team investigators to manage their Incidents. \r\n- <strong>SOC Incidents / Closed</strong>: Categories of CLOSED Incidents. \r\n\t- <strong>CLOSED - No Risk</strong>: For events that were added to cases and were determined to be of no risk to the [CUSTOMER] Enterprise.\r\n\t- <strong>CLOSED - Insufficient Data</strong>: For cases that were unable to determine the root cause. Subcategories might be added for more detailed tracking and measurements. \r\n\t- <strong>CLOSED - False Positive</strong>: For cases that were determined to be a false positive. \r\n\t- <strong>CLOSED - Remediated</strong>: For cases with a validated conclusion. Subcategories might be added for more detailed tracking and measurements to improve time to resolution. \r\n\t- <strong>CLOSED - Other</strong>: Cases that have been closed that don’t match the previously identified closure codes.\r\n\r\n## Find an Incident\r\n- From the Azure Sentinel Menu, Select Incidents. The Incidents page lets you know how many incidents you have, how many are open, how many you've set to In progress, and how many are closed.\r\n\r\n![Investigate Incidents](https://docs.microsoft.com/azure/sentinel/media/tutorial-investigate-cases/incident-severity.png)\r\n\r\n- You can filter the incidents as needed, for example by tag, status, or severity.\r\n\r\n![Incident Tags](https://techcommunity.microsoft.com/t5/image/serverpage/image-id/232940i1CCFD101BCBB19EE/image-size/large?v=v2&px=999)\r\n\r\n## Procedure \r\n### Open an Incident \r\n- Determine that an Incident has the appropriate Alerts/Events to investigate (see Incident Triage Procedures) \r\n- Add events of interest to the Incident through Bookmarks and attaching them to the Incident.\r\n\t- Create a Bookmark\r\n\t\t1. In the Azure portal, navigate to Sentinel > Logs and execute the desired KQL query.\r\n\t\t2. From the log query results list, use the checkboxes to select one or more rows that contain the information you find interesting.\r\n\t\t3. Select Add bookmark:\r\n\t\t\t\t\r\n\t\t![Create Bookmark](https://docs.microsoft.com/azure/sentinel/media/bookmarks/add-hunting-bookmark.png)\r\n\t\t\t\t\r\n\t\t4. On the right, in the Add bookmark pane, optionally, update the bookmark name, add tags, and notes to help you identify what was interesting about the item.\r\n\t\t5. In the Query Information section, use the drop-down boxes to extract information from the query results for the Account, Host, and IP address entity types. This action maps the selected entity type to a specific column from the query result. For example:\r\n\t\t\t\t\r\n\t\t![Map Entity Types](https://docs.microsoft.com/azure/sentinel/media/bookmarks/map-entity-types-bookmark.png)\r\n\t\t\t\t\r\n\t\t6. To view the bookmark in the investigation graph (currently in preview), you must map at least one entity type that is either Account, Host, or IP address.\r\n\t\t7. Click Save to commit your changes and add the bookmark. All bookmarked data is shared with other investigators, and is a first step toward a collaborative investigation experience.\r\n\t- Add bookmarks to a new or existing incident\r\n\t\t1. In the Azure portal, navigate to Sentinel > Threat management > Hunting > Bookmarks tab, and select the bookmark or bookmarks you want to add to an incident.\r\n\t\t2. Select Incident actions (Preview) from the command bar:\r\n\t\t\t\t\r\n\t\t![Incident Actions](https://docs.microsoft.com/azure/sentinel/media/bookmarks/incident-actions.png)\r\n\t\t\t\t\r\n\t\t3. Select either Create new incident or Add to existing incident, as required. Then:\r\n\t\t4. For a new incident: Optionally update the details for the incident, and then select Create.\r\n\t\t5. For adding a bookmark to an existing incident: Select one incident, and then select Add.\r\nTo view the bookmark within the incident: Navigate to Sentinel > Threat management > Incidents and select the incident with your bookmark. Select View full details, and then select the Bookmarks tab.\r\n\r\n## Incident Description \r\n- Incident Name \r\n\t- Use the following Naming convention as follows: yyyy-mm-dd - 001 - Event name and/or details \r\n\t- Example: 2021-04-21 - 001 - Local Account Authentication\r\n\t\t- NOTE: This is only for New Incidents created manually.\r\n\t\t- For Incidents created/generated by Security Tools outside of Azure Sentinel, they will already have a Title and Description assigned. \r\n- Incident stage ( Examples: Triaged, Queued, Open, Initial, Follow-up, etc..) \r\n- Incident Severity \r\n\t- Assign the Incident severity using the Incident Triage Procedures (i.e. SEV-1, SEV-2, SEV-3, SEV-4)\r\n- Document details and observations (use the following template for information gathering) \r\n\t- Attacker Information - Contains Shift log entry and Source IP information including: IP/hostname/port/whoIS/abuse contact/blacklisted/IPAM and Outlook contact info \r\n\t- Target Information - Contains Destination IP information including: IP/hostname/port/whoIS/abuse contact/blacklisted/IPAM and Outlook contact info \r\n\t- Event Description - IDS/IDP Signature/Firewall Event Analysis/Anti-Virus detail (obtained from filename and website) \r\n\t- Analyst Comments - Analyst comments (conclusion) and reference material (previous cases/emails/action items/intel papers) \r\n\r\n## Assign the Incident \r\n- Re-tag the Incident from Open to Under Investigation\r\n- Assign the Incident to yourself or if you are escalating, leave the Incident unassigned and apply the correct annotation-tag described in the \r\n- Perform appropriate notifications (to IR team or SOC Analyst). See the Callout Procedures. \r\n\r\n## Updating the Status \r\n- All SOC Analysts will review the Incident and assign the Incident the appropriate stage. The stage of the Incident will need to be updated as necessary and as defined by the Stage Timing Chart.\r\n- SOC Analysts will update the Incident with the annotation-tag \"Follow-up\" addressing the following: \r\n\t- Actions Taken \r\n\t- Follow-up Contact \r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Incident Management Procedure"
            },
            "name": "Incident Management Procedure Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Crisis Response\r\n\r\n## Description \r\nA crisis is defined as a series of events that may compromise the integrity of a large number of systems, multiple organizational zones or networks resulting in catastrophic data loss, prolonged organizational downtime, or major financial impact. A SOC Analyst should initiate the Crisis Response procedures for any event that is likely to cause major impact to the organization. \r\n\r\n## Step 1 - Gather Information\r\nThe first step a SOC Analyst should do in response to a perceived crisis situation is to gather basic information about the attack. \r\nImportant information includes: \r\n- Source IP Addresses \r\n- Destination IP Addresses \r\n- Time of Attack \r\n- Context and Depth of Attack \r\n- Estimated Impact \r\n\t\r\nIt is very unlikely all information in a Crisis situation will be immediately present, but it is important that the SOC Analyst understand a basic scope of the attack/crisis before engaging another team. <strong>It is critical that all steps taken be documented in the shift log as the steps are being taken.</strong> During a crisis, the Primary Analyst (on-console) will remain on console for the remainder of the shift or until the crisis is remediated. A SOC Analyst that is not on console will be responsible for all communication efforts if a Senior SOC Analyst is not present and would assist the SOC Analyst if present. \r\n\r\n## Step 2 - Escalate Events and Notify Teams \r\nOnce an Incident with Alerts/Events or series of Alerts/Events are recognized as a crisis, a Senior Analyst should be contacted immediately. If a Senior Analyst cannot be reached, the SOC Analyst should contact SOC Management. \r\n\t\r\n<strong>SOC Management</strong>\r\n\r\nAfter the situation has been discussed with a Senior Analyst/Manager, a callout to other teams should occur to begin the mitigation process. The SOC should be the central hub of communication during a crisis. <strong>The Incident Responder on-call member should be notified in all crisis situations.</strong>\r\n\t\r\nHere is a sample listing of teams to involve in different crisis situations. Every crisis situation is unique and must be handled in the manner most likely to resolve the crisis.\r\n\r\n| Crisis | Teams |\r\n| : | : |\r\n| Virus/Worm Outbreak |\tCommand Center, Helpdesk Team |\r\n| Network Intrusion | Network Team |\r\n| 10+ Server Compromise | Server Team, Network Team |\r\n| Effective DDoS Attack | Command Center, Network Team |\r\n| Outbound Attack on Sensitive Networks (gov, .mil, .cn) | Network Team |\r\n| Serious Impact to Business Processes | Command Center, Network Team, Server Team |\r\n\r\n\r\nContact Emails: SOC Contacts \r\nPage will contain: \r\n- Brief description of incident \r\n- SOC telephone number \r\n\t\r\nIn addition to notifying Security Teams, we should also contact other Ancillary Teams that could monitor or provide assistance during a crisis. <strong>Use appropriate wording. For example instead of \"denial of service\" you might use \"server performance issues\" when contacting teams outside of Security.</strong>\r\n\t\r\nBelow are distribution lists to reach Field Support managers and team leads for informational emails. These teams should be notified when a crisis is occurring. \r\n\r\n| Distribution List |\r\n| : | : | : | : |\r\n| Field Support managers | Email | Teams | Phone |\r\n|   |   |   |   |   |\r\n\r\n\r\nBelow are manager line numbers for emergency contacts to engage these teams during a crisis. \r\n\r\n| Emergency Contacts|\r\n| : | : | : |\t\r\n| Team | Description/Actions | Manager's Line |\r\n| Command Center | Initial Crisis Response Point, Information Coordination |   |\t  \r\n| Server Team |\tAnalyze and take offline servers |   |\t  \r\n| Network Team | Bring down networked devices |   |\t  \r\n| Applications Team | Application administration |   |\t  \r\n| Field Support (reached via Command Center) | Remote on-site support |   |   |\r\n\r\n## Step 3 - Information Coordination \r\nCollect additional analytical information about the crisis and coordinate in a manner in which each team receives the same information. It is the Senior Analyst's responsibility to coordinate each team's efforts (if a Senior Analyst/Manager is not available, the task falls to a SOC Analyst that is not on console). This can be done by using one or more of the following communication methods: Conference Call, Phone Bridge, or SOC War Room. \r\n\t\r\n<strong>Conference Call</strong> - If the number of technicians working on the crisis is low (less than 5 people) a conference call can be initiated to coordinate efforts. Note: This is usually only used in the latter stages of crisis resolution when specific technical personnel have been identified to solve the problem. See how to initiate a conference call: Telephone Functions \r\n\t\r\n<strong>Phone Bridge</strong> - Phone Bridges are the standard way of communicating across multiple teams and should be used when more than 5 technicians are on the call. See how to initiate a phone bridge: Phone Bridge Information \r\n\r\nPhone bridges will typically include: \r\n- SOC Management \r\n- SOC Support (as needed) \r\n\t- Incident Response Team \r\n\t- Data Center Operator \r\n\t\t- Event Manager \r\n\t\t- Fix Analyst \r\n\t\t- Fix Manager \r\n\t- Ancillary Teams (as needed) \r\n\t\t- Server Team \r\n\t\t- Network Team \r\n\t\t- Applications Team \r\n\t\t- Etc. \r\n\t\r\n\tNOTE: Teams will identify their Fix Managers, Fix Analysts, and other key players as the Crisis Response requires. \r\n\r\n<strong>SOC War Room</strong>  - The SOC will likely be the area where multiple teams meet for face-to-face communication. The SOC War Room will be the CCC Conference Room. A Crisis Response situation will supersede any reservations other teams may have for the CCC Conference Room. A Word Document page or a SharePoint OneNote should be created and displayed in the SOC War Room to serve as a whiteboard to capture and manage current response actions. \r\n\r\n##Step 4 - Information Management \r\nThe SOC will provide hourly updates on the crisis to the involved teams as well as Upper Management. A Senior SOC Analyst will provide hourly e-mails and be responsible for keeping each team updated and in sync. Each update should include a timeline of events and current actions taking place by teams. An example is below. \r\n\t\r\nThe SOC will generate a final email detailing the events involved in the crisis, steps that were taken to resolve the crisis and further actions that may be necessary to return to status quo once the crisis is deemed over. \r\n\r\n## Step 5 - Crisis Remediation \r\nThe final step involves identifying a solution to the crisis and implementing the solution. This step should be carried out by the team that owns the device(s) that will contribute in mitigating the crisis. The SOC can be used to contact internal [CUSTOMER]'s Systems teams and external parties if necessary. Detailed information of a contact to any internal or external person should be documented in the knowledge base including the name, contact information and action of the party. \r\n\t\r\nThe SOC should assist in further monitoring of the crisis and coordinating among teams until the resolution is implemented. Long-term incidents involving several teams will require team-member rotation. The SOC will work on a rotating schedule until the crisis is resolved. SOC Analysts will continue to work as scheduled. \r\n\r\n### Email Example\r\n\r\n![Email Example](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/EmailExample.png?raw=true)\r\n\r\n## Process Owner\r\nSOC Manager\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Crisis Response"
            },
            "name": "Crisis Response Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Shift Log Management\r\n\r\n## Description \r\nThis procedure describes how a SOC Analyst should use Shift Logs and what information should be provided in a shift log entry. \r\n\r\n## Shift Log Entries \r\nIt is very important for shift log entries to be clear and concise while providing the necessary information. When selecting the appropriate information to enter, an analyst should consider how shift log information is used. We primarily use shift log entries for two purposes: daily operational meetings, historical analysis and event reconstruction. \r\n\r\nThe following information should be entered in a shift log entry: \r\n- Source IP/hostname and Port (or just multiple if > 5) \r\n- Destination IP/hostname and Port (or just multiple if > 5) \r\n- External vs. Internal \r\n- Base Event name \r\n- Permit vs. Blocked \r\n- Number of related Incidents/Alerts/events \r\n- Basic reasoning behind creating case or closing events \r\n\t\r\nUsing the example below, your entry should include roughly the same type of information in the same order. \r\n\r\n## Creating Shift Logs \r\n<strong>Step 1 - Insert New Template Page</strong> \r\n\r\nLocate the OneNote Section for the current month and select that Section. Select the Shift Log Template and copy the contents to the new Month/Day Shift page. This page provides the template for the daily shift log pages. \r\n\t\r\nThe template page will be located on the Shift Logs section for the selected month. \r\n\t\r\n<strong>Step 2 - Enter Date and Analyst Name</strong>\r\n\r\nFor this example, on the monthly Example Shift Log OneNote Section for the current month we will add the date and Analyst Name to a new page. Each Analyst will have their own page as shown below.\r\n\r\n![OneNote Analyst Page](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/OneNoteAnalystPage.png?raw=true)\r\n\r\n<strong>Step 3 - Make Changes as Needed</strong>\r\n\r\nMake the necessary changes to the date and time fields as well as any other links that should be changed. The instructions and proper format for these changes can be found directly Example Shift Log Entry as shown below.\r\n\r\n![Example Shift Log Entry](https://github.com/rinure-msft/Azure-Sentinel/blob/master/docs/ExampleShiftLogEntry.png?raw=true)\r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Shift Log Management"
            },
            "name": "Shift Log Management Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Phone Bridge Details\r\n\r\n## Description\r\nThis process details the steps an Analyst takes to join a Conference Bridge. Please update the information below with current numbers and participation codes.\r\n\r\n| Meeting Place dial in numbers: |\r\n| : | : |\r\n| Internal | 888-677-8000 |\r\n| Local + International | 877-624-8000 |\r\n| Toll Free | 855-446-6338 |\r\n\t\r\nNote:  To dial outside of the Company, use +8\r\n\r\n## Security Bridge\r\n425-495-4000 x4953\r\n\r\n## Other Bridge Details (changes monthly)\r\nTo start a phone bridge, use the following dial-in code: [253]\r\n\r\n## Steps to joining a Conference:\r\n1. You must use a touch-tone phone to participate in an Instant Meeting Conference.\r\n2. Dial the appropriate access number:\r\n\ta. Participants: Enter numeric passcode followed by a \"#\"\r\n\tb. Leaders: Enter your numeric leader passcode followed by a # sign.\r\n\r\n## Inviting other teams to join a bridge:\r\nIf you need to invite other people onto the SOC bridge please send them the following blurb in email or a meeting invite: \"Please join the [CUSTOMER] Security Operations Center on the following phone bridge: Toll Free: [1-866-555-5555], Participant Code: 123456789#\"\r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Phone Bridge Details"
            },
            "name": "Phone Bridge Details Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Vulnerability Scanning Schedule\r\n\r\n## Description\r\n\r\nThe [CUSTOMER] Enterprise undergoes frequent scheduled vulnerability scans and penetration testing. The SOC must be aware of the approved scans and their time frame to carry out the scanning/penetration testing. This page serves to provide dates on any approved scans and penetration tests. Additionally, the procedure to verify a suspected scan not listed on this page is also provided.\r\n\r\nIf a scan or penetration test has been detected and it is not listed on this page, use the Scan Verification Procedure to verify that the scan has been authorized. Any unlisted scans that cannot be verified by the Scan Identification Procedure must be treated as an incident with the appropriate Incident Triage Procedures.\r\n\r\n## Vulnerability Scan Scheduling\r\nListed below are scheduled vulnerability scans which have been identified as automatic scans:\r\n\r\n## [CUSTOMER] Scanner IP Addresses\r\n\r\n| SCANNERS |\r\n| : | : | : | : | : | : |  \r\n| Server Name | Operating System | Location | IP Addresses | Server Role | SAN |\r\n| VulSERV01\t| Server 2019 | East US\t|   | Console |\t500 GB |\r\n| VulSERV02\t| Server 2019 | West US\t|   | Console | 500 GB |\r\n\r\n## Port Scan Scheduling\r\n\r\nListed below is the Port Scanning guidebooks used by [CUSTOMER]:\r\n- [Qualys Scanner VLAN Scanning](https://www.qualys.com/docs/qualys-scanner-vlan-scanning.pdf)\r\n- [Qualys Consultant Scanner Personal Edition User Guide](https://www.qualys.com/docs/qualys-consultant-scanner-personal-edition-user-guide.pdf)\r\n- [Qualys Cloud Agent Getting Started Guide](https://www.qualys.com/docs/qualys-cloud-agent-getting-started-guide.pdf)\r\n- [Qualys Cloud Platform Evaluator’s Guide](https://www.qualys.com/docs/qualys-evaluators-guide.pdf)\r\n\r\n## Manual Scan Scheduling\r\n\r\nListed in the chart below are approved scheduled scans which have been reported to the SOC.\r\n\r\n| Manual Scan Schedule |\r\n| : | : | : | : | : |\r\n| Scan Title | Scan Range | Business Unit | Contact Person | Date/Time of Scan |\r\n|   |   |   |   |   |   |\r\n\r\n## Pen Testing Activity\r\n\r\nThe following scan schedules are defined per Web Inspect\r\n\r\n| Penetration Test Activity |\r\n| : | : | : | : | : | : |\r\n| Business Group | Type of Pen Test | Contact |\tSource & Destination Information | Pen Tester | Date/Time |\r\n|   |   |   |   |   |   |   |\r\n\r\n## External IP Addresses for [CUSTOMER]\r\n\r\nThese IP's are used by the [CUSTOMER]'s Pen Testers in order to exploit vulnerabilities throughout the [CUSTOMER] environment. There may be other Pen Tester IP's the SOC is not aware of.\r\n- List IP ranges here:\r\n\r\n## Process Owner\r\nSOC Manager\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Vulnerability Scanning Schedule"
            },
            "name": "Vulnerability Scanning Schedule Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# IP & Domain Blocklisting\r\n\r\n## Description\r\nThere are times when the SOC is notified of malicious IP addresses performing scans or exploit attempts. These pieces of information should be tracked within Azure Sentinel so we can automatically be notified if/when the [CUSTOMER] is being attacked by one of these addresses. There are other times when a particular domain name is considered especially malicious and the SOC wants to be notified when someone attempts to or successfully connects to one of these domains. To facilitate this we have created several Blacklists which can be modified by the analyst as new information comes available.\r\n\r\nWhen a malicious IP or domain is identified and added to a blacklist, a search for any previous connection attempts within the past 24 hours must be run in as a KQL query within Azure Sentinel.\r\n\r\nAzure Sentinel watchlists enable the collection of data from external data sources for correlation with the events in your Azure Sentinel environment. Once created, you can use watchlists in your search, detection rules, threat hunting, and response playbooks. Watchlists are stored in your Azure Sentinel workspace as name-value pairs and are cached for optimal query performance and low latency.\r\n\r\n<strong>Common scenarios for using watchlists include:</strong>\r\n- Investigating threats and responding to incidents quickly with the rapid import of IP addresses, file hashes, and other data from CSV files. Once imported, you can use watchlist name-value pairs for joins and filters in alert rules, threat hunting, workbooks, notebooks, and general queries.\r\n- Importing business data as a watchlist. For example, import user lists with privileged system access, or terminated employees, and then use the watchlist to create allow and deny lists used to detect or prevent those users from logging in to the network.\r\n\r\n## Insert Watchlist's within Azure Sentinel:\r\n\r\nFrom the Azure portal, navigate to Azure Sentinel > Configuration > Watchlist and then select Add new.\r\n\r\n![New Watchlist](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-new.png)\r\n\r\nOn the General page, provide the name, description, and alias for the watchlist, and then select Next.\r\n\r\n![General Watchlist](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-general.png)\r\n\r\nOn the Source page, select the dataset type, upload a file, and then select Next.\r\n\r\n![Source Watchlist](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-source.png)\r\n\r\n<strong>Note:</strong> File uploads are currently limited to files of up to 3.8 MB in size.\r\n\r\nReview the information, verify that it is correct, and then select Create.\r\n\r\n![Review Watchlist](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-review.png)\r\n\r\nA notification appears once the watchlist is created.\r\n\r\n![Complete Watchlist](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-complete.png)\r\n\r\n\r\n## Use watchlists in queries\r\nFrom the Azure portal, navigate to Azure Sentinel > Configuration > Watchlist, select the watchlist you want to use, and then select View in Log Analytics.\r\n\r\n![Query Watchlist](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-queries-list.png)\r\n\r\nThe items in your watchlist are automatically extracted for your query, and will appear on the Results tab. The example below shows the results of the extraction of the ServerName and IpAddress fields.\r\n\r\n<strong>Note:</strong> The timestamp on your queries will be ignored in both the query UI and in scheduled alerts.\r\n\r\n![Query Fields](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-queries-fields.png)\r\n\r\nYou can query data in any table against data from a watchlist by treating the watchlist as a table for joins and lookups.\r\n\r\n\tHeartbeat\r\n\t| lookup kind=leftouter _GetWatchlist('IPlist') on $left.ComputerIP == $right.IPAddress\r\n\r\n![Query Join](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-queries-join.png)\r\n\r\n## Use watchlists in analytics rules\r\nTo use watchlists in analytics rules, from the Azure portal, navigate to Azure Sentinel > Configuration > Analytics, and create a rule using the _GetWatchlist('<watchlist>') function in the query.\r\n\r\nIn this example, create a watchlist called “ipwatchlist” with the following values:\r\n\r\n![Create Watchlist]](https://docs.microsoft.com/azure/sentinel/media/watchlists/create-watchlist.png)\r\n\r\n![2 New Watchlist](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-new-2.png)\r\n\r\nNext, create the analytics rule. In this example, we only include events from IP addresses in the watchlist:\r\n\r\n\t//Watchlist as a variable\r\n\tlet watchlist = (_GetWatchlist('ipwatchlist') | project IPAddress);\r\n\tHeartbeat\r\n\t| where ComputerIP in (watchlist)\r\n\r\n\r\n\t//Watchlist inline with the query\r\n\tHeartbeat\r\n\t| where ComputerIP in ( \r\n    (_GetWatchlist('ipwatchlist')\r\n    | project IPAddress)\r\n\t)\r\n\r\n\r\n![Watchlist Rules](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-analytics-rule-2.png)\r\n\r\n## View list of watchlists aliases\r\nTo get a list of watchlist aliases, from the Azure portal, navigate to Azure Sentinel > General > Logs, and run the following query: _GetWatchlistAlias. You can see the list of aliases in the Results tab.\r\n\r\n![Watchlist Alias](https://docs.microsoft.com/azure/sentinel/media/watchlists/sentinel-watchlist-alias.png)\r\n\r\n\r\n## Watchlist's Added To Azure Sentinel\r\n\r\n| Watchlists |\r\n| : | : | : | : |\r\n| Date Added | Ticket # or Incident ID | Status\t| Ips/Domains Blocked |\r\n|   |   |   |   |   |\r\n\t\t\t\r\n## Process Owner\r\nSOC Manager\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "IP & Domain Blocklisting"
            },
            "name": "IP & Domain Blocklisting Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Daily Operations Process\r\n\r\n## Purpose \r\nThis process is intended to guide the daily operations for the [CUSTOMER] Security Operations Center (SOC). This process provides a significant number of critical subordinate operational procedures that document the standard daily tasks that support effective SOC operations. \r\n\r\n## Scope \r\nThis process applies to the [CUSTOMER] SOC and covers its main operational activities across all shifts and situations. \r\n\r\n## Process Summary \r\nAll SOC personnel are responsible to manage the daily tasks of Security Operations. This process is the primary daily guide that establishes the operational tempo and individual daily procedures for the smooth operation of the SOC. All of the operational activities that must be accomplished within a given 8-hour period are spelled out in this process or its subordinate procedures. This includes; staffing, monitoring, problem & change, shift turn-over and the daily operations meeting. These are all rigorous procedures that drive the daily work effort for all SOC Analysts during their scheduled shifts. \r\n\r\n## Shift Staffing and Scheduling Procedure \r\nThe <strong>Shift Staffing and Scheduling Procedures</strong> ensures appropriate staffing and establishes standard shift schedules. This procedure will document and establish the shift schedules that are required to provide 8x5 operational monitoring. This procedure will also provide process to cover planned and unplanned absences. \r\n\r\n## Problem & Change Procedure \r\nThe <strong>Problem Ticket & Change Controls Procedures</strong> documents how the non-emergent processes associated with SOC operations are handled. This procedure will leverage the standard Customer IT problem and change process. This procedure will document how to manage daily operational problems or changes in: \r\n- Monitored security devices \r\n- Low priority alerts \r\n- Any related Security Operations technology \r\n\r\n## Shift Turnover Procedure \r\nThe <strong>Shift Turnover Procedures</strong> provides a comprehensive and standard shift turn-over briefing to the replacement shift. The effective flow of operational and analytical information is critical to making informed security decisions. This procedure will ensure appropriate information exchange occurs during shift change. \r\n\r\n## Daily Ops Call Procedure \r\nThe <strong>Daily Operations Meeting Procedures</strong> will document all aspects of the daily operations call or meeting for the [CUSTOMER] security operations situational awareness. This is the daily operations call that informs a wider audience of important operational and analytical security information. \r\n\r\n## Metrics \r\n- Incidents per Analyst Hour - Overall KPIs \r\n- Incidents triaged by category by analyst - Personnel KPIs \r\n- Service Center Tickets - Overall KPIs \r\n\r\n## Roles & Responsibilities \r\n- SOC Manager owns the successful completion of all daily operational processes and procedures. The SOC manager is also responsible for ensuring these daily operational processes effectively support the SOC operations and for the continuous improvement of them. \r\n- SOC Operations Lead owns the successful completion of all procedures executed during his/her presence in the SOC. The SOC Operations lead owns the documentation and measurement of all subordinate procedures as well as the continual improvements to them. \r\n- SOC Analyst executes daily operational procedures as a matter of daily responsibility. The role of a SOC Analyst is the detailed and repeatable execution of all operational tasks as documented in this process and its subordinate procedures. \r\n\t\r\n## Process Owner \r\n SOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Daily Operations Process"
            },
            "name": "Daily Operations Process Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Daily Ops Meeting\r\n\r\n## Description \r\nThis is the daily operations call / meeting for the SOC, this call is intended to disseminate to a wider audience operational, analytical and infrastructure information pertaining to SOC operations. \r\n\r\nSteps \r\n- All parties join standard daily operations call conference bridge \r\n- Parties on call: \r\n\t- SOC Analysts & Senior SOC Analysts \r\n\t- IR Team representative \r\n\t- Others as needed \r\n- All parties to the call are logged in the shift-log \r\n- Cover Daily Ops Call Agenda \r\n- Optional \r\n\t- SOC Manager \r\n\t- SOC Leadership team \r\n\r\nAgenda \r\n- Operational \r\n\t- Callouts \r\n\t- Significant activity \r\n\t- Upcoming operational events \r\n- Analytical \r\n\t- Daily analysis (current significant Incidents/Alerts/events) \r\n\t- Emerging attacks or threats \r\n\t- General Internet trends \r\n- Open Discussion \r\n\t- Issues/concerns \r\n\t- Any other related items\r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Daily Ops Meeting"
            },
            "name": "Daily Ops Meeting Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Problem Tickets and Change Controls\r\n\r\n## Initiating a Trouble Ticket \r\nThere are 2 categories for trouble ticket creation. \r\n- [CUSTOMER] - Used when the issue will be resolved by [CUSTOMER]'s Teams \r\n- Azure Sentinel - Used when the issue needs to be resolved by Microsoft Customer Support \r\n\r\n<strong>Initiating a Change Control</strong> \r\n\t\r\n- Specify the customer's change control process here. (i.e. Remedy)\r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Problem Tickets and Change Controls"
            },
            "name": "Problem Tickets and Change Controls Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Shift Staffing Schedule\r\n\r\n## Description \r\nThe [CUSTOMER] Security Operations Center (SOC) is currently running a 9x5 operation to maintain adequate monitoring of potentially adverse information security events. In the future, [CUSTOMER] may elect to run 24x7x365 operations if the current coverage does not suffice. This procedure will define how both SOC shift schedules will be staffed. \r\n\r\n## Shift Scheduling \r\nTemporary Staffing Model \r\n\r\n\r\nThis staffing model is centered around the 8 hr. (extended) business working hours. This schedule is used under special circumstances such as training or holiday rotation. Each work week consists of four (4) SOC Analysts and four (4) Senior SOC Analysts \r\n- SOC Analysts will monitor for 2 or 4 hours at a time and alternate from actively monitoring the SOC Triage Tagged Incidents and performing other SOC Analyst duties. \r\n- Each analyst will be responsible for a total of 4 or 6 hours of active monitoring per day. \r\n- One analyst will be the Primary Analyst on console, and another analyst will be Secondary Analyst on console. \r\n- Analysts will rotate console duties throughout the duration of each shift. \r\n\t\r\n## Planned Absence  \r\n- When requesting vacation, submit your request via E-Mail to the SOC Operations Lead \r\n- A Senior SOC Analyst will cover for any planned vacations or other planned absences within their shift team if needed \r\n- Vacations will be coordinated as far in advance as possible to ensure for appropriate shift coverage \r\n\t- All vacations should be scheduled a minimum of 2 weeks in advance \r\n\r\n## Unplanned Absence \r\n1. Contact a SOC Analyst \r\n\t- Call or page Manager or Director (SOC Contacts)\r\n\t- Senior SOC Analyst to provide or arrange coverage \r\n2. Contact SOC Manager/Operations Lead\r\n\r\n## Process Owner\r\nSOC Manager\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Shift Staffing Schedule"
            },
            "name": "Shift Staffing Schedule Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Shift Turnover\r\n\r\n## Description \r\nThe Shift Turn-over procedure defines what needs to be done to allow for accurate and appropriate pass-on of shift information from one shift to the next. \r\n\r\n### Steps \r\nSee the Shift Logs for activity during outgoing shift. \r\n- Information to cover: \r\n\t1. All callouts and any new Incidents that may have been created \r\n\t2. Review open tickets assigned to the SOC \r\n\t3. Any new Alerts/events of interest that did not warrant a new Incident \r\n\t4. Significant operational activity and analytical information \r\n- Review all tracking pages: \r\n\t- Action Item Log \r\n\t- Filter Request Log \r\n- New shift should immediately complete: \r\n\t- Review Intelligence Reports \r\n\t- Review all e-mail from other SOC Analysts and SOC Management \r\n\t- Review nightly update e-mail \r\n\t\t\r\n<strong>Sign previous shift log</strong> to acknowledge that you have completed\r\n\r\n## Process Owner\r\nSOC Manager\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Shift Turnover"
            },
            "name": "Shift Turnover Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Weekly Operational Process\r\n\r\n## Description \r\nThis process is intended to guide the weekly operations for the [CUSTOMER] Security Operations Center (SOC). This process provides a significant number of critical subordinate operational procedures that document the standard weekly tasks that support effective SOC operations.\r\n\r\n## Scope\r\nThis process applies to the SOC and covers its main operational activities across all shifts and situations.\r\n\r\n## Process Summary\r\nThe Senior SOC Analyst and any additional appointed personnel are responsible to manage the weekly SOC tasks. All of the operational activities that must be accomplished within a given weekly time frame are spelled out in this process or its subordinate procedures. This includes; Weekly Intelligence Report, Weekend Event Analysis and Review, Weekly Threat Report, Weekly SLA Attainment, and Weekly Incident Statistics.\r\n\r\n## Weekly Threat Intelligence Report Procedure \r\nThe Weekly Threat Intelligence Report provides the SOC and its ancillary teams with weekly up-to-date situational awareness concerning items related to the company as well as items on a regional/global scale.\r\n\r\n## Process Owner \r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Weekly Operational Process"
            },
            "name": "Weekly Operational Process Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Weekly Threat Intelligence Report\r\n\r\n## Example\r\n\r\n# Sample Security Threat Intel Report \r\n[CUSTOMER] Confidential – Internal use only\r\n \r\n<strong>Statistics and Issues</strong>\r\n- Azure AD outage occurred on 03/15/2021 due to number of SQL reads.\r\n- 220 Azure Sentinel Incidents were opened and 74 Incidents were closed this week.\r\n- A large spike in port 3389/TCP traffic was observed on 04/12/2021.\r\n\r\n### Key Articles of Interest\r\n\r\n[<strong>In Wake of Resurgence, US-CERT Issues Alert About Dridex</strong>](http://www.darkreading.com/risk/in-wake-of-resurgence-us-cert-issues-alert-about-dridex/d/d-id/1322630?_mc=sm_dr&hootPostID=f21b912162f609c2d4991e32dcbc29cb)\r\n\r\nUS-CERT issued a technical alert about the Dridex banking Trojan today, about two weeks after the malware was found being used in a large phishing campaign heavily targeted at users in the United Kingdom. Palo Alto Networks reported they saw this campaign after witnessing a brief decrease in Dridex activity in September, following the arrest of a Moldovan man purported to be a key player in a cybercrime gang that used Dridex.\r\n\r\n[<strong>FBI, Security Vendors Partner for DRIDEX Takedown</strong>](http://blog.trendmicro.com/trendlabs-security-intelligence/us-law-enforcement-takedown-dridex-botnet/)\r\n\r\nMultiple command-and-control (C&C) servers used by the DRIDEX botnet have been taken down by the Federal Bureau of Investigation (FBI), following the action taken by the National Crime Agency (NCA) in the UK.\r\n\r\n[<strong>Samsung's mobile payments acquisition LoopPay breached by hackers</strong>](http://mashable.com/2015/10/07/samsung-looppay-hacked/#kS0vPpIf4iq6)\r\n\r\nA report on Wednesday revealed that LoopPay, the U.S.-created mobile payment system acquired by Samsung in February, was the target of a hacker attack in March. But the most interesting wrinkle in the story is the fact that the hackers who executed the attack on the South Korea-based company appear to be from China, thus framing the incident as a case of international, possibly corporate, espionage, rather than just another hack.\r\n \r\n[<strong>Microsoft Patch Tuesday for October 2015</strong>](https://www.trustwave.com/Resources/SpiderLabs-Blog/Microsoft-Patch-Tuesday-for-October-2015/)\r\n\r\nOctober's Patch Tuesday is upon us and with only six bulletins, it's one of lightest releases we've seen. The six bulletins are split down the center with three rated as Critical and three rated as Important. This release addresses a total of 30 CVEs half of which are patched in Internet Explorer. The other two Critical bulletins patch remote code execution vulnerabilities in the Microsoft VBScript and Jscript scripting engines as well as the Microsoft Windows Shell. The Windows Shell bulletin patches a use-after-free vulnerability that is triggered by having a victim open a maliciously crafted windows toolbar object. The remote code execution would occur in the user context of the victim's user account.\r\n\r\n[<strong>Android ransomware uses Google's own design principles against victims</strong>](http://www.fierceitsecurity.com/story/android-ransomware-uses-googles-own-design-principles-against-victims/2015-10-13?utm_medium=nl&utm_source=internal)\r\n\r\nThe Android.Lockdroid.E ransomware uses Google's design principles and an open-source project against users, warned Symantec security researcher Dinesh Venkatesan in a blog post.The malware developers used Google's Material Design language and open-source project MaterialDrawer to create a lockscreen with a more professional-looking user interface. The malware also uses Material Design to display personal data it gathers from device logs, making the fraudulent legal notice more convincing.\r\n\r\n\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Weekly Threat Intelligence Report"
            },
            "name": "Weekly Threat Intelligence Report Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Reporting Process\r\n\r\n## Purpose \r\nThe purpose of this process is to establish the standard reporting methodologies and to ensure that critical analytical security information is included, tracked, and effectively reported on. \r\n\r\n## Scope \r\nThis process applies to the Incidents/Alerts/events that are generated in Azure Sentinel, including all annotation tags and actions generated by the SOC in its monitoring and alerting function. \r\n\r\n## Process Summary \r\nBusiness requirements owners will define informational requirements. The Lead SIEM Engineer will design, update, and maintain all required reports (i.e. Workbooks) within Azure Sentinel. The SOC Analysts will provide analytical comments and summaries to SOC work products as needed. On a regular basis the SOC Team will use Azure Sentinel's Workbooks to produce reports and provide availability and access. These reports are central to answering business questions about personnel performance, security operations, threat statistics, vulnerability statistics and KQL query performance. \r\n\r\nThe <strong>Periodic Reports Procedures</strong> establishes the standard reports that will be run on a regular basis. These include daily, weekly, and monthly reports to produce actionable information relating to security operations, threat statistics, vulnerability statistics, and query performance. The complete documentation will be maintained in the Use Case procedure appendices. The lead engineer is responsible for all reporting. The periodic reporting procedure will document which reports will be run and how often. \r\n\r\n### Metrics \r\n- All reports document and present metrics \r\n\r\n### Roles & Responsibilities \r\n- <strong>SOC Manager</strong> owns the successful completion of all daily operational processes and procedures. The SOC manager is also responsible for ensuring these daily operational process effectively support SOC operations and for continually improving them. \r\n- <strong>SOC Analyst</strong> execute daily operations procedures as a matter of daily responsibility and owns the successful completion of all procedures executed during his/her presence in the SOC. SOC Analysts own the documentation and measurement of all subordinate procedures as well as the continual improvements to them.  The role of a SOC Analyst is the detailed and repeatable execution of all operational tasks as documented in this process and its subordinate procedures.  \r\n- <strong>Lead SOC Engineer</strong> is responsible for the successful completion of all reporting processes. This lead engineer is also responsible for developing the content to satisfy defined requirements which are documented in the Use Case procedures. \r\n\t\r\n### Applicable Policies & Standards \r\n- Link to Policies and Standards \r\n\r\n### Process Linkages \r\n- Subordinate Procedures \r\n\t- Periodic Reports \r\n- Related Process & Procedures \r\n\t- Incident Management Process \r\n\t- Metrics Process \r\n\r\n## Process Owner\r\n SOC Manager\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Reporting Process"
            },
            "name": "Reporting Process Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Periodic Reports\r\n\r\n## Purpose \r\nSenior SOC Analysts will be responsible for producing daily and weekly reports and monthly metrics as detailed in the SOC Roles & Responsibilities. Senior SOC Analysts own the following reports and processes. \r\n\r\n## SOC Weekly Threat Report \r\nThis page details the sources and processes to create the Weekly Threat Report. \r\n- SOC Weekly Threat Report Instructions \r\n- SOC Weekly Threat Report Archive \r\n\r\n## SOC Monthly Metrics \r\nThis page details how to collect and produce monthly performance metrics \r\n- Monthly Metrics \r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Periodic Reports"
            },
            "name": "Periodic Reports Text"
          }
        ]
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Operational Processes & Procedures"
      },
      "customWidth": "75",
      "name": "SOC Operational Processes & Procedures Group"
    },
    {
      "type": 12,
      "content": {
        "version": "NotebookGroup/1.0",
        "groupType": "editable",
        "items": [
          {
            "type": 1,
            "content": {
              "json": "# SOC Technology Processes & Procedures\r\n\r\n| Process Name | Procedures | Description/Comments |\r\n| : | : | : |\r\n| Design Process |  |  |\r\n|   | Architecture | Holds all architecture design documents for all services |\r\n|   | Data Retention | Describes the data retention requirements for all services |\r\n|   | Network Diagrams | Customer network diagrams for line of business applications |\r\n|   | Content Development Design | Procedure on how to develop content |\r\n|   | Azure Infrastructure Monitoring | Azure Standards that are in place to monitor for Threats and Failure |\r\n|   | Engineering Incident Management | Procedure for dealing with system problems |\r\n|   | User Access Control Design | Details regarding how ACL will be setup for all components and users |\r\n"
            },
            "customWidth": "75",
            "name": "SOC Technology Processes & Procedures Header"
          },
          {
            "type": 11,
            "content": {
              "version": "LinkItem/1.0",
              "style": "list",
              "links": [
                {
                  "id": "83785bef-fb93-4028-8996-49e1970fdf90",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Design Process",
                  "subTarget": "Design Process",
                  "style": "primary"
                },
                {
                  "id": "9af0a853-0cc6-4607-8bb4-6ad53ab17c9e",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Architecture",
                  "subTarget": "Architecture",
                  "style": "secondary"
                },
                {
                  "id": "d624d8ff-5bfe-491f-a3d5-8653d2fec08c",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Data Retention",
                  "subTarget": "Data Retention",
                  "style": "secondary"
                },
                {
                  "id": "d5010198-817e-4fba-a5fd-38ee7ec02e50",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Network Diagrams",
                  "subTarget": "Network Diagrams",
                  "style": "secondary"
                },
                {
                  "id": "885bba14-db69-4ef0-9971-9482423ed72c",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Content Development Design",
                  "subTarget": "Content Development Design",
                  "style": "secondary"
                },
                {
                  "id": "0d4c84d3-afd6-4bcf-912b-e14dc7dcb323",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Azure Infrastructure Monitoring",
                  "subTarget": "Azure Infrastructure Monitoring",
                  "style": "secondary"
                },
                {
                  "id": "995bd498-69c5-4e35-9ade-487087e2fa93",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "Engineering Incident Management",
                  "subTarget": "Engineering Incident Management",
                  "style": "secondary"
                },
                {
                  "id": "4d34fd94-088c-4ff4-aad6-c05788f0b4b9",
                  "cellValue": "Tab",
                  "linkTarget": "parameter",
                  "linkLabel": "User Access Control Design",
                  "subTarget": "User Access Control Design",
                  "style": "secondary"
                }
              ]
            },
            "customWidth": "25",
            "name": "SOC Technology Processes & Procedures Tabs",
            "styleSettings": {
              "margin": "20",
              "padding": "20"
            }
          },
          {
            "type": 1,
            "content": {
              "json": "# Design Process\r\n\r\n## Purpose \r\nThe purpose of this process is to document the methodology by which the initial conceptual design of the content that the SOC will use within Azure Sentinel and the procedures for on-going changes to design components. The process will include procedures for Use Cases and Analytics Modeling as well as many other content design procedures. \r\n\r\n## Scope \r\nThe scope of this process includes the initial configuration and the approach to update key parameters that impact the effectiveness and efficiency of Azure Sentinel. The scope of this process is strictly limited to the [CUSTOMER] SOC. The Modeling Procedure will document the parameters relative to networks, servers, endpoints, applications, and category levels. The use case procedure will address business and analytical requirements as well as objectives, any compliance requirements, and other technology problems to be solved.\r\n\r\n## Process Summary \r\nThe Lead Engineer will provision and maintain the appropriate conceptual design content in Azure Sentinel. This process consists of two main subordinate procedures and many secondary procedures which are all concerned with the content and design structure of Azure Sentinel. \r\n \r\nThe Use Cases procedure is the key component for meeting compliance business requirements. This procedure will document the requirements gathering process, the steps required to analyze and implement monitoring analytics within Azure Sentinel and all the associated documentation required by the business. These requirements will fit a number of general categories; Regulatory (PCI, SOX, HIPAA, PII, FFIEC, etc), General Security, Policy Compliance, System Administration, Metrics, and Network. \r\n\r\n## Metrics \r\n- Use cases defined, tracked & completed \r\n- Interactive Workbook statistics defined, tracked & completed \r\n\t- Workbook Reports defined, tracked, & completed \r\n\r\n## Roles & Responsibilities \r\n- SOC Manager is responsible for the overall success of this process. The SOC manager ensures the resources are available to support Azure Sentinel Analytic design and on-going modifications. \r\n- Lead Engineer is responsible for interfacing with local organizations to obtain essential modeling data to set parameters in Azure Sentinel; and to develop use cases to support business requirements/objectives with efficient implementation. \r\n- SOC Lead is responsible for providing SOC related requirements and objectives that will allow Azure Sentinel to effectively support the SOC. \r\n- SOC Analyst is responsible for providing feedback on modeling and use case design effectiveness. The SOC Analyst is responsible for the 24x7x365 monitoring of solutioned Use Case content. \r\n- Network Management is responsible for providing essential network topology and log data. \r\n- Information Systems Management is responsible for requirements verification, prioritization and escalation. \r\n\r\nMore information on specific roles and responsibilities is available in Roles & Responsibilities. \r\n\r\n## Process Owner \r\nSOC Manager \r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Design Process"
            },
            "name": "Design Process Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Architecture\r\n\r\n## Description\r\nHolds all architecture design documents for all services. Update this page with applicable Architecture Design Documents and Visio's.\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Architecture"
            },
            "name": "Architecture Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Data Retention Standard\r\n\r\n## Description \r\nThis will maintain all the data retention requirements for Azure Sentinel managed by the SOC. Please describe the retention requirement as well as any special business justification for each particular business unit and their associated data being stored within Azure Sentinel.\r\n\r\n## CUSTOMER OR BUSINESS UNIT NAME \r\nPer Regulatory Compliance Requirements, Production data, and other data identified as required for compliance, is stored for a period of 1 year. Data remains \"Hot\" within Azure Sentinel for a period of 90 days in the Log Analytics Workspace assigned to Azure Sentinel.\r\n\r\n## Governing Requirements for Data Retention \r\nBelow are the Standards that is governed by. \r\n- PCI DSS-40 \r\n- Sarbanes-Oxley \r\n\r\n## Data Retention\r\nThe following steps describe how to configure how long log data is kept by in your workspace. Data retention at the workspace level can be configured from 30 to 730 days (2 years) for all workspaces unless they are using the legacy Free pricing tier. Retention for individual data types can be set as low as 4 days. Learn more about pricing for longer data retention. To retain data longer than 730 days, consider using Log Analytics workspace data export @ https://docs.microsoft.com/azure/azure-monitor/logs/logs-data-export.\r\n\r\n## Workspace level default retention\r\n1. In the Azure portal, from your workspace, select Usage and estimated costs from the left pane.\r\n2. On the Usage and estimated costs page, click Data Retention from the top of the page.\r\n3. On the pane, move the slider to increase or decrease the number of days and then click OK. If you are on the free tier, you will not be able to modify the data retention period and you need to upgrade to the paid tier in order to control this setting.\r\n\r\n![Change Retention](https://docs.microsoft.com/azure/azure-monitor/logs/media/manage-cost-storage/manage-cost-change-retention-01.png)\r\n\r\nWhen the retention is lowered, there is a several day grace period before the data older than the new retention setting is removed. The Data Retention page allows retention settings of 30, 31, 60, 90, 120, 180, 270, 365, 550 and 730 days. If another setting is required, that can be configured using Azure Resource Manager using the retentionInDays parameter. When you set the data retention to 30 days, you can trigger an immediate purge of older data using the immediatePurgeDataOn30Days parameter (eliminating the several day grace period). \r\n\r\nNOTE: This may be useful for compliance-related scenarios where immediate data removal is imperative. This immediate purge functionality is only exposed via Azure Resource Manager.\r\n\r\nWorkspaces with 30 days retention may actually retain data for 31 days. If it is imperative that data be kept for only 30 days, use the Azure Resource Manager to set the retention to 30 days and with the immediatePurgeDataOn30Days parameter.\r\n\r\nNOTE: that the Log Analytics purge API does not affect retention billing and is intended to be used for very limited cases. To reduce your retention bill, the retention period must be reduced either for the workspace or for specific data types.\r\n\r\n## Retention by data type\r\nIt is also possible to specify different retention settings for individual data types from 4 to 730 days (except for workspaces in the legacy Free pricing tier) that override the workspace level default retention.\r\n\r\n## Additional Resources that may be helpful\r\nhttps://docs.microsoft.com/azure/azure-monitor/logs/manage-cost-storage#troubleshooting-why-usage-is-higher-than-expected\r\nhttps://docs.microsoft.com/azure/azure-monitor/logs/manage-cost-storage#understanding-nodes-sending-data\r\n\r\n## Process Owner \r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Data Retention"
            },
            "name": "Data Retention Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Network Diagrams\r\n\r\n## Description \r\nThis topic serves as the repository for all Network Diagrams obtained by the SOC. All new diagrams should be uploaded to this page under the appropriate category. Additionally, please update any diagrams that are out of date. \r\n\r\n## CUSTOMER OR BUSINESS UNIT DIAGRAMS\r\n\r\n"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Network Diagrams"
            },
            "name": "Network Diagrams Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Content Development Design\r\n\r\n## Create analytic rules to detect threats\r\nThe Analytic Rules you Create will search for specific events or sets of events across your environment, alert you when certain event thresholds or conditions are reached, generate incidents for your SOC to triage and investigate, and respond to threats with automated tracking and remediation processes.\r\n\r\n## Create an analytic rule with a scheduled query\r\n1. From the Azure Sentinel navigation menu, select Analytics.\r\n2. In the action bar at the top, select +Create and select Scheduled query rule. This opens the Analytics rule wizard.\r\n\r\n![Detect Threats](https://docs.microsoft.com/azure/sentinel/media/tutorial-detect-threats-custom/create-scheduled-query-full.png#lightbox)\r\n\r\n## Analytics rule wizard - General tab\r\n1. Provide a unique Name and a Description.\r\n2. In the Tactics field, you can choose from among categories of attacks by which to classify the rule. These are based on the tactics of the MITRE ATT&CK framework.\r\n3. Set the alert Severity as appropriate.\r\n4. When you create the rule, its Status is Enabled by default, which means it will run immediately after you finish creating it. If you don’t want it to run immediately, select Disabled, and the rule will be added to your Active rules tab and you can enable it from there when you need it.\r\n\r\n![General Tab](https://docs.microsoft.com/azure/sentinel/media/tutorial-detect-threats-custom/general-tab.png)\r\n\r\n## Define the rule query logic and configure settings\r\n- In the Set rule logic tab, you can either write a query directly in the Rule query field, or create the query in Log Analytics and then copy and paste it here.\r\n- Queries are written in Kusto Query Language (KQL). Learn more about KQL concepts and queries, and see this handy quick reference guide.\r\n- The example shown in this screenshot queries the SecurityEvent table to display a type of failed Windows logon events.\r\n\r\n![Set Rule Logic](https://docs.microsoft.com/azure/sentinel/media/tutorial-detect-threats-custom/set-rule-logic-tab-all-1-new.png#lightbox)\r\n\r\n- Here's another sample query, one that would alert you when an anomalous number of resources is created in Azure Activity.\r\n\tAzureActivity\r\n\t| where OperationName == \"Create or Update Virtual Machine\" or OperationName ==\"Create Deployment\"\r\n\t| where ActivityStatus == \"Succeeded\"\r\n\t| make-series dcount(ResourceId)  default=0 on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller\r\n\r\n### Rule query best practices\r\n- The query length should be between 1 and 10,000 characters and cannot contain \"search *\" or “union *”.\r\n- Using ADX functions to create Azure Data Explorer queries inside the Log Analytics query window is not supported.\r\n- When using the bag_unpack function in a query, if you project the columns as fields using \"project field1\" and the column doesn't exist, the query will fail. To guard against this happening, you must project the column as follows:\r\n\tproject field1 = column_ifexists(\"field1\",\"\")\r\n\r\n## Alert enrichment\r\n- Use the Entity mapping configuration section to map parameters from your query results to Azure Sentinel-recognized entities. Entities enrich the rules' output (alerts and incidents) with essential information that serves as the building blocks of any investigative processes and remedial actions that follow. They are also the criteria by which you can group alerts together into incidents in the Incident settings tab.\r\n\r\nLearn more about entities in [Azure Sentinel](https://docs.microsoft.com/azure/sentinel/entities-in-azure-sentinel).\r\n\r\n[See Map data fields to entities in Azure Sentinel](https://docs.microsoft.com/azure/sentinel/map-data-fields-to-entities) for complete entity mapping instructions, along with important information about backward compatibility.\r\n\r\n- Use the Custom details configuration section to extract event data items from your query and surface them in the alerts produced by this rule, giving you immediate event content visibility in your alerts and incidents.\r\n\r\nLearn more about surfacing custom details in alerts, and see the [complete instructions](https://docs.microsoft.com/azure/sentinel/surface-custom-details-in-alerts).\r\n\r\n## Query scheduling and alert threshold\r\n\r\n- In the Query scheduling section, set the following parameters:\r\n\r\n![Set Rule Logic](https://docs.microsoft.com/azure/sentinel/media/tutorial-detect-threats-custom/set-rule-logic-tab-all-2-new.png#lightbox)\r\n\r\n- Set Run query every to control how often the query is run - as frequently as every 5 minutes or as infrequently as once every 14 days.\r\n- Set Lookup data from the last to determine the time period of the data covered by the query - for example, it can query the past 10 minutes of data, or the past 6 hours of data. The maximum is 14 days.\r\n- Use the Alert threshold section to define the sensitivity level of the rule. For example, set Generate alert when number of query results to Is greater than and enter the number 1000 if you want the rule to generate an alert only if the query returns more than 1000 results each time it runs. This is a required field, so if you don’t want to set a threshold – that is, if you want your alert to register every event – enter 0 in the number field.\r\n\r\n## Results simulation\r\nIn the Results simulation area, in the right side of the wizard, select Test with current data and Azure Sentinel will show you a graph of the results (log events) the query would have generated over the last 50 times it would have run, according to the currently defined schedule. If you modify the query, select Test with current data again to update the graph. The graph shows the number of results over the defined time period, which is determined by the settings in the Query scheduling section.\r\n\r\nHere's what the results simulation might look like for the query in the screenshot above. The left side is the default view, and the right side is what you see when you hover over a point in time on the graph.\r\n\r\n![Results Simulation](https://docs.microsoft.com/azure/sentinel/media/tutorial-detect-threats-custom/results-simulation.png)\r\n\r\nIf you see that your query would trigger too many or too frequent alerts, you can experiment with the settings in the Query scheduling and Alert threshold sections and select Test with current data again.\r\n\r\n## Event grouping and rule suppression\r\n\r\n- Under Event grouping, choose one of two ways to handle the grouping of events into alerts:\r\n\t- Group all events into a single alert (the default setting). The rule generates a single alert every time it runs, as long as the query returns more results than the specified alert threshold above. The alert includes a summary of all the events returned in the results.\r\n\t- Trigger an alert for each event. The rule generates a unique alert for each event returned by the query. This is useful if you want events to be displayed individually, or if you want to group them by certain parameters - by user, hostname, or something else. You can define these parameters in the query.\r\n\t- Currently the number of alerts a rule can generate is capped at 20. If in a particular rule, Event grouping is set to Trigger an alert for each event, and the rule's query returns more than 20 events, each of the first 19 events will generate a unique alert, and the 20th alert will summarize the entire set of returned events. In other words, the 20th alert is what would have been generated under the Group all events into a single alert option.\r\n\r\n#### What's the difference between events and alerts?\r\n\tAn event is a description of a single occurrence of an action. For example, a single entry in a log file could count as an event. In this context an event refers to a single result returned by a query in an analytics rule.\r\n\tAn alert is a collection of events that, taken together, are significant from a security standpoint. An alert could contain a single event if the event had significant security implications - an administrative login from a foreign country outside of office hours, for example.\r\n\tBy the way, what are incidents? Azure Sentinel's internal logic creates incidents from alerts or groups of alerts. The incidents queue is the focal point of SOC analysts' work - triage, investigation and remediation.\r\n\tAzure Sentinel ingests raw events from some data sources, and already-processed alerts from others. It is important to note which one you're dealing with at any time.\r\n\r\n- In the Suppression section, you can turn the Stop running query after alert is generated setting On if, once you get an alert, you want to suspend the operation of this rule for a period of time exceeding the query interval. If you turn this on, you must set Stop running query for to the amount of time the query should stop running, up to 24 hours.\r\n\r\n## Configure the incident creation settings\r\nIn the Incident Settings tab, you can choose whether and how Azure Sentinel turns alerts into actionable incidents. If this tab is left alone, Azure Sentinel will create a single, separate incident from each and every alert. You can choose to have no incidents created, or to group several alerts into a single incident, by changing the settings in this tab.\r\n\r\n![Incident Settings](https://docs.microsoft.com/azure/sentinel/media/tutorial-detect-threats-custom/incident-settings-tab.png)\r\n\r\n## Incident settings\r\nIn the Incident settings section, Create incidents from alerts triggered by this analytics rule is set by default to Enabled, meaning that Azure Sentinel will create a single, separate incident from each and every alert triggered by the rule.\r\n\r\nIf you don’t want this rule to result in the creation of any incidents (for example, if this rule is just to collect information for subsequent analysis), set this to Disabled.\r\n\r\nIf you want a single incident to be created from a group of alerts, instead of one for every single alert, see the next section.\r\n\r\n## Alert grouping\r\nIn the Alert grouping section, if you want a single incident to be generated from a group of up to 150 similar or recurring alerts (see note), set Group related alerts, triggered by this analytics rule, into incidents to Enabled, and set the following parameters.\r\n\r\n- Limit the group to alerts created within the selected time frame: Determine the time frame within which the similar or recurring alerts will be grouped together. All of the corresponding alerts within this time frame will collectively generate an incident or a set of incidents (depending on the grouping settings below). Alerts outside this time frame will generate a separate incident or set of incidents.\r\n- Group alerts triggered by this analytics rule into a single incident by: Choose the basis on which alerts will be grouped together:\r\n\t- Group alerts into a single incident if all the entities match: Alerts are grouped together if they share identical values for each of the mapped entities (defined in the Set rule logic tab above). This is the recommended setting.\r\n\t- Group all alerts triggered by this rule into a single incident: All the alerts generated by this rule are grouped together even if they share no identical values.\r\n\t- Group alerts into a single incident if the selected entities match: Alerts are grouped together if they share identical values for some of the mapped entities (that you can select from the drop-down list). You might want to use this setting if, for example, you want to create separate incidents based on the source or target IP addresses.\r\n- Re-open closed matching incidents: If an incident has been resolved and closed, and later on another alert is generated that should belong to that incident, set this setting to Enabled if you want the closed incident re-opened, and leave as Disabled if you want the alert to create a new incident.\r\n\r\n## Set automated responses and create the rule\r\n1. In the Automated responses tab, select any playbooks you want to run automatically when an alert is generated by the custom rule. For more information on creating and automating playbooks, see [Respond to threats](https://docs.microsoft.com/azure/sentinel/tutorial-respond-threats-playbook).\r\n\r\n![Automated Response](https://docs.microsoft.com/azure/sentinel/media/tutorial-detect-threats-custom/automated-response-tab.png)\r\n\r\n2. Select Review and create to review all the settings for your new alert rule. When the \"Validation passed\" message appears, select Create to initialize your alert rule.\r\n\r\n![Review and Create](https://docs.microsoft.com/azure/sentinel/media/tutorial-detect-threats-custom/review-and-create-tab.png)\r\n\r\n## View the rule and its output\r\n- You can find your newly created custom rule (of type \"Scheduled\") in the table under the Active rules tab on the main Analytics screen. From this list you can enable, disable, or delete each rule.\r\n- To view the results of the alert rules you create, go to the Incidents page, where you can triage, investigate incidents, and remediate the threats.\r\n\r\n## Troubleshooting\r\nSee the following Link: https://docs.microsoft.com/azure/sentinel/tutorial-detect-threats-custom#troubleshooting\r\n\r\nNOTE: SOC managers should be sure to check the rule list regularly for the presence of auto-disabled rules.\r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Content Development Design"
            },
            "name": "Content Development Design Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Azure Infrastructure Monitoring\r\n\r\n## Configuration and change management\r\nAzure reviews and updates configuration settings and baseline configurations of hardware, software, and network devices annually. Changes are developed, tested, and approved prior to entering the production environment from a development and/or test environment.\r\n\r\nThe baseline configurations that are required for Azure-based services are reviewed by the Azure security and compliance team and by service teams. A service team review is part of the testing that occurs before the deployment of their production service.\r\n\r\n## Vulnerability management\r\nSecurity update management helps protect systems from known vulnerabilities. Azure uses integrated deployment systems to manage the distribution and installation of security updates for Microsoft software. Azure is also able to draw on the resources of the Microsoft Security Response Center (MSRC). The MSRC identifies, monitors, responds to, and resolves security incidents and cloud vulnerabilities around the clock, every day of the year.\r\n\r\n## Vulnerability scanning\r\nVulnerability scanning is performed on server operating systems, databases, and network devices. The vulnerability scans are performed on a quarterly basis at minimum. Azure contracts with independent assessors to perform penetration testing of the Azure boundary. Red-team exercises are also routinely performed and the results are used to make security improvements.\r\n\r\n## Protective monitoring\r\nAzure security has defined requirements for active monitoring. Service teams configure active monitoring tools in accordance with these requirements. Active monitoring tools include the Microsoft Monitoring Agent (MMA) and System Center Operations Manager. These tools are configured to provide time alerts to Azure security personnel in situations that require immediate action.\r\n\r\n## Incident management\r\nMicrosoft implements a security incident management process to facilitate a coordinated response to incidents, should one occur.\r\n\r\nIf Microsoft becomes aware of unauthorized access to [CUSTOMER]'s data that's stored on its equipment or in its facilities, or it becomes aware of unauthorized access to such equipment or facilities resulting in loss, disclosure, or alteration of customer data, Microsoft takes the following actions:\r\n\r\n- Promptly notifies the customer of the security incident.\r\n- Promptly investigates the security incident and provides customers detailed information about the security incident.\r\n- Takes reasonable and prompt steps to mitigate the effects and minimize any damage resulting from the security incident.\r\n\r\nAn incident management framework has been established that defines roles and allocates responsibilities. The Azure security incident management team is responsible for managing security incidents, including escalation, and ensuring the involvement of specialist teams when necessary. Azure operations managers are responsible for overseeing the investigation and resolution of security and privacy incidents.\r\n\r\n## Process Owner\r\nMicrosoft"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Azure Infrastructure Monitoring"
            },
            "name": "Azure Infrastructure Monitoring Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# Engineering Incident Management\r\n\r\n## Description \r\nThis page describes how to escalate system issues to the engineering team. It will also cover how the engineering team will manage their Incidents and workload.\r\n\r\n## Workflow \r\nAt a high level, the engineering incident management process works like this: \r\n1. An Incident is opened in Azure Sentinel and the SOC Analyst tags the Incident with SOC-Engineering to assign the Incident to the SOC Engineering team. \r\n2. The engineers review the Incidents, assign an owner and prioritize \r\n3. The owner works through the issues until resolution \r\n4. Incident is closed \r\n\r\n## Detailed Steps \r\n<strong>Opening an Incident</strong> \r\n1. Within the Azure Sentinel, navigate to the Incidents Blade and search for tagged Incidents with \"SOC-Engineering\". These should be Incidents that require a SOC Engineer to look into for refinement.\r\n2. In the Comments, provide as much description as possible \r\n3. Validate the specific events that show the problem through a KQL query and attach the events to the incident by using a Bookmark. \r\n4. Notify the SOC Engineering team via Teams, Email or some other method.\r\n\r\n<strong>Incident Review</strong> \r\n1. An Engineer will review each Incident to see if it is valid, if not the SOC Analyst who submitted the Incident to the SOC Engineering team will be notified with a detailed explanation. \r\n2. If the Incident is valid, an owner from the SOC Engineering team is assigned and the Incident is prioritized. \r\n\r\n<strong>Resolution</strong> \r\n1. The Incident owner is responsible for providing updates as they become available. At a minimum, the Incident should be updated weekly unless the SOC Engineer assigned updates the tag to Stage = 'On Hold'. \r\n\r\n<strong>Incident Closure</strong> \r\n1. When the problem is resolved, the Incident can be closed. This is done by assigning a tag - Stage = Closed and changes the Status of the Incident to Closed along with setting the Classification to one of the following depending on the Engineering Reason:\r\n\t- False Positive - incorrect alert logic\r\n\t- False Positive - incorrect data \r\n2. If required, this Workbook should be updated. ie: flows, connector tracking, installation instructions, etc... \r\n3. If appropriate, the SOC should be notified with any changes and instructions. \r\n\r\n## Process owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "Engineering Incident Management"
            },
            "name": "Engineering Incident Management Text"
          },
          {
            "type": 1,
            "content": {
              "json": "# User Access Control Design\r\n\r\n## Permissions in Azure Sentinel\r\n\r\nAzure Sentinel uses Azure role-based access control (Azure RBAC) to provide built-in roles that can be assigned to users, groups, and services in Azure.\r\n\r\nUse Azure RBAC to create and assign roles within your security operations team to grant appropriate access to Azure Sentinel. The different roles give you fine-grained control over what users of Azure Sentinel can see and do. Azure roles can be assigned in the Azure Sentinel workspace directly (see note below), or in a subscription or resource group that the workspace belongs to, which Azure Sentinel will inherit.\r\n\r\n## Roles for working in Azure Sentinel\r\n\r\n<strong>Azure Sentinel-specific roles</strong>\r\nAll Azure Sentinel built-in roles grant read access to the data in your Azure Sentinel workspace.\r\n- Azure Sentinel Reader can view data, incidents, workbooks, and other Azure Sentinel resources.\r\n- Azure Sentinel Responder can, in addition to the above, manage incidents (assign, dismiss, etc.)\r\n- Azure Sentinel Contributor can, in addition to the above, create and edit workbooks, analytics rules, and other Azure Sentinel resources.\r\n- Azure Sentinel Automation Contributor allows Azure Sentinel to add playbooks to automation rules. It is not meant for user accounts.\r\n\r\n\tNOTE:\r\n\tFor best results, these roles should be assigned on the resource group that contains the Azure Sentinel workspace. This way, the roles will apply to all the resources that are deployed to support Azure Sentinel, as those resources should also be placed in that same resource group.\r\n\tAnother option is to assign the roles directly on the Azure Sentinel workspace itself. If you do this, you must also assign the same roles on the SecurityInsights solution resource in that workspace. You may need to assign them on other resources as well, and you will need to be constantly managing role assignments on resources.\r\n\r\n## Additional roles and permissions to consider\r\nUsers with particular job requirements may need to be assigned additional roles or specific permissions in order to accomplish their tasks.\r\n\r\n- <strong>Working with playbooks to automate responses to threats</strong>\r\nAzure Sentinel uses playbooks for automated threat response. Playbooks are built on Azure Logic Apps, and are a separate Azure resource. You might want to assign to specific members of your security operations team the ability to use Logic Apps for Security Orchestration, Automation, and Response (SOAR) operations. You can use the Logic App Contributor role to assign explicit permission for using playbooks.\r\n- <strong>Connecting data sources to Azure Sentinel</strong>\r\nFor a user to add data connectors, you must assign the user write permissions on the Azure Sentinel workspace. Also, note the required additional permissions for each connector, as listed on the relevant connector page.\r\n- <strong>Guest users assigning incidents</strong>\r\nIf a guest user needs to be able to assign incidents, then in addition to the Azure Sentinel Responder role, the user will also need to be assigned the role of Directory Reader. Note that this role is not an Azure role but an Azure Active Directory role, and that regular (non-guest) users have this role assigned by default.\r\n- <strong>Creating and deleting workbooks</strong>\r\nFor a user to create and delete an Azure Sentinel workbook, the user will also need to be assigned with the Azure Monitor role of Monitoring Contributor. This role is not necessary for using workbooks, but only for creating and deleting.\r\n\r\n## Other roles you might see assigned\r\n\r\nIn assigning Azure Sentinel-specific Azure roles, you may come across other Azure and Log Analytics Azure roles that may have been assigned to users for other purposes. You should be aware that these roles grant a wider set of permissions that includes access to your Azure Sentinel workspace and other resources:\r\n\r\nAzure roles: Owner, Contributor, and Reader. Azure roles grant access across all your Azure resources, including Log Analytics workspaces and Azure Sentinel resources.\r\n\r\nLog Analytics roles: Log Analytics Contributor and Log Analytics Reader. Log Analytics roles grant access to your Log Analytics workspaces.\r\n\r\nFor example, a user who is assigned the Azure Sentinel Reader role, but not the Azure Sentinel Contributor role, will still be able to edit items in Azure Sentinel if assigned the Azure-level Contributor role. Therefore, if you want to grant permissions to a user only in Azure Sentinel, you should carefully remove this user’s prior permissions, making sure you do not break any needed access to another resource.\r\n\r\n## Azure Sentinel roles and allowed actions\r\n\r\nThe following table summarizes the Azure Sentinel roles and their allowed actions in Azure Sentinel.\r\n\r\n| Role | Create and run playbooks | Create and edit analytic rules and other Azure Sentinel resources *\t| Manage incidents (dismiss, assign, etc.) | View data, incidents, workbooks, and other Azure Sentinel resources |\r\n| : | : | : | : | : |\r\n| Azure Sentinel Reader | -- | -- | -- | ✓ |\r\n| Azure Sentinel Responder | -- | -- | ✓ | ✓ |\r\n| Azure Sentinel Contributor | -- | ✓ | ✓ | ✓ |\r\n| Azure Sentinel Contributor + Logic App Contributor | ✓ | ✓ | ✓ | ✓ |\r\n\r\n* Creating and deleting workbooks requires the additional Monitoring Contributor role. For more information, see Additional roles and permissions @ https://docs.microsoft.com/azure/sentinel/roles#additional-roles-and-permissions.\r\n\r\n## Custom roles and advanced Azure RBAC\r\n\r\nCustom roles. In addition to, or instead of, using Azure built-in roles, you can create Azure custom roles for Azure Sentinel. Azure custom roles for Azure Sentinel are created the same way you create other Azure custom roles, based on specific permissions to Azure Sentinel and to Azure Log Analytics resources.\r\n\r\nLog Analytics RBAC. You can use the Log Analytics advanced Azure role-based access control across the data in your Azure Sentinel workspace. This includes both data type-based Azure RBAC and resource-context Azure RBAC. For more information, see:\r\n\r\n- [Manage log data and workspaces in Azure Monitor](https://docs.microsoft.com/azure/azure-monitor/logs/manage-access#manage-access-using-workspace-permissions)\r\n- [Resource-context RBAC for Azure Sentinel](https://docs.microsoft.com/azure/sentinel/resource-context-rbac)\r\n- [Table-level RBAC](https://techcommunity.microsoft.com/t5/azure-sentinel/table-level-rbac-in-azure-sentinel/ba-p/965043)\r\n\r\nResource-context and table-level RBAC are two methods of providing access to specific data in your Azure Sentinel workspace without allowing access to the entire Azure Sentinel experience.\r\n\r\n## Process Owner\r\nSOC Manager"
            },
            "customWidth": "75",
            "conditionalVisibility": {
              "parameterName": "Tab",
              "comparison": "isEqualTo",
              "value": "User Access Control Design"
            },
            "name": "User Access Control Design Text"
          }
        ]
      },
      "conditionalVisibility": {
        "parameterName": "Tab",
        "comparison": "isEqualTo",
        "value": "SOC Technology Processes & Procedures"
      },
      "customWidth": "75",
      "name": "SOC Technology Processes & Procedures Group"
    }
  ],
  "fallbackResourceIds": [
    ""
  ],
  "fromTemplateId": "sentinel-SOCProcessFramework",
  "$schema": "https://github.com/Microsoft/Application-Insights-Workbooks/blob/master/schema/workbook.json"
}