Bring Threat Intelligence from IntSights Using TAXII Data Connector

by Contributed | Jan 20, 2021 | Technology

This article is contributed. See the original author and article here.

Azure Sentinel provides multiple ways to import threat intelligence into the product. The threat intelligence imported into Azure Sentinel makes it to the ThreatIntelligenceIndicator log analytics table and is also made available on the Threat Intelligence Blade. The imported threat intelligence can then be used in various parts of the product like hunting, investigation, analytics, workbooks, etc.

One of the ways to bring threat intelligence into Azure Sentinel is using the Threat Intelligence – TAXII Data connectors. This data connector uses the TAXII protocol for sharing data in STIX format and enables a built-in TAXII client in Azure Sentinel to import threat intelligence from TAXII 2.x servers.

Today we are announcing the availability of the IntSights TAXII Server, which allows you to get threat data from IntSights into Azure Sentinel using the Threat Intelligence – TAXII Data connector.

IntSights + Microsoft Azure Sentinel Solution

The IntSights and Azure Sentinel integration allows customers to gain visibility on indicators of compromise that directly target their unique digital footprints based on monitoring of thousands of sources across the clear, deep, and dark web to identify threats. With the IntSights intelligence feed, users can proactively block threats before they impact their environments and get instant visibility on those threats within Azure Sentinel.

In addition, users can leverage this integration to get enriched IOCs with additional context about the IOC like threat actor, malware, and campaign information. Users can further pivot to the IntSights Investigation module to gain additional visibility and context to protect their organizations.

Microsoft Azure Sentinel benefits with IntSights feed

The Azure Sentinel and IntSights integration enables analysts in the Security Operation Center (SOC) to gain visibility into thousands of indicators of compromise with contextual information. This integration also provisions dashboards in the form of Azure Sentinel workbooks detailing event data associated with the IOCs found in your environment.

This blog will walk you through the process of connecting the IntSights TAXII Server to Azure Sentinel.

Connecting Azure Sentinel to the IntSights TAXII Server:

To connect Azure Sentinel to the IntSights TAXII Server, obtain the API Root, Collection ID, Username and Password from the IntSights portal after you configure a policy of the data you wish to send to Azure Sentinel.

Enable the Threat Intelligence – TAXII data connector in Azure Sentinel

To import threat intelligence indicators into Azure Sentinel from the IntSights TAXII Server, follow these steps:

1. Open the Azure Portal and navigate to the Azure Sentinel service.


2. Choose the workspace where you want to import threat intelligence indicators from the IntSights TAXII Server.


3. Select Data Connectors from the Configuration menu.


4. Select Threat Intelligence – TAXII from the list of the data connectors and click the Open Connector page button.


5. Now enter a Friendly name for the TAXII Server collection. This will be stamped on all the indicators as the Source of the indicator.


6. Now enter the API Root, Collection ID, Username and Password that you obtained from IntSights.


7. Click the Add button.

You should now see a confirmation on the notification dialog that the connection was established successfully. The TAXII Server will now show up in the List of the configured TAXII Servers.

View imported indicators from IntSights TAXII Server in Azure Sentinel

Now that threat intelligence indicators from the IntSights TAXII Server are being imported into Azure Sentinel, you can view them in one of the two below mentioned ways in Azure Sentinel:

a. The ThreatIntelligenceIndicators table in Log analytics

1. Open the Azure portal and navigate to the Azure Sentinel service.


2. Choose the workspace where you imported threat indicators from IntSights using the Threat Intelligence – TAXII Data connector.


3. Select Logs from the General section of Azure Sentinel.


4. The ThreatIntelligenceIndicator table is located under the SecurityInsights group.


5. Use the following query to find indicators from IntSights:

         ThreatIntelligenceIndicator

         | where SourceSystem == “Friendly name of the TAXII Server”

b. Threat Intelligence blade under the Threat Management menu

1. Open the Azure portal and navigate to the Azure Sentinel service.


2. Choose the workspace where you imported threat indicators from IntSights using the Threat Intelligence – TAXII Data connector.


3. Select Threat Intelligence from the Threat management section of Azure Sentinel.


4. You can filter the indicators according to the Source to view the ones that you imported from IntSights. To do so, select the friendly name of the IntSights TAXII Sever you used from the Source pill filter.

Use imported indicators from IntSights TAXII Server in Azure Sentinel

Now that you have imported the indicators into Azure Sentinel, you can use them for matching against log sources. This can be done using the Azure Sentinel out-of-the-box analytics rules by modifying them or by creating new rules from scratch. The set of out-of-the-box analytics rules used to match threat indicators with your event data all have names beginning with, ‘TI map’ under the Analytics section in the Configuration menu. All these rule templates operate similarly with the only difference being what type of threat indicators are used (domain, email, file hash, IP address, or URL) and which event type to match against.

Get insights about your threat intelligence using the new IntSights Workbook

You can use the IntSights Workbook to visualize important information about the threat intelligence you have imported from the IntSights TAXII Server. This workbook provides an interactive dashboard about the threat intelligence you have imported from IntSights. The IntSights Workbook is available on the Azure Sentinel GitHub page. The name of the workbook is “IntsightsIOCWorkbook”.

You can follow the below mentioned steps to get the IntSights Workbook:

1. Open the Azure portal and navigate to the Azure Sentinel service.


2. Choose the workspace where you imported threat indicators from the IntSights TAXII Server.


3. Select Workbooks from the Threat management menu.


4. Navigate to the Templates tab and search for the workbook titled IntSights IOC Workbook.


5. Select the Save button and choose an Azure location to store the workbook.


6. Now select the View saved workbook button to open the workbook for viewing.

Send tags for indicators back to IntSights

You can send a tag to your IntSights account for every IOC that was sent by IntSights and seen in your environment so that you can further analyze the data in the IntSights platform. This can be done simply by deploying a Playbook from the Azure Sentinel GitHub.

Conclusion

With the IntSights and Azure Sentinel integration, you can now gain visibility on indicators of compromise from thousands of sources across the clear, deep, and dark web for advanced detection and hunting threats. You can also receive additional context about the IOCs from the IntSights feed to protect your organization against targeted threats.

Protect your Box environment and Data using Microsoft Cloud App Security

by Contributed | Jan 20, 2021 | Technology

This article is contributed. See the original author and article here.

One of the most used non-Microsoft app that Microsoft Cloud App Security can help protect is Box.

You may ask: “Why would I connect Box to MCAS? What benefits will I gain?”

Continuing on our series on how to use MCAS to protect your non-Microsoft apps, we’ll discuss leveraging MCAS to detect threat impacting your Box environment and to protect your data in the cloud.

Why connect Box?

In short: for the exact same reasons you would want to connect Office 365 and more, as described here:

How to connect Box?

First thing first, let’s discuss how to connect Box to Cloud App Security.

The process is as straightforward as can be, and is fully described in our Official documentation.

If you would rather see it in action, check out the video below:

Configure MCAS for Box

By simply connecting box you already gain value: not only the default threat detection policies will apply automatically, but any File Policy you have created to support another app, such as Office 365, will also apply by default to Box (only governance actions require editing existing policies).

Therefore, you would be able to start enforcing compliance requirements right after the connection is established.

Of course, each app being unique, there are a number of Box specific configurations and policies that can be leveraged. Let’s start here with best practices that apply to most customers.

Quick config – Quick value!

Enabling Box policy templates

With regards to Box specifically, we created the following templates to help you handle the specificities of the app, and we recommend most customers to enable them as Box is connected to your MCAS environment.

The video below illustrates how to use these templates in your environment:

Generic templates 

On top of these specific Box use cases, you can use all the generic features and policy templates offered in MCAS. Here are a few easy examples to deploy.

Configure your own policy

Of course, these pre-canned templates are only the tip of the iceberg of what can be done to protect your Box environment.

Two main types of policies would apply to your Box deployment.

First, Activity Policies can be configured to detect virtually any activity that you deem suspicious for your environment. These are particularly useful if you are concerned about a specific threat in your environment.

One of the most common use cases we see for Box users is the ability to apply Data Loss Prevention (DLP) policies.

For that, one can use MCAS File Policies. They allow the admin to detect files with specific properties, sharing level, and even do content inspection to detect sensitive data.

One of the key benefits of these File Policies is that they can apply equally to all apps. For instance, if you are using Office 365 and Box, a single policy can be applied to detect your sensitive data shared in the cloud (should you decide to have separate policies for each of your apps it is also possible using the “App” filter).  See the capture below for an example of a policy detecting Credit Card Numbers in DOC files stored in OneDrive, SharePoint or Box:

Governance Actions

The last part of the File policy creation page is dedicated to Governance actions. These allow you to define actions that will be executed automatically when a policy is triggered. These can be different for each app. For Box the list is quite extensive as displayed here:

 Let’s discuss a few of these.

Real time control

The policies and controls we have discussed above are all relying on Box’s APIs to query activities and data.  While this allows monitoring activities very specific to Box and data already stored, it is an out of band connection (cloud to cloud, users are never aware of this connection) and as such, data is received by MCAS in Near Real Time.

For use-cases where real time controls are required, we can leverage another component of MCAS: Conditional Access App Control.

This feature allows MCAS to act as a reverse proxy in the cloud, and allows for a real time control of several activities, for Box or any other Cloud App:

• Control file downloads


• Control file Uploads (including malware detection)


• Control or prevent Cut/Copy/Paste/Print

Some of the most common scenario used with Conditional access app Control with Box are:

• Block download of sensitive data to unmanaged devices


• Prevent upload of malware.


• Prevent copying or printing data from an unmanaged device.


• Prevent file sharing: clicking on the share button would be blocked.


• Read-only mode: prevent file editing or file creation/upload

More info on how to use Conditional Access App control is available here:

• MCAS Data Protection Blog Series: Box Real-Time Protections


• Protect apps with Microsoft Cloud App Security Conditional Access App Control


• Deploy Conditional Access App Control for featured apps (including Box)


• Configure Session policies

You can also learn about how to deploy Conditional Access App Control in the videos here:

• Configuring real-time monitoring and Control with Microsoft Cloud App Security


• Configuring a policy to block uploads in real-time with Microsoft Cloud App Security

Share your thoughts!

We hope this will help you get the best value out of MCAS and secure your environment.

Have you found a scenario that we haven’t covered here? Please share with our community and let us know in the comments below.

(By Idan Basre and @Yoann Mallet)  

Azure Logic Apps Running Anywhere – Built-In Service Bus Trigger: batching and session handling

by Contributed | Jan 20, 2021 | Technology

This article is contributed. See the original author and article here.

Built-In Service Bus Trigger: batched message processing and session handling

Logic App Refresh preview provides us with the option to create a built-in S trigger to receive messages from Service Bus topic or queue.

In this blog post two advanced Service Bus message processing are discussed:

• Azure Service Bus batch processing and how to configure the max batch count of messages.


• Messages processing in Logic App for the session-aware Service Bus queues or subscriptions.

Service Bus queue batch processing:

To improve the message retrieval performance for Service Bus queue, it is highly recommended to receive the messages in batch. The Logic App Service Bus trigger for queue by default supports array of Service Bus messages as output.

The prefetchCount is used to specify how many messages should be retrieved in a “batch” to save the roundtrips from Logic Apps back to the Azure Service Bus. Prefetching messages increases the overall throughput for a queue by reducing the overall number of message operations, or round trips.

The prefetchCount can be configured in the global configuration settings in host.json, the Azure function trigger requests these many messages for the Azure Function.

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "prefetchCount": 20,
            "messageHandlerOptions": {
                "autoComplete": true,
                "maxConcurrentCalls": 32,
                "maxAutoRenewDuration": "00:05:00"
            }

The host.json can be edited using Kudu Advance tool (in case the Logic App is created in Azure Portal).

Message processing for session-aware service bus queue/subscriptions:

You can enable the session by selecting the Enable sessions checkbox while creating the Service Bus queue in UI :

In the session-aware Service Bus queue the built-in Service Bus trigger cannot receive the message by default. The sessions are not enabled for Service Bus trigger by default.

The Azure Service Bus trigger is based upon Azure Function ServiceBusTrigger binding configuration of Azure function, the isSessionsEnabled configuration needs to set for it to enable the session processing. This option can be handled in the logic app code definition as given below:

        "triggers": {
            "When_messages_are_available_in_Service_Bus_queue": {
                "inputs": {
                    "parameters": {
                        "isSessionsEnabled": true,
                        "queueName": "psrivassbq5"
                    }

Once you update the Logic App definition you can view this in the designer as shown below. However, the isSessionsEnabled trigger input option cannot be configured on the designer surface. The input option IsSessionEnabled in UI will be provided in the Logic App Refresh future release.

When the messages are queued in Service Bus session queue, it will trigger the Service Bus trigger based upon sessions in Service Bus queue. You can use the SessionId  property from Service Bus trigger output.