Upload Custom Windows Hyper-V Image for Gen 2 VM in Azure

Upload Custom Windows Hyper-V Image for Gen 2 VM in Azure

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

Introduction

This is Andrew Coughlin and I am a Customer Engineer at Microsoft focusing on Azure IaaS. In this blog I will focus on how to upload a custom windows Hyper-V image for generation 2 virtual machines in Azure. Support for generation 2 virtual machines in Azure was released on November 4, 2019, these systems use UEFI boot, SCSI, supported on VMs that support premium storage compared to generation 1 which use PCAT boot, IDE and are available on all VM sizes.  Generation 2 VMs provide for OS disk size greater than 2TB in size and build larger VMs, up to 12TBs. To get additional information about generation 2 virtual machines in Azure please visit this post.

 

If you have ever uploaded a custom image in Azure in the past you will notice the process is very similar.

 

Prerequisites

  • Review the Support for generation 2 VMs on Azure.
  • Install Azure PowerShell as documented here.
  • Create Hyper-V Gen 2 machine to be used as the image.
  • Prepare your Windows Hyper-V image is documented here.
  • Convert VHDX to VHD as documented here.
  • Download and Install azcopy as documented here.
  • Sign in with Azure as documented here.
  • Select Azure subscription to upload image as documented here.

 

Upload Hyper-V Image to Managed Disk

First you want to determine which resource group the image will reside in or if you will create a new resource group. As a reminder a resource group is a container that holds related solutions: virtual machines, storage accounts, disks virtual networks, etc. for your Azure solutions. A resource group can include all resources for your solutions or only those resources that you want to be managed together. For documentation on how to create a new resource group, this can be found on this page. In this example I’m going to use the resource group called “rg-images”.

 

AndrewCoughlin_0-1599851626911.png

 

First, we need to open an elevated PowerShell command prompt.

 

AndrewCoughlin_1-1599851626922.png

 

Next, we will set some variables as we will need these throughout the process, in this example. We are going to be creating this image in Central US, with the image name W2K19-Image-V2, in the resource group called rg-images, with a disk image called W2K19-Image-V2.

  • $location = ‘Central US’
  • $imageName = ‘W2K19-Image-V2’
  • $rgName = ‘rg-images’
  • $diskname = ‘W2K19-Image-V2’

 

AndrewCoughlin_2-1599851626929.png

 

Next, we want to create an empty managed disk, you will type the following commands:

 

 

 

$vhdSizeBytes = (Get-Item "<full File Path>").length

$diskconfig = New-AzDiskConfig -SkuName 'Standard_LRS' -OsType 'Windows' -UploadSizeInBytes $vhdSizeBytes -Location $location -CreateOption 'Upload'

New-AzDisk -ResourceGroupName $rgName  -DiskName $diskname -Disk $diskconfig

 

 

 

AndrewCoughlin_3-1599851626952.png

 

NOTE: You can replace the Standard_LRS, with Premium_LRS or StandardSSD_LRS.  At the writing of this blog Ultra disks are currently not supported.

 

Next, we need to confirm the disk status is equal to “ReadyToUpload”, you will type the following:

 

 

 

$disk = Get-AzDisk -ResourceGroupName $rgName -DiskName $diskname

$disk.DiskState

 

 

 

AndrewCoughlin_4-1599851626954.png

 

NOTE: The disk status must be set to “ReadyToUpload”, if it is not you need to check what was typed in the “New-AzDiskConfig” command.

 

Now we want to create the writable shared access signature (SAS) for the managed disk we just created.  Then we will get the disk status and make sure it is equal to “ActiveUpload”, to do this you will type the following:

 

 

 

$diskSas = Grant-AzDiskAccess -ResourceGroupName $rgName -DiskName $diskname -DurationInSecond 86400 -Access 'Write'

$disk = Get-AzDisk -ResourceGroupName $rgName -DiskName $diskname

$disk.DiskState

 

 

 

AndrewCoughlin_5-1599851626956.png

 

Now we are ready to upload our disk to Azure, to do this you will type the following and wait for the process to complete:

 

 

 

cd <location of Azcopy>

.azcopy.exe copy "<location of vhd>" $diskSas.AccessSAS --blob-type PageBlob

 

 

 

AndrewCoughlin_6-1599851626969.png

 

When the upload is completed you will get the following results:

 

AndrewCoughlin_7-1599851626986.png

 

After the upload has completed, you will revoke access from the disk as this is not needed, you will type the following:

 

 

 

Revoke-AzDiskAccess -ResourceGroupName $rgName -DiskName $diskname

 

 

 

AndrewCoughlin_8-1599851626993.png

 

Create Image from Managed Disk

We now have the managed disk uploaded to the cloud.  The next step is to create an image from that managed disk.  When the image is created, we want to make sure to specify this image will be a V2 image.  To do this you will type the following:

 

 

 

$imageConfig = New-AzImageConfig -Location $location -HypervGeneration V2

$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsState Generalized -OsType Windows -ManagedDiskId $disk.Id

$image = New-AzImage -ImageName $imageName -ResourceGroupName $rgName -Image $imageConfig

 

 

 

AndrewCoughlin_9-1599851627014.png

 

Verify in the portal that our image is now created from our managed disk.  We can now start provisioning generation 2 virtual machines with this image.

 

AndrewCoughlin_10-1599851627021.png

 

Conclusion

There you have it, we have just uploaded a custom windows image and now we can use that image to deploy generation 2 virtual machines in your Azure environment.  Thank you for taking the time to read this blog, I hope this helps you and see you next time.

 

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Azure IoT TLS: Changes are coming! (…and why you should care)

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

Microsoft is updating Azure services in a phased manner to use TLS certificates from a different set of Certificate Authorities (CAs) beginning August 13, 2020 and concluding approximately on October 26, 2020. We expect that most Azure IoT customers will not be impacted; however, your application may be impacted if you explicitly specify a list of acceptable CAs (a practice known as “certificate pinning”). This change is limited to services in public Azure cloud and no sovereign cloud like Azure China.

 

This change is being made because the current CA certificates do not comply with one of the CA/Browser Forum Baseline requirements. This was reported on July 1, 2020 and impacts multiple popular Public Key Infrastructure (PKI) providers worldwide. Today, most of the TLS certificates used by Azure services are issued from the “Baltimore CyberTrust Root” PKI.

The following services used by Azure IoT devices will remain chained to the Baltimore CyberTrust Root*, but their TLS server certificates will be issued by new Intermediate Certificate Authorities (ICAs) starting October 5, 2020:

  1. Azure IoT Hub
  2. Azure IoT Hub Device Provisioning Service (DPS)
  3. Azure Storage Services

 

If any client application or device has pinned to an Intermediate CA or leaf certificate rather than the Baltimore CyberTrust Root, immediate action is required to prevent disruption of IoT device connectivity to Azure.

 

* Other Azure service TLS certificates may be issued by a different PKI.

 

Certificate Renewal Summary

The table below provides information about the certificates that are being rolled. Depending on which certificate your device or gateway clients use for establishing TLS connections, action may be needed to prevent loss of connectivity.

 

Certificate

Current

Post Rollover (Oct 5, 2020)

Action

Root

Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474
Expiration: Monday, May 12, 2025, 4:59:00 PM
Subject Name:
CN = Baltimore CyberTrust Root

OU = CyberTrust
O = Baltimore
C = IE

 

 

 

Not Changing

None

Intermediates

Thumbprints:

 

CN = Microsoft IT TLS CA 1

Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

—————————————————-

CN = Microsoft IT TLS CA 2

Thumbprint: 54d9d20239080c32316ed9ff980a48988f4adf2d

—————————————————-

CN = Microsoft IT TLS CA 4

Thumbprint: 8a38755d0996823fe8fa3116a277ce446eac4e99

—————————————————-

CN = Microsoft IT TLS CA 5

Thumbprint: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

—————————————————-

 

Expiration: ‎Friday, ‎May ‎20, ‎2016 5:52:38 AM
Subject Name:

OU = Microsoft IT

O = Microsoft Corporation

L = Redmond

S = Washington

C = US

Thumbprints:

 

CN = Microsoft RSA TLS CA 01

Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

—————————————————-

CN = Microsoft RSA TLS CA 02

Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

—————————————————-

 

Expiration: ‎Tuesday, ‎October ‎8, ‎2024 12:00:00 AM;
Subject Name:

O = Microsoft Corporation

C = US

Required

Leaf (IoT Hub)
 

Thumbprint: 8b1a359705188c5577cb2dcd9a06331807c0bb97
Expiration: ‎Friday, ‎March ‎19, ‎2021 6:15:48 PM

Subject Name:

CN = *.azure-devices.net

Thumbprint: Coming soon
Expiration: Coming soon
Subject Name:
CN = *.azure-devices.net

Required

Leaf (DPS)
 

Thumbprint: f568f692f3274ecbb479c94272d6f3344a3f0247
Expiration: ‎Friday, ‎March ‎19, ‎2021 5:58:35 PM

Subject Name:

CN = *.azure-devices-provisioning.net

Thumbprint: Coming soon
Expiration: Coming soon
Subject Name:
CN = *.azure-devices-provisioning.net

Required

Note: Both the intermediate and lea certificates are expected to change frequently. We recommend not taking dependencies on them and instead pinning the root certificate as it rolls less frequently.

 

 

Action Required

  1. If your devices depend on the operating system certificate store for getting these roots or use the device/gateway SDKs as provided, then no action is required.
  2. If your devices pin the Baltimore root CA among others, then no action is required related to this change.
    1. If your device interacts with other Azure services (e.g. IoT Edge -> Microsoft Container Registry), then you must pin additional roots as provided here.
  3. If your devices use a connection stack other than the ones provided in an Azure IoT SDK, and pin any intermediary or leaf TLS certificates instead of the Baltimore root CA, then immediate action is required:
    1. To continue without disruption due to this change, Microsoft recommends that client applications or devices pin the Baltimore root –
      1. Baltimore Root CA
        (Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474)
      2. To prevent future disruption, client applications or devices should also pin the following roots:
        1. Microsoft RSA Root Certificate Authority 2017
          (Thumbprint: 73a5e64a3bff8316ff0edccc618a906e4eae4d74)
        2. Digicert Global Root G2
          (Thumbprint: df3c24f9bfd666761b268073fe06d1cc8d4f82a4)
    2. To continue pinning intermediaries, replace the existing certificates with the new intermediates CAs:
      1. Microsoft RSA TLS CA 01
        (Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a)
      2. Microsoft RSA TLS CA 02
        (Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75)
      3. To minimize future code changes, also pin the following ICAs:
        1. Microsoft Azure TLS Issuing CA 01
          (Thumbprint: 2f2877c5d778c31e0f29c7e371df5471bd673173)
        2. Microsoft Azure TLS Issuing CA 02
          (Thumbprint: e7eea674ca718e3befd90858e09f8372ad0ae2aa)
        3. Microsoft Azure TLS Issuing CA 05
          (Thumbprint: 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5)
        4. Microsoft Azure TLS Issuing CA 06
          (Thumbprint: 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0)
  1. If your client applications, devices, or networking infrastructure (e.g. firewalls) perform any sub root validation in code, immediate action is required:
    1. If you have hard coded properties like Issuer, Subject Name, Alternative DNS, or Thumbprint of any certificate other than the Baltimore Root CA, then you will need to modify this to reflect the properties of the newly pinned certificates.
    2. Note: This extra validation, if done, should cover all the pinned certificates to prevent future disruptions in connectivity.

 

Validation

We recommend performing some basic validation to mitigate any unintentional impact to your IoT infrastructure connecting to Azure IoT Hub and DPS. We will be providing a test environment for your convenience to try out before we roll these certificates in production environments. The connection strings for this test environment will be updated here soon.

 

A successful TLS connection to the test environment indicates a positive test outcome – that your infrastructure will work as is with these changes. The test connection strings contain invalid keys, so once the TLS connection has been established, any run time operations performed against these services will fail. This is by design since these resources exist solely for customers to validate their TLS connectivity. The test environment will be available until all public cloud regions have been updated.

 

Support

If you have any technical questions on implementing these changes, with the options below and a member from our engineering team will get back to you shortly.

  • Issue Type: Technical
  • Service: Internet of Things/IoT SDKs
  • Problem type: Connectivity
  • Problem subtype: Unable to connect

 

Additional Information

  1. IoT Show: To know more about TLS certificates and PKI changes related to Azure IoT, please check out the IoT Show:

  2. Microsoft wide communications: To broadly notify customers, Microsoft had sent a Service Health portal notification on Aug 3rd, 2020 and released a public document that include timelines, actions that need to be taken, and details regarding the upcoming changes to our Public Key Infrastructure (PKI).
Introducing the Azure Network Security Tech Community and Github Repo

Introducing the Azure Network Security Tech Community and Github Repo

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

Hello World!

 

With so many Azure customers relying on native Azure network security tools to secure their networks and applications, it is clear that there is a demand for more information on this topic. We are here to deliver just that. My team is dedicated to helping customers deploy and get the most out of Azure Network Security services, and we will be using Tech Community to amplify our voices.

 

What are the Azure Network Security services?NetSec.png

Azure network security is a set of native services meant to secure cloud and hybrid networks using the Zero Trust approach. To narrow it down, the primary tools we will cover here are Azure Firewall and Firewall Manager, Azure DDoS Protection, and Azure WAF. Yes, we’re aware that WAF deals with Application Security and not as much Network Security, but we’re bringing the concepts together. Web applications are delivered over networks, right?

 

Naturally while we are concentrating on these core services, that does not mean others will not be discussed. Quite the opposite, in fact. Building a secure Azure network can involve a vast array of resources. Expect attention to also be paid to Azure Bastion, Network Watcher, NSGs, as well as core networking components ranging from Route Tables to Virtual WAN.

 

Here’s a quick introduction to our primary tools for those that are unfamiliar:

 

Azure FirewallFirewall.png

Azure Firewall is the Azure-native PaaS firewall. Not to be confused with NSGs or resource firewalls on other PaaS services, Azure Firewall is built to be a centrally deployed and managed service that handles all the traffic from your regional deployments. Being a PaaS service, it auto-scales to accommodate increasingly demanding workloads, and it can be managed using the tools and methods you are already using to deploy and manage other resources – CLI, API, ARM, or whichever combination of abbreviations suits you best.

 

Azure Firewall is meant to perform all the same functions as most Network Virtual Appliances (NVAs), including segmenting east-west traffic within your VNets and controlling inbound and outbound traffic. Learn more in the docs.

 

Azure Firewall ManagerFirewallManager.png

Firewall Manager is a service that serves a growing number of purposes. First, it allows for easy management of multiple Azure Firewalls. By abstracting the Firewall Policy away from each individual Firewall, you can use Firewall Manager to assign a central set of policies to one or many Firewalls across the globe. Additionally, Firewall Manager can be used to manage security services in Azure VWAN Hubs, which can either be more Azure Firewalls or third-party services such as Zscaler and iboss.

 

Read the docs to get the full story on Firewall Manager.

 

Azure WAFWAF.png

Azure Web Application Firewall, as the name implies, is a firewall specifically meant to inspect web application traffic. Azure WAF can be attached to Application Gateway, Front Door, or CDN. There are some differences based on which service WAF is attached to, but the major function is the same – WAF analyzes decrypted traffic to match every request against its rules. These rules can consist of managed rulesets that look for common attacks found in the OWASP Top 10, bot protection rulesets that can block known malicious bot traffic, and custom rules that can look for various combinations of patterns.

 

To learn more, read some more docs.

 

Azure DDoS Protection StandardDDoSProtection.png

Every resource that lives in an Azure data center benefits from the inbuilt platform-level DDoS Protection. Our DDoS Protection infrastructure is in place to ensure the availability of each Azure region, and this protection is inherited by every Azure service. For customers that need to ensure that their workloads are protected against every attack, DDoS Protection Standard is available to tune the protection mechanisms to each individual workload. Along with Standard comes several other features, which include cost protection for resources that auto-scale during an attack, high-priority support during attacks, and some great logging to feed to your SOC.

 

This is the final time in this post that docs will be read.

 

GitHub RepositoryGitHub-Mark-120px-plus.png

 

There has been such an appetite among our customers for useful technical content that we decided to create a GitHub repo just for Azure network security. Find it at Aka.ms/AzNetSec. You will find a combination of scripts, Policies, KQL queries, ARM templates, Azure Monitor Workbooks, and other odds and ends. Our goal is to make everything as useful as possible to take the guess work out of using our tools.

 

We encourage contributions from the community, so if you have something you think may be useful to others, don’t hesitate to fork and send us a pull request. Even if you don’t wish to contribute, please leave us feedback and suggestions for new content to create; we strive for continuous improvement. If you have suggestions or feedback regarding specific product features, please use Azure User Voice. Yes, we do monitor it and use the feedback when planning features.

 

Tech Community Plans

 

This has been a quick introductory post to share this team’s focus and areas of interest. We have lots of ideas for things to share in the future based on our experience with customers, but we also want to listen to the feedback we receive here. If there is something you would like to know more about, please leave a comment here or post about it in the Network Security conversations space.

 

How to Protect Office 365 with Azure Sentinel

How to Protect Office 365 with Azure Sentinel

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

Special thanks to Clive Watson” and “Ofer Shezafthat collaborating with me on this blog post.

 

Due to the COVID-19 crisis, the usage of Office 365 has increased which introduces new security monitoring challenges for SOC teams. Increase usage means that the service should be more focal for defenders.

 

Over the past few mounts I have been working with my customers, on approaches to onboard Office 365 and related services into Azure Sentinel and the benefit of built-in solutions that a Cloud based Security Information and Event Management (SIEM) and Security Orchestration, Automation and Response (SOAR) bring, such as these use cases.

 

This blog post is built as a checklist and covers the following topics:

 

  • Required data sources for Office 365 and related workloads
  • Onboarding of data sources
  • Visualizing data
  • Using of out of the box Analytics Rules templates
  • Hunting with Azure Sentinel
  • Integration of 3rd party Threat Intelligence (TI)
  • Data enrichment capabilities
  • Automation with SOAR capabilities
  • Integration with Ticketing Systems
  • Integration with 3rd party SIEMs

 

Required data sources for Office 365 and related workloads

Choosing the right telemetry for Office 365 and related workloads depends on the enterprise’s security model. For instance, if an enterprise which follow the Zero Trust approach from Microsoft would focus on different telemetry than an enterprise with a classical security approach.

 

The following data sources should be the minimum onboarded to monitor Office 365:

 

 

In addition, the sources below are optional as they depend on additional licenses. Azure Sentinel can benefit from these expert systems and it is recommended to onboard if licensed or consider adding these to aid with detection and use cases.

 

  • Azure Activity Directory Identity Protection alerts
  • Office 365 Advanced Threat Protection and Threat Investigation and Response alerts
  • Microsoft Cloud App Security alerts

 

Lastly, the following data sources are optional and would unlock more value by correlating different data sources using SIEM and SOAR capabilities.

 

  • Logs from Domain Controllers and Azure Advanced Threat Protection alerts
  • Telemetry from client devices
  • Logs and alerts from Proxies and Firewalls
  • 3rd Party Threat Intelligence feeds           

 

Onboarding of data sources

Azure Sentinel comes with a several built-in and custom connectors to onboard Office 365 and related workloads.

 

Data Source

Default Connector

Custom Connector

Azure Active Directory Sign-In and Audit Logs

Reference URL

n/a

Office 365 / Exchange Online Logs

Office 365 / SharePoint Online Logs

Office 365 / Microsoft Teams Logs

Reference URL

n/a

Office 365 Audit.General Logs

n/a

Azure Function App connector

Office 365 – DLP.All Logs

n/a

Azure Function App connector

Office 365 Security and Compliance Alerts

n/a

Azure Logic App connector

Office 365 Message Trace Logs

n/a

Azure Function App connector

Microsoft Secure Score Recommendations

n/a

Azure Logic App connector

 

GIFT Demonstration – Enable the Office 365 data connector:

 

Office 367 Data Connector Next Steps.gif

 

For a full list, please see, the Azure Sentinel Grand List.

 

Visualizing data

Azure Sentinel has many built-in workbooks that provide extensive reporting capabilities analyzing your connected data sources to let you quickly and easily deep dive into the data generated by those services. The built-in workbooks can be changed and customized as needed.  The Workbooks are provided by Microsoft, our data connector partners and the community.

 

These built-in Workbooks are available in Azure Sentinel for Office 365 and related workloads.

 

Workload / Purpose

Sample Workbooks

General

Azure Sentinel Workbooks 101 (with sample Workbook)

 

Usage Reporting for Azure Sentinel

 

Security Alerts

Azure Active Directory

Azure Active Directory Sign-In Logs

 

Azure Active Directory Audit Logs

 

Additional Azure Monitor Workbooks for Azure AD

 

How to use Azure Sentinel to follow users travel and map their location

Office 365

Office 365 General

Office 365 Exchange Online

 

Office 365 SharePoint Online

 

Office 365 Exchange, SharePoint and Teams DLP Workbooks

 

Graph Visualization of External MS Teams Collaborations in Azure Sentinel

 

Office 365 Message Trace

 

For more information and instructions on how to use Azure Sentinel Workbooks, please see:

 

Visualize your data using Azure Monitor Workbooks in Azure Sentinel | Microsoft Docs

 

In case you prefer to use Power BI for analytics and visualization:

 

Import Azure Monitor log data into PowerBI:

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/powerbi

 

GIFT Demonstration – How to enable and use the Office 365 Workbook:

 

Office 367 Workbook.gif

 

Using out of the box Analytics Rule Templates

Once you have connected your required data sources, you can use the Analytics Rule templates available in Azure Sentinel to generate incidents when certain criteria are matched. The Analytics Rules can be changed and customized as needed.

 

These Analytics Rule templates are available in Azure Sentinel for Office 365 and related workloads.

 

Workload

Analytics Rules Templates

Azure Active Directory

Azure Active Directory Sign-In Logs

 

Azure Active Directory Audit-Logs

 

Correlation Rules for Azure Active Directory

Office 365

Office 365 Activity

 

Microsoft Teams

 

Office 365 DLP

 

Message Trace

Azure Active Directory Identity Protection

Microsoft Cloud App Security

Azure Advanced Threat Protection

Microsoft Security alert templates

 

Tip: You see the related Analytics Rules (and required data) that match the connector on the “Next Steps” page of the “Add Connector” wizard.

 

Next Step.png

 

Hunting with Azure Sentinel

Azure Sentinel has built-in Hunting Queries to look proactively for new anomalies that you are not yet detecting with your Analytics Rules.  You can use these Hunting Queries and Live Stream  to create interactive sessions that let you test newly created queries as events occur, get notifications from the sessions when a match is found, and launch investigations if necessary. You can quickly create a livestream session using any Log Analytics query.

  • Test newly created queries as events occur
  • You can test and adjust queries without any conflicts to current rules that are being actively applied to events. After you confirm these new queries work as expected, it’s easy to promote them to custom alert rules by selecting an option that elevates the session to an alert.

These Hunting Queries are available in Azure Sentinel for Office 365 and related workloads.

 

Workload

Hunting Queries

Azure Active Directory

Azure Active Directory Sign-In Logs

 

Azure Active Directory Audit-Logs

Office 365

Office 365 Activity

 

Microsoft Teams

 

Message Trace

 

GIFT Demonstration – Using the Built-In Hunting Queries for Office 365:

 

HUnting.gif

 

Integration with 3rd Party Threat Intelligence

Azure Sentinel lets you import you own threat intelligence indicators, which can enhance your security analysts’ ability to detect and prioritize known threats.

 

You can stream threat indicators to Azure Sentinel by using one of the integrated threat intelligence platform (TIP) products listed in the next section, connecting to TAXII servers, or by using direct integration with the Microsoft Graph Security tiIndicators API.

 

The Threat Intelligence data connector includes out of the box Analytics Rules and Hunting Query templates for Office 365 and related workloads.

 

Threat Intelligence Analytics Rules

Threat Intelligence Hunting Queries

 

Data enrichment capabilities

Data enrichment is key to associating data in context of enterprises. For instance, data enrichment would add additional information or context to the ingested logs to make it more valuable.

 

For Office 365 and related workloads Azure Sentinel provides these enrichment use cases:

 

Purpose

Source

Enrich User Entities with Azure Active Directory information

Reference URL

Enrich IP Entities with GeoIP information

Reference URL

Enrich IP Entities with VirusTotal information

Reference URL

Enrich URL Entities with VirusTotal information

Reference URL

Sentinel Alert Evidence

Reference URL

 

Automation with SOAR capabilities

Azure Sentinel has built-in SOAR capabilities to orchestrate and automate common and complex tasks. Azure Sentinel uses Azure Logic App and Azure Function Apps for automation. Both services are built-in in Azure. The SOAR use cases are published here: GitHub, and can be deployment via ARM-Templates.

 

Using automation can save time, improve efficiency and help you improve your SOC (Security Operations Center) metrics and reduce the workload for the Securtity analyts.

 

https://docs.microsoft.com/en-us/azure/sentinel/manage-soc-with-incident-metrics

Azure Sentinel includes these automation solutions for Office 365 and related workloads:

 

Purpose

Source

Block Azure Active Directory User

Reference URL

Confirm an Azure Active Directory User

Reference URL

Dismiss an Azure Active Directory User

Reference URL

Reset Azure Active Directory User Password

Reference URL

Revoke Azure Active Directory Sign-In Session

Reference URL

Delete Email for User Mailbox

Reference URL

Assign Incident to Specific Owner

Reference URL

Involve the User into Incident Process

Reference URL

Post Incident Details to Microsoft Teams

Reference URL

Post Incident Details to Slack

Reference URL

 

GIFT Demonstration – How to enable the “Block Azure Active Directory User” Playbook:

 

SOAR.gif

 

Integration with Ticketing Systems

As part of the SOAR capabilities, Azure Sentinel support integration with ticketing systems.  You can also just send a simple email or Teams message with the same data if you prefer (or do this in parallel with your Ticket).

 

Ticketing System

Source

ServiceNow

Open a Service Now Ticket

 

Aggregate Service Now Ticket

 

Close an Incident from Service Now

Jira

Open a Jira Ticket

IBM Resilient (OnPrem)

Create an IBM Resilient Incident

Zendesk

Open a Zendesk Ticket

 

Integration with 3rd Party SIEM

In case you are approaching Side-by-Side along with your exiting SIEM.

 

Exiting SIEM

Source

Splunk

Reference URL

QRadar

Reference URL

Other 3rd Party SIEMs

Reference URL

 

Summary

Ingesting of Office 365 alert logs are free, Azure Sentinel comes with a lot of use cases which help organizations to monitor and protect Office 365 workload, as well allows easy integration into existing SOC environment.

 

In this post we have covered the basics, looking at the data required, how to on-board connectors, how to manage Alerts, how to Hunt and automate responses to the results, and also connecting to 3rd party ticketing or SIEM solutions.

Friday Five: Azure Cloud, Active Directory, More!

Friday Five: Azure Cloud, Active Directory, More!

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

image.png

Project Server Permission Mode Vs SharePoint Permission Mode

Mohamed El-Qassas is a Microsoft MVP, SharePoint StackExchange (StackOverflow) Moderator, C# Corner MVP, Microsoft TechNet Wiki Judge, Blogger, and Senior Technical Consultant with +10 years of experience in SharePoint, Project Server, and BI. In SharePoint StackExchange, he has been elected as the 1st Moderator in the GCC, Middle East, and Africa, and ranked as the 2nd top contributor of all the time. Check out his blog here.

image.png

Start your DevOps pipeline in the Azure Cloud

James van den Berg has been working in ICT with Microsoft Technology since 1987. He works for the largest educational institution in the Netherlands as an ICT Specialist, managing datacenters for students. He’s proud to have been a Cloud and Datacenter Management since 2011, and a Microsoft Azure Advisor for the community since February this year. In July 2013, James started his own ICT consultancy firm called HybridCloud4You, which is all about transforming datacenters with Microsoft Hybrid Cloud, Azure, AzureStack, Containers, and Analytics like Microsoft OMS Hybrid IT Management. Follow him on Twitter @JamesvandenBerg and on his blog here.

IMG_0747.jpg

ASP.NET Core 5: Make your options immutable

Anthony Giretti is a specialist in web technologies with 14 years of experience. He specializes in particular in Microsoft .NET and he is currently learning the Cloud Azure platform. He has twice received the Microsoft MVP award and he is also a certified Microsoft MCSD and Azure Fundamentals. Follow him on Twitter @anthonygiretti.

image.png

Starting with FIDO2 security keys With Azure Active Directory

Robert Smit is a EMEA Cloud Solution Architect at Insight.de and is a current Microsoft MVP Cloud and Datacenter as of 2009. Robert has over 20 years experience in IT with experience in the educational, health-care and finance industries. Robert’s past IT experience in the trenches of IT gives him the knowledge and insight that allows him to communicate effectively with IT professionals. Follow him on Twitter at @clusterMVP

Microsoft Flight Simulator 2020 running in Windows Virtual Desktop!

Freek Berson is an Infrastructure specialist at Wortell, a system integrator company based in the Netherlands. Here he focuses on End User Computing and related technologies, mostly on the Microsoft platform. He is also a managing consultant at rdsgurus.com. He maintains his personal blog at themicrosoftplatform.net where he writes articles related to Remote Desktop Services, Azure and other Microsoft technologies. An MVP since 2011, Freek is also an active moderator on TechNet Forum and contributor to Microsoft TechNet Wiki. He speaks at conferences including BriForum, E2EVC and ExpertsLive. Join his RDS Group on Linked-In here. Follow him on Twitter @fberson