Chapter 9. Integrating with partners

A SIEM usually aggregates data from multiple data sources, and these data sources are not necessarily part of a single vendor; in fact, these data sources are from different vendors and different solutions that are part of the organization’s IT ecosystem. For this reason, it is imperative for the SIEM solution to be flexible and enable you to ingest data from different vendors. In addition to the native data connectors available for Microsoft solutions in Azure Sentinel, there are also a set of built-in connectors for partner solutions.

In this chapter, you will learn more about integrating Azure Sentinel with Fortinet, Amazon AWS, and Palo Alto.

Connecting with Fortinet

Azure Sentinel has native integration with Fortinet and allows you to connect with Fortinet Fortigate appliances for data ingestion. Before starting the configuration, make sure to review the following prerequisites:

Once you meet those prerequisites, you can start the implementation. Follow these steps to connect Azure Sentinel with Fortinet:

  1. Deploy a virtual machine in the cloud or on-premises to host the Linux agent, using one of the supported operating systems. In these steps, we will use an Unbuntu 16.04 server image.

    Tip

    SYSLOG CEF messages are sent in clear text over UDP 514. Some systems support TCP 514 and even TLS. If you deploy a VM in the cloud with a public IP, ensure that you, at a minimum, use a Network Security Group (NSG) to limit source IP addresses that can send messages to the Linux CEF Collector.

  2. Open the Azure Portal and sign in as a user who has Azure Sentinel Contributor privileges.

  3. In the search pane, type Azure Sentinel and click the Azure Sentinel icon when it appears.

  4. Select the workspace on which Azure Sentinel is enabled.

  5. Click Data Connectors.

  6. Scroll down and select the Fortinet connector. Click Open Connector Page.

  7. Scroll down to step 1.2 and copy the text in the Run the following command to install and apply the CEF collector box. Figure 9-1 shows the data connector screen.

    This is a screenshot of the Fortinet Data connector blade. It shows a overview of the steps required to configure data collection.
    FIGURE 9-1 Azure Sentinel Fortinet connector page

  8. Log in to the Linux VM using your preferred terminal tool; for this example, we are using Putty.

  9. Paste the command to install the CEF collector, as shown in Figure 9-2.

    This is a screenshot of the putty window for the CEF collector. It shows the user logging in and pasting the command from the data connector page.
    FIGURE 9-2 Pasting the command to install the CEF collector

  10. Once the installation finishes, you should see an output similar to Figure 9-3.

    This is a screenshot of the Putty window for the CEF collector. It shows the output from the CEF collector install script.
    FIGURE 9-3 Post-installation output

  11. Now that the agent is installed on the CEF collector, you need to configure Foritgate.

  12. Log in to Fortigate using your preferred terminal tool.

  13. Type the following commands, and see the example shown in Figure 9-4.

    Click here to view code image

    config log syslogd setting
set status enable
set format cef
set port 514
set server <ip_address_of_Receiver>
end
    This is a screenshot of the Putty window for the Fortinet Firewall collector. It shows the user logging in and typing the commands required for configuring CEF.
    FIGURE 9-4 CEF configuration

  14. Fortigate is now configured to send data to the CEF collector.

Validating connectivity

Now that you have configured your connector, the next step is to validate the connectivity and make sure that the flow between your device and Azure Sentinel is working properly. Follow the steps below to validate this configuration:

  1. Open the Azure Portal and sign in as a user who has Azure Sentinel Contributor privileges.

  2. In the search pane, type Azure Sentinel and click the Azure Sentinel icon it when it appears.

  3. Select the workspace on which Azure Sentinel is enabled.

  4. Click Data Connectors.

  5. Scroll down and select the Fortinet connector. In Figure 9-5, you can see several indicators that data is connected.

    • You can see the Fortinet connector in the list has a green status bar to its left.

    • You can see the Status is listed as CONNECTED.

    • You can see when the last log was received.

    • Lastly, you can see a histogram of data and a total number of data received in the status blade.

    This is a screenshot of the Data Connectors blade. It shows the Fortinet connector is now green and has a graphic showing data received in the last few days. There has been an increase of data that is a result of being connected.
    FIGURE 9-5 Azure Sentinel Data connector page

  6. Click Logs in the left blade under General.

  7. Enter CommonSecurityLog | where DeviceProduct == “Fortigate” in the query window and select Run. Figure 9-6 shows the results, and you can see the data has been ingested.

    This is a screenshot of the Logs blade. It shows the CommonSecurityLog | where DeviceProduct == “Fortigate” query. The results pane shows the returned logs.
    FIGURE 9-6 Querying data generated by the connector

  8. If data is not showing up in the data connector or query, you can run a troubleshooting script.

  9. Click Data Connectors.

  10. Scroll down and select the Fortinet connector. Click Open Connector Page.

  11. Scroll down to step 1.2 and copy the text in the Run the following command to validate your connectivity box. Figure 9-7 shows the data connector screen.

    This is a screenshot of the Fortinet connector blade. It shows the instructions in the validation section, which explain how to run the command to validate connectivity.
    FIGURE 9-7 Command to validate the connectivity

  12. Log in to the Linux VM.

  13. Paste the command to run the troubleshooting script, as shown in Figure 9-8.

    This is a screenshot of the Putty window for the CEF collector. It shows the user logging in and pasting the command from the Data Connector page to run the validation script.
    FIGURE 9-8 Validating the connectivity

  14. Note, this machine was not configured for CEF collection. Figure 9-9 shows some errors in the validation script because of misconfigurations.

This is a screenshot of the Putty window for the CEF collector. It shows output from the validation script.
FIGURE 9-9 Errors on a machine without CEF collector

Connecting with Amazon Web Services (AWS)

Azure Sentinel has a connector dedicated to AWS; this connector enables you to ingest all AWS CloudTrail events into Azure Sentinel. The AWS CloudTrail enables ongoing delivery of events as log files to an Amazon S3 bucket that you specify during the creation of the cloud trail. If you have a CloudTrail already configured, you should see the trail name and settings in the AWS portal, as shown in Figure 9-10.

This is a screenshot of the AWS CloudTrail page showing that there is already one trail created in this account.
FIGURE 9-10 AWS Cloud Trail

The AWS data connector works by establishing a trust relationship between AWS CloudTrail and Azure Sentinel. For this trust to happen, you will need to create a role in AWS that gives permission to Azure Sentinel to access the AWS logs. You will also need the following information:

  • Workspace ID that is used by Azure Sentinel. This information is available in the AWS connector page in Azure Sentinel.

  • Microsoft Account ID, which is available on the AWS Connector. This information will be required during the configuration of the AWS Role.

Follow these steps to configure this role in AWS:

  1. Log in to your AWS Portal using an account that has privileges to create new roles.

  2. In the main dashboard, click Services.

  3. Under the Security, Identity & Compliance option, click IAM, as shown in Figure 9-11.

    This is a screenshot of the Services menu in the AWS dashboard; from here, you select the IAM option, which is located under Security, Identity & Compliance.
    FIGURE 9-11 Accessing the identity and access management to create a role

  4. In the left navigation pane, click Roles and click the Create role button, as shown in Figure 9-12.

    This is a screenshot of the Roles page in AWS, where you will create a new role that will be used by Azure Sentinel.
    FIGURE 9-12 Creating a new role in AWS

  5. In the Create role page, click Another AWS account, as shown in Figure 9-13.

    This is a screenshot of the Create Role page in AWS, showing the selection of Another AWS Account, where you will need to type the Microsoft Account ID provided in the Azure Sentinel AWS Connector page.
    FIGURE 9-13 Creating a role in AWS that is based on another AWS account

  6. Notice that the Account ID is the first information it requests. This Account ID is available in your Azure Sentinel AWS Connector. Leave this page open, go to Azure Sentinel, click Data Connectors, open the Amazon Web Services connector, and take note of the Microsoft Account ID under the Configuration section, as shown in Figure 9-14.

    This is a screenshot of the Configuration section of the AWS Connector page in Azure Sentinel. The Microsoft Account ID and External ID (Workspace ID) fields have been obscured for security purposes.
    FIGURE 9-14 AWS Connector in Azure Sentinel

  7. Copy the Microsoft Account ID, and while you are there, also make a record of the External ID (Workspace ID) number.

  8. Go back to the AWS page in step 5 and paste the Microsoft Account ID in the Account ID field.

  9. Select the option Require External ID (Best Practice When A Third Party Will Assume This Role) and paste the External ID (Workspace ID) that you copied in step 7. Click the Next: Permissions button to proceed.

  10. Under Attach permissions policies, select AWSCloudTrailReadOnlyAccess, as shown in Figure 9-15.

    This is a screenshot of the permission role assignment policy in AWS.
    FIGURE 9-15 Selecting the role for this account

  11. Click the Next: Tags button and click the Next: Review button; the final Review page appears, as shown in Figure 9-16.

    This is a screenshot of the Review page in AWS, where you can add a name for the role that you are creating.
    FIGURE 9-16 Final Review page

  12. For the Role Name, type AzureSentinelBook and click the Create Role button. At this point, you should see a confirmation page similar to the one shown in Figure 9-17.

    This is a screenshot of the confirmation page showing that the AzureSentinelBook role was created.
    FIGURE 9-17 Confirmation of the role creation in AWS

  13. In the Role Name table, click the role you created—AzureSentinelBook—and the summary of the role appears, as shown in Figure 9-18.

    This is a screenshot of the summary page for the role you created. This page shows the Role ARN (Amazon Resource Name), which will be used by Azure Sentinel.
    FIGURE 9-18 Properties of the role you created

  14. Copy the Role ARN.

  15. Open Azure Sentinel, click Data Connectors, and click Amazon Web Services.

  16. Under Configuration, paste the Role ARN in the Role to add field, and click the Add button, as shown in Figure 9-19.

    This is a screenshot of the Role To Add option for the Amazon Web Services connector in Azure Sentinel.
    FIGURE 9-19 Adding the Amazon Resource Name

  17. Once you add, you should see the ROLE ARN included in the table; the date for the last received event will be populated once it starts to sync. Also, your AWS connector should turn green to reflect that the connector is configured, as shown in Figure 9-20.

    This is a screenshot of the Amazon Web Services connector status, showing that it is connected.
    FIGURE 9-20 AWS connector page showing the status of the connection

Validating connectivity

Now that you configured your connector, the next step is to validate the connectivity and make sure that the flow between AWS CloudTrail and Azure Sentinel is working properly. You might notice that the main Azure Sentinel dashboard automatically creates an entry for AWS CloudTrial once it starts to receive data via the connector, as shown in Figure 9-21.

This is a screenshot of the Azure Sentinel dashboard, showing the entry for AWS Cloud Trail.
FIGURE 9-21 AWS Cloud Trail entry in the main Azure Sentinel dashboard

You can access the data that was sent from AWS CloudTrail to Azure Sentinel by simply clicking the AWSCLOUDTRAIL option shown in Figure 9-21. When you do this, Azure Sentinel will open the Log Analytics workspace, with the AWSCloudTrail query, as shown in Figure 9-22.

This is a screenshot of the Log Analytics page, showing the results for the AWS Cloud Trail query.
FIGURE 9-22 Log Analytics query for AWS Cloud Trail

This test is validating the data flow from your AWS Cloud Trail to Azure Sentinel.

Connecting with Palo Alto

Azure Sentinel comes with a pre-built connector for Palo Alto Networks firewalls. The connector works for both on-premises firewalls and those hosted in the cloud. At a high level, you will need to complete two primary steps to make the connection work. The first step is to set-up a Syslog collector. To do this, you will run a Microsoft-provided script that installs the Log Analytics agent and configures it to listen for Syslog messages on port 514 and sends the CEF messages to your Azure Sentinel workspace. The second step is to configure the Palo Alto Networks firewall to forward the CEF-formatted Syslog messages to the proxy machine. To use TLS communication between the firewall and the proxy machine, you will need to configure the Syslog daemon (rsyslog or syslog-ng) to communicate in TLS.

Figure 9-23 shows the high-level architecture for connecting an on-premises Palo Alto Networks firewall to Azure Sentinel.

This diagram shows the architecture of the technology components needed to forward logs from a Palo Alto Networks firewall hosted within a customer’s data center to Azure Sentinel.
FIGURE 9-23 The architecture of the connectivity of an on-premise Palo Alto Networks firewall to Azure Sentinel via a syslog proxy machine hosted in Azure

Figure 9-24 shows the architecture for connecting a Palo Alto Networks firewall hosted in Azure to Azure Sentinel.

This is a diagram showing the architecture of the technology components needed to forward logs from a Palo Alto Networks firewall appliance hosted within Azure to Azure Sentinel for monitoring.
FIGURE 9-24 The architecture for the connectivity of an Azure-hosted Palo Alto Networks firewall appliance to Azure Sentinel via a syslog proxy machine hosted in Azure

To connect a Palo Alto Networks firewall, you will need to make sure the following pre-requisites are met:

  • Access to an Azure Sentinel account with read and write permissions to the supporting workspace

  • Administrative access to a Linux machine from one of the options below:

    • 64-bit operating systems

      • CentOS 6 and 7

      • Amazon Linux 2019.09

      • Oracle Linux 6 and 7

      • Debian GNU/Linux 8 and 9

      • Ubuntu Linux 14.04 LTS, 16.04 LTS and 18.04 LTS

      • SUSE Linux Enterprise Server 12

    • 32-bit operating systems

      • CentOS 6

      • Oracle Linux 6

      • Red Hat Enterprise Linux Server 6

      • Debian GNU/Linux 8 and 9

      • Ubuntu Linux 14.04 LTS and 16.04 LTS

The Linux machine chosen must also include one of the following syslog daemon versions:

  • Syslog-ng: 2.1-3.22.1

  • Rsyslog: v8

  • Syslog RFCs supported

  • Syslog RFC 3164

  • Syslog RFC 5424

Once you meet the prerequisites above, you can start the implementation. For the following steps, we will be connecting a Palo Alto Networks firewall hosted in Azure with Azure Sentinel; reference the architecture shown in Figure 9-24. Complete the following steps:

  1. Deploy a Virtual Machine in Azure as your syslog collector. The virtual machine will host the Log Analytics agent. In the following steps, we will also use an Unbuntu 16.04 server image for our proxy machine.

    Tip

    SYSLOG CEF messages are sent in clear text over UDP 514. Some systems support TCP 514, and TLS and should be leveraged for a more secure and reliable connection. If you deploy a VM in the cloud with a public IP, make sure you a use a Network Security Group (NSG) to limit the source IP addresses that can send to the Linux CEF Collector.

  2. Open the Azure Portal and sign in as a user who has Azure Sentinel Contributor privileges.

  3. In the search pane, type Azure Sentinel and click on the Azure Sentinel logo when it appears.

  4. Select the workspace on which Azure Sentinel has been enabled.

  5. Click Data Connectors.

  6. Scroll down and select the Palo Alto Networks connector. Click Open Connector Page.

  7. Scroll down to step 1.2 and copy the text in the Run the following command to install and apply the CEF collector box. Microsoft also provides a button next to the script that when clicked will automatically copy the script to your clipboard. Figure 9-25 shows step 1.2 for the Palo Alto Networks connector:

    This is a screenshot of the Azure Sentinel Palo Alto Networks firewall data connector page, showing the script needed to install the Log Analytics agent on the proxy machine.
    FIGURE 9-25 A step from the Azure Sentinel Palo Alto Networks firewall data connector page

  8. Log in to the Linux VM using your preferred terminal tool.

  9. Paste the command to install the Log Analytics agent that you previously copied to your clipboard. Ensure you are running the script with administrator privileges.

  10. Now that the agent is installed on the proxy machine, you need to configure the Palo Alto Networks firewall to forward the logs to the proxy machine in CEF format. You can do that by following Step 2 on the Azure Sentinel documentation page for the connector at https://docs.microsoft.com/en-us/azure/sentinel/connect-paloalto.

  11. Log in to the Palo Alto Networks firewall and complete all of the instructions found at https://docs.paloaltonetworks.com/resources/cef.

  12. Next, go to https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring and complete steps 2 and 3. Be sure to set the Syslog server format to BSD, which is the default setting.

Validating connectivity

One of the easiest ways to validate the connectivity of your Palo Alto Networks firewall is via the Data connectors blade. Select the Palo Alto Networks data connector and you will get a detailed tile that includes the status of the connection, provider, and date of the last logs received. The tile also includes a time series chart showing data ingestion volumes by date. In the Figure 9-26 below, you can see that the status is listed as Connected and that the last log was received eight days ago.

This is a screenshot of the Azure Sentinel Palo Alto Networks firewall data connector page, showing that the firewall was successfully connected.
FIGURE 9-26 Azure Sentinel Palo Alto Networks data connector tile showing that the firewall is connected

You can also validate the connection by navigating to query page and running the following KQL query:

Click here to view code image

CommonSecurityLog
| where DeviceVendor == “Palo Alto Networks”
| where DeviceProduct == “PAN-OS”
| take 10

This query will return 10 log records from the Palo Alto Networks firewall. My results are shown in Figure 9-27. Note that it can take up to 20 minutes for logs to appear in Azure Sentinel after the Palo Alto Networks firewall is first connected.

This is a screenshot of the Azure Sentinel query blade showing recent Palo Alto Networks firewall logs to further validate connectivity.
FIGURE 9-27 Azure Sentinel KQL query and results for Palo Alto Networks firewall logs
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.105.190