Secure Application Lifecycle – Part 3 – Azure Sentinel

Secure Application Lifecycle – Part 3 – Azure Sentinel

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

In the past part 1 and part 2, I discussed how we can monitor the security and health of our subscription manually. Also, we used Microsoft tools to find security issues with the subscription and discussed how we could resolve them.


Today I would like to discuss another Azure service called Azure Sentinel, to monitor security incidents in our subscription and respond to them.


 


What is Azure Sentinel?


Microsoft Azure Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution. Azure Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.


Azure Sentinel is our birds-eye view across the enterprise alleviating the stress of increasingly sophisticated attacks, increasing volumes of alerts, and long resolution time frames.



  • Collect data at cloud scale across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds. 

  • Detect previously undetected threats, and minimize false positives using Microsoft’s analytics and unparalleled threat intelligence. 

  • Investigate threats with artificial intelligence, and hunt for suspicious activities at scale, tapping into years of cybersecurity work at Microsoft. 

  • Respond to incidents rapidly with built-in orchestration and automation of common tasks.


magdysalem_0-1611613203893.png


 


Using Azure Sentinel, We can collect security data. Then we can use the tools offer by Azure Sentinel to investigate these logs for the events we are interested in.


Also, we can use machine learning backed Azure sentinel tools to detect familiar security incidents. After we found these incidents, we can easily respond to them using responders. This means we can monitor Azure subscription security status or the subscription health and respond to Misconfigurations.


 


Consider the following example. We have resource group with the following azure services,


magdysalem_1-1611613203912.png


What kind of security checks we could enable and monitor



  • Storage account: HTTPS is mandatory enabled.

  • Key vault: soft-delete is enabled.

  • Azure SQL database: Threat detection is enables.


This can be done easily by configuring these services to send their logs to in Azure Sentinel workspace to monitor and report. The following section is a walkthrough demo where we will do the following:



  • Provision Sentinel workspace

  • Configure resources to send diagnostic logs to Sentinel.

  • Configure Sentinel to respond to incidents.


Provision Azure Sentinel Service


We can select all services, search for Sentinel, and click on Azure Sentinel.


magdysalem_2-1611613203933.png


 


Then we can click Create a new workspace


magdysalem_3-1611613203938.png


 


magdysalem_4-1611613203955.png


 


Now, we will give the workspace name and select a region that is suitable for Our resources. Once our workspace is ready then We can click add Azure Sentinel


magdysalem_5-1611613203968.png


 


magdysalem_6-1611613204003.png


our Azure sentinel workspace is created. So now we can go ahead and configure a few Azure resources to send logs to this workspace.


Configure resources to send diagnostic logs to Sentinel


We will start with apps services. From the portal page for the app services, we can scroll down under monitoring, click on diagnostic settings, click on add diagnostic settings.


magdysalem_7-1611613204044.png


 


From the Diagnostics setting, we can select a different type of logs to send to Sentinel workspace as following


magdysalem_8-1611613204062.png


 


We can do the same steps with other resources like Azure Key Vault


magdysalem_9-1611613204083.png


 


Now if we check the Azure Sentinel workspace page, we will see something like the following.


magdysalem_10-1611613204104.png


 


Configure Azure Sentinel to respond to Incidents


In this section, we will explain how to configure Azure Sentinel to respond to incidents and security violations. First, we need to connect Azure Sentinel to a data source by clicking on data connectors, it will show us a list of data sources.


magdysalem_11-1611613204136.png


 


We will configure Azure Sentinel to detect and respond to policy violations in our subscription. In this case, we will need to select Azure Activity as our data connector and click “Configure Azure Activity Logs”


magdysalem_12-1611613204158.png


 


Then we select the subscription and click Log Analytics Connection


magdysalem_13-1611613204171.png


 


magdysalem_14-1611613204182.png


 


Now, We are connected and Azure sentinel instance can now ingest Azure activity logs. We can check Activity Logs by running a simple query to make sure we are receiving logs


magdysalem_15-1611613204207.png


 


Next step, we will create a query to return policy violations.


magdysalem_16-1611613204232.png


 


Once we verify the query is working properly, we can start setting the alert. From Sentinel blade click on Analytics and click on “Create” to establish a new rule


magdysalem_17-1611613204253.png


 


Here we will fill the rule fields and Click Next


magdysalem_18-1611613204264.png


 


Under rule logic, we will enter the query that we created previously.


magdysalem_19-1611613204281.png


 


We will scroll down to specify how often we want the query to run.


magdysalem_20-1611613204295.png


 


After filling the schedule, we can click on Incident settings where we need to specify how we want Azure Sentinel to respond to the incident. If we do not have a playbook set up yet we can just click “Review” and create the alert


magdysalem_21-1611613204311.png


 


magdysalem_22-1611613204329.png


 


Next, we will add a new logic app to respond to the alert we just created in the above section.


From the Playbooks section click create a new playbook


magdysalem_23-1611613204345.png


 


We will be redirected to a new page to create a logic app


magdysalem_24-1611613204360.png


 


Once the logic app is created, we can review the “Overview page” and select “Blank Logic App”


magdysalem_25-1611613204372.png


 


The only difference between an ordinary logic, app, and responder is the first action. The first action here should be Azure sentinel.  Also if it is not showing, we can simply search for it.


magdysalem_26-1611613204376.png


 


Now, we will choice respond to Azure Sentinel Alert


magdysalem_27-1611613204398.png


 


Next will select the connection to connect to the Azure Sentinel Workspace instance


magdysalem_28-1611613204404.png


 


Once we complete the connections by choosing an existing one or create a new one.  We can use the Get entities functions, which enable us to get the relevant entities from inside the Entities list, such as accounts, IP addresses, and hosts. This will enable us to run actions on specific entities.


Now, We can define what happens when we trigger the playbook. We can add an action, logical condition, switch case conditions, or loops. For example, once an alert is triggered it will send an email and post a message in Team. Please review Logic App for more information


magdysalem_29-1611613204407.png


 


The last step now, we need to configure the alert to use the playbook we just created.


We start by clicking analytics and select the alert we click Edit


magdysalem_30-1611613204445.png


 


Click on Automated Response then click on the playbook we just created in the previous section


magdysalem_31-1611613204466.png


 


Then click Review and save. Now if any resource will violate the policy in place we will be notified from Azure Sentinel. Also, we can check Incidents Review to check all the violation and incident As we can see it is extremely easy to use Azure Sentinel to respond to security events threatening the health of our subscription


 


magdysalem_32-1611613204479.png


 


Summary


In this series, we talked about the importance of security. There are two aspects of security validations, credentials in the code, and Azure subscription security. 


We discussed CredScan tool and how we can use it automatically The credits can Tool has two flavors. Clients and server-side, the clients is a visual studio extension, which we can install on the developers’ machine. So, each time the developer builds the solution, they’ll get a list of warnings of the credentials in the coat. The Server side can be integrated into the continuous integration pipeline. So each time a bill kicks off, CredScan is going to look for credentials in the code.


 


 In the second blog, we talked about AzSK. This tool can be used to run security health checks for Azure subscriptions.


 


In the final blog, we talked about Azure Sentinel and talked about how we can provision it and how we can configure azure resources to send diagnosis logs to Azure Sentinel. We also talked about how to set an incident alert and how to configure a playbook to respond to the alert as an automated response for an incident.


 


Thank you for reading, I hope the information is useful to you. 

Experiencing Data Access Issue in Azure portal for Log Analytics – 01/25 – Resolved

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

Final Update: Monday, 25 January 2021 21:33 UTC

We’ve confirmed that all systems are back to normal with no customer impact as of 1/25, 20:25 UTC. Our logs show the incident started on 1/21, 20:20 UTC and that during the 4 days and 5 minutes that it took to resolve the issue, customers in the US Gov Virginia Region could have experienced data loss for the below data types:

HeartBeat
Perf
Security CEF
Security Events
Synapse

  • Root Cause: The failure was due to a backend configuration issue.
  • Incident Timeline: 4 days and 5 minutes – 1/21, 20:20 UTC through 1/25, 20:25 UTC
We understand that customers rely on Azure Log Analytics as a critical service and apologize for any impact this incident caused.

-Eric Singleton

Microsoft Learn for Educators

Microsoft Learn for Educators

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

Microsoft Learn for Educators takes the best of Microsoft Learn online learning paths and supporting instructor-led training materials into the classroom.

Higher education institutions, educators, and faculty members at colleges, universities, community colleges, polytechnics, and secondary schools can access Microsoft ready-to-teach curriculum and teaching materials aligned to industry-recognized Microsoft Certifications.

These certifications augment a student’s existing degree path and validate the skills needed to be successful across a variety of in-demand technical careers.



Demand for technical certifications is growing. For students who are looking to stand out in the job market, and the faculty and higher education institutions looking to support them, technical certifications can be a differentiator. For a student, adding a Microsoft Certification to their profile alongside artifacts from class projects demonstrates not only their learning from coursework, but also a commitment to keeping up with the evolving forefront of technology.



Learnedu.PNG


 


Microsoft Learn for Educators program benefits. Through this program we are offering educators & academic institutions many benefits, including:



  • Microsoft curriculum and teaching materials

  • Free Microsoft Certification practice exams

  • Free Microsoft Certification exams

  • Training program managers

  • Curriculum integration support

  • Microsoft Learn for Educators community

  • Data and insights reporting


For more details see this blog post: Microsoft Learn for Educators delivers cutting-edge instruction to students – Microsoft Tech Community

Protecting your DocuSign Agreements with Azure Sentinel

Protecting your DocuSign Agreements with Azure Sentinel

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

With the proliferation of cyberattacks continuing to grow every day, it’s essential to stay ahead of the challenges and mitigate risk. It is important for security teams to research trends, so that they can protect their environment from the persistent and ever-growing threats, phishing campaigns and other forms of cyberattacks.



DocuSign allows organizations to manage electronic agreements. As part of the DocuSign Agreement Cloud, DocuSign offers eSignature, a way to sign documents electronically on different devices. As your DocuSign use cases continue to grow, the DocuSign Monitor API can be a powerful tool to bolster the integrity of your systems, reinforce company policies and help assure your customers that their sensitive data is in good hands.



In this blog, we will cover the process to integrate Azure Sentinel with critical DocuSign security events to stay on top of signs of intrusion or suspicious activity. The steps below will demonstrate the process to collect for Azure Sentinel which uses an Azure Function to pull DocuSign security events using the DocuSign Monitor API and ingests them into an Azure Log Analytics workspace.


 


Collecting events from the DocuSign Monitor API


This section explains how to get the activity tracking information for your organization by calling the DocuSign Monitor API endpoint.


Architecture.png


You can get the activity tracking information for your organization by calling the DocuSign Monitor API endpoint:


https://<<ORG>>.docusign.net/api/v2.0/datasets/monitor/stream?cursor=={{cursorValue}}&limit={{queryLimit}}


 


Ex:


https://lens.docusign.net/api/v2.0/datasets/monitor/stream?cursor==&limit=1000


 


















Name



Description



cursor



A string query parameter that specifies the place in your monitoring data from which the request will begin gathering records. Your app can use cursor to keep its place while sifting through monitoring records in a way like how you might use a bookmark to keep your place while reading chapters of a book.
Whenever you successfully call the monitor API endpoint, the response will include an endCursor value which you can use to create the cursor for your next request, enabling you to chunk your downloads as you examine large numbers of event and alert records.
Calls that do not specify a cursor will begin retrieving records from the first event recorded.
Not required. Defaults to 0.



limit



An Int32 query parameter that specifies the maximum number of records (up to 2000) to be returned in the response.
Not required. Defaults to 1000.



When you call the above endpoint, you can supply two parameters, cursorValue and queryLimit, that determine the subset of the monitoring data that will be returned in response JSON.


After a successful call, a set of JSON event and alert records is returned, including an endCursor metadata property. 


API response example:


 


 


 

{
    "endCursor": "aa_637383858077494473_637383857323373872_1",
    "data": [
        {
            "timestamp": "2020-10-15T19:08:52.3373872Z",
            "eventId": "8a977c98-xxxx-xxxx-xxxx-44b8149a905d",
            "site": "DEMO",
            "accountId": "692934c6-xxxx-xxxx-xxxx-5b0741b5dd7f",
            "organizationId": "",
            "userId": "524faa2d-xxxx-xxxx-xxxx-072d88c7effc",
            "integratorKey": "QTES-f79957b2-xxxx-xxxx-xxxx-80e57adfbb8e",
            "userAgent": "Faraday v0.15.3",
            "userAgentClientInfo": {
                "browser": {
                    "family": "Other",
                    "version": {}
                },
                "device": {
                    "family": "Other",
                    "brand": "",
                    "model": ""
                },
                "os": {
                    "family": "Other",
                    "version": {}
                }
            },
            "ipAddress": "162.xxx.xx.1",
            "ipAddressLocation": {
                "latitude": xx.74,
                "longitude": -xx.99,
                "country": "US",
                "state": "Colorado",
                "city": "Denver"
            },
            "object": "Account",
            "action": "Updated",
            "property": "SecurityPolicy",
            "field": "RecipientAuthenticationSettings",
            "result": "Optional",
            "data": {}
        }
    ]
}

 


 


 


 


 














Name



Description



endCursor



A string value that specifies the place in your monitoring data from which your next request can begin to continue getting records data from the place this request ended.
Use the value of endCursor to begin your next query from this spot in your records.



 


Deploying the DocuSign connector


This section explains how to use the ARM template to deploy the data connector to ingest DocuSign security events into Azure Log Analytics Workspace


To access the ARM template, navigate to https://github.com/Azure/Azure-Sentinel/tree/master/DataConnectors/DocuSign-SecurityEvents



  1. Click the Deploy to Azure Button

  2. Enter values for the following parameters




    • “DocuSignOAuthAccessToken”: This is the DocuSign OAuth Token

    • “Workspace Id”: Azure Log Analytics Workspace Id​

    • “Workspace Key”: Azure Log Analytics Workspace Key

    • “CustomLogTableName”: Azure Log Analytics Custom Log Table Name

    • “Function Schedule”: The `TimerTrigger` makes it incredibly easy to have your functions executed on a schedule. The default **Time Interval** is set to pull the last ten (10) minutes of data.



Note: DocuSignOAuthAccessToken and Workspace Key values will be placed as “Secrets” in the docusignkv<<uniqueid>> Azure KeyVault


ARMTemplate.gif


 


 


For complete instructions, please refer to README.md


Security events that can be collected from DocuSign Monitor API


Once it has been deployed, the data connector will be able to collect the following events from your DocuSign organization:


Ex:



  • Account administrator added.

  • Account password rules updated.

  • Account user deleted.


Docusign_table.gif


The complete list of all events that can be collected from DocuSign can be found here


Example analytics rules using DocuSign event data


Once DocuSign security events are ingested into your Azure Sentinel Workspace, you can create a custom analytics rule with a scheduled query to help you discover threats and anomalous behaviors that may be present in your organization.


Below are some examples of analytics rules you could run against your ingested DocuSign data:


Rule #1:


Description: User fails six or more login attempts in an hour


 


 


 

DocuSignSecurityEvents_CL
| where TimeGenerated > ago(1h)
| where object_s == 'User'
| where action_s == 'Login'
| where field_s == 'Status'
| where result_s == 'Failed'
| summarize Attempts = count() by userId_s, accountId_g
| where Attempts >= 6

 


 


 


 


Rule #2:


Description: Admin initiates a bulk account export


 


 


 

DocuSignSecurityEvents_CL
| where TimeGenerated > ago(1h)
| where object_s == 'Organization'
| where action_s == 'Initiated'
| where property_s == 'BulkAccountsExport'

 


 


 


 


Rule #3:


Description: When a bulk user settings export is initiated


 


 


 


 

DocuSignSecurityEvents_CL
| where TimeGenerated > ago(1h)
| where object_s == 'Organization'
| where action_s == 'Initiated'
| where property_s == 'BulkUsersExport'

 


 


 


 


 


Summary


This post outline the key components that are necessary to ingest DocuSign security events to Azure Log Analytics using DocuSign Monitor API. The DocuSign security events data connector helps to protect your organization’s electronic agreements with round-the-clock activity tracking and provides near real-time visibility across your DocuSign organization operations which helps security teams to detect potential threats, investigate incidents and respond decisively. Try it out, and let us know what you think!


We will be continuing to develop and add custom analytics rules and hunting queries for DocuSign security event data over time so make sure you keep an eye on Azure Sentinel GitHub repo.  As always if you have your own ideas for queries or detections please feel free to contribute to the Azure Sentinel community.


 


With thanks to @Sarah_Young@Cristhofer Munoz and @Chi_Nguyen for their input into this blog post.

COVID Vaccine Health Bot – MidDay Café 02-01-2021

COVID Vaccine Health Bot – MidDay Café 02-01-2021

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

HLS Mid-Day Café3.pngJoin us Monday, 12 noon EST, for MidDay Café where Microsoft’s Gregory Lisiak will be covering the Microsoft COVID Vaccine Health Bot to assist organizations in implementing, and leveraging, the bot. Additionally, Microsoft’s Samantha BrownMark LitwinPete Anello, and Patrick Miller, will be joining me to bring you the latest in Microsoft News, Events, and more.


Mid-Day Café is a new, weekly, fast paced, live web series by the HLS Group. Join us each Monday at 12 noon eastern.


February 1st Lineup:



  • Welcome and Introductions.

  • Mid-Day Café News in 2!

  • Upcoming HLS Events in 1!

  • COVID Vaccine Health Bot featuring Gregory Lisiak.

  • Open Q&A

  • Wrap Up


How to join:



Thanks for visiting – Michael Gannotti   LinkedIn | Twitter


Michael GannottiMichael Gannotti