To understand your security architecture requirements, you must first ensure that you have a solid understanding of the IT environment that you are trying to protect. Before deploying any new security solutions, there is a need to map out the solutions that are currently deployed and how they protect each area of the IT environment. The following list provides the major components of any modern IT environment:

• Identity for authentication and authorization of access to systems.
• Networks to gain access to internal resources and the internet.
• Storage and compute in the data center for internal applications and sensitive information.
• End user devices and the applications they use to interact with the data.
• And in some environments, you can include Industrial Control Systems (ICS) and the Internet of Things (IoT).

When we start to look at the threats and vulnerabilities for these components, we quickly find ourselves deep...

To assist with the discovery and mapping of current security solutions, we developed the cloud security reference framework. The following diagram is a section of this framework that provides the technical mapping components, and you can use this to carry out a mapping of your own environment:

Figure 1.2 – Technical mapping components; the cloud security reference framework

Each of these 12 components are described in the following list, along with some examples of the type of solutions to consider as regards integration with Azure Sentinel and the rest of your security architecture:

1. Security Operations Center: At a high level, this includes the following technologies and procedures: log management and Security Incident and Event Monitoring (SIEM), Security Orchestration and Automated Response (SOAR), vulnerability management, threat intelligence, incident response, and intrusion prevention/detection. This...

As described earlier, the SOC platform includes a range of technologies to assist with the routine and reactive procedures carried out by various teams. Each of these solutions should help the SOC analysts to perform their duties at the most efficient level to ensure a high degree of protection, detection, and remediation.

The core components of the SOC include log management and Security Incident and Event Monitoring (SIEM), Security Orchestration and Automated Response (SOAR), vulnerability management, threat intelligence, and incident response. All of these components are addressed by the deployment of Azure Sentinel. Additional solutions will be required, and integrated, for other SOC platform capabilities such as intrusion prevention/detection, integrity monitoring, and disaster recovery:

Deploying an SOC using Azure Sentinel comprises the following components:

• Azure Monitor for data collection and analysis. This was originally created to...

To implement a cohesive technical solution for your SOC platform, you need to ensure that the following components are reviewed and thoroughly implemented. This is best done on a routine basis and backed up by regularly testing the strength of each capability using penetration testing experts that will provide feedback and guidance to help improve any weaknesses.

Log management and data sources

The first component of an SOC platform is the gathering and storing of log data from a diverse range of systems and services across your IT environment. This is where you need to have careful planning to ensure that you are collecting and retaining the most appropriate data. Some key considerations we can borrow from other big data guidance are listed here:

• Variety: You need to ensure you have data feeds from multiple sources so as to gain visibility across the spectrum of hardware and software solutions across your organization.
• Volume: Too large...

Azure Sentinel is designed to work with multiple security solutions, not just those that are developed by Microsoft.

At the most basic level, log collection and analysis are possible from any system that can transmit their logs via the Syslog collectors. More detailed logs are available from those that connect via the CEF standard and servers that share Window Event logs. The preferred method, however, is to have direct integration via APIs to enable a two-way communication and help to manage the integrated solutions. More details relating to these options are included in Chapter 3, Data Collection and Management.

Common Event Format (CEF)

CEF is an industry standard format applied to Syslog messages, used by most security vendors to ensure commonality between platforms. Azure Sentinel provides integrations to easily run analytics and queries across CEF data. For a full list of Azure Sentinel CEF source configurations, review the following article...

One of the key reasons you might be planning to deploy Azure Sentinel is to manage the security for your cloud platform deployments. Instead of sending logs from the cloud provider to an on-premises SIEM solution, you will likely want to keep that data off your local network, so as to save on bandwidth usage and storage costs.

Let's now take a look at how some of these platforms can be integrated with Azure Sentinel.

Integrating with AWS

AWS provides API access to most features across the platform, which enables Azure Sentinel to be a rich integration solution. The following list provides some of the common resources that should be integrated with Azure Sentinel if enabled in the AWS account(s):

• AWS Cloud Trail logs provide insights into AWS user activities, including failed sign-in attempts, IP addresses, regions, user agents, and identity types, as well as potential malicious user activities with assumed roles.
• AWS Cloud Trail...

The primary method of integration with your private infrastructure (such as an on-premises data center) is the deployment of Syslog servers as data collectors. While endpoints can be configured to send their data to Azure Sentinel directly, you will likely want to centralize the management of this data flow. The key consideration for this deployment is the management of log data volume; if you are generating a large volume of data for security analytics, you will need to transmit that data over your internet connections (or private connections such as Express Route).

The data collectors can be configured to reduce the load by filtering the data, but a balance must be found between the volume and velocity of data collected in order to have sufficient available bandwidth to send the data to Azure Sentinel. Investment in increased bandwidth should be considered to ensure adequate capacity based on your specific needs.

A second method of integration...

There are several components to consider when pricing Azure Sentinel:

• A charge for ingesting data into Log Analytics
• A charge for running the data through Azure Sentinel
• Charges for running Logic Apps for Automation (optional)
• Charges for running your own machine learning models (optional)
• The cost of running any VMs for data collectors (optional)

The cost for Azure Monitor and Azure Sentinel is calculated by how much data is consumed, which is directly impacted by the connectors: which type of information you connect to and the volume of data each node generates. This may vary each day throughout the month as changes in activity occur across your infrastructure and cloud services. Some customers notice a change based on their customer sales fluctuations.

The initial pricing option is to use Pay As You Go (PAYG). With this option, you pay a fixed price per gigabyte (GB) used, charged on a per-day basis. Microsoft...

For the final section of this chapter, we are going to look at an important part of SOC development: scenario mapping. This process is carried out on a regular basis to ensure that tools and procedures are tuned for effective analysis and have the right data flow and that responses are well defined to ensure appropriate actions are taken upon detection of potential and actual threats. To make this an effective exercise, we recommend involving a range of different people with diverse skill sets and viewpoints, both technical and non-technical. You can also involve external consultants with specific skills and experience in threat hunting, defense, and attack techniques.

The following process is provided as a starting point. We encourage you to define your own approach to scenario mapping and improve it each time the exercise is carried out.

Step 1 – Define the new scenarios

In this first step, we articulate one scenario at a time; you may want to use...

In this chapter, we introduced Azure Sentinel and how it fits into the cloud security landscape. We explored some of the widely used acronyms for both problems and solutions and then provided a useful method of mapping these technical controls to the wide array of options available from many security platform providers today. We also looked at the future state of SOC architecture to ensure you can gain visibility and control across your entire infrastructure: physical, virtual, and cloud-hosted.

Finally, we looked at the potential cost of running Azure Sentinel as a core component of your security architecture and how to carry out the scenario-mapping exercise to ensure you are constantly reviewing the detections, the usefulness of the data, and your ability to detect and respond to current threats.

In the next chapter, we will take the first steps toward deploying Azure Sentinel by configuring an Azure Monitor workspace. Azure Monitor is the bedrock of Azure Sentinel...

1. What is the purpose of the cybersecurity reference framework?
2. What are the three main components when deploying an SOC based on Azure Sentinel?
3. What are some of the main operation platforms that integrate with a SIEM?
4. Can you name five of the third-party (non-Microsoft) solutions that can be connected to Azure Sentinel?
5. How many steps are involved in the scenario-mapping exercise?

You can refer to the following URLs for more information on topics covered in this chapter:

• Lessons learned from the Microsoft SOC – Part 1: Organization, at https://www.microsoft.com/security/blog/2019/02/21/lessons-learned-from-the-microsoft-soc-part-1-organization/.
• Lessons learned from the Microsoft SOC – Part 2a: Organizing People, at https://www.microsoft.com/security/blog/2019/04/23/lessons-learned-microsoft-soc-part-2-organizing-people/.
• Lessons learned from the Microsoft SOC – Part 2b: Career paths and readiness, at https://www.microsoft.com/security/blog/2019/06/06/lessons-learned-from-the-microsoft-soc-part-2b-career-paths-and-readiness/.
• The Microsoft Security Blog, at https://www.microsoft.com/security/blog.