This article is contributed. See the original author and article here.
|
We continue to expand the Azure Marketplace ecosystem. For this volume, 111 new offers successfully met the onboarding criteria and went live. See details of the new offers below: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This article is contributed. See the original author and article here.
In the past few months, we have worked on an improved integration of Microsoft Defender ATP alerts into Azure Sentinel. After an initial evaluation period, we are now ready to gradually roll out the new solution to all customers. The new integration will replace the current integration of MDATP alerts which is now in public preview (see details below). The changes will occur automatically on 3/8/2020 and require no configuration from customers.
Improved alert details and context
The new integration has significant advantages in improved details and context, which are meant to facilitate and expedite triage and investigation of Microsoft Defender ATP incidents in Azure Sentinel. The integration will provide a more detailed view of each alert and is designed to capture changes on alert status over time. The upgrades include increased visibility into investigation and response information from MDATP as well as a link to provide an easy pivot to see the alert in the source portal. Finally, more information on entities is provided in a more concise format so analysts can have a broader picture of the involved entities.
It is important to note that the new integration does make minor changes to the structure of alerts from Microsoft Defender ATP. A summary of the changes is presented below (table 1), and a full description of the changes, together with a sample alert, can be found in the attached file. Any scheduled rules that use one of the changed fields might be affected.
A new MDATP API
The integration is based on the newly released MDATP Alerts API. Details on the new API can be found here.
Improved discoverability of the Sentinel integration in MDATP
The Sentinel integration is now exposed in the Partner application section in Microsoft Defender ATP.
Additional Resources
Connecting Microsoft Defender ATP alerts to Sentinel – https://docs.microsoft.com/en-us/azure/sentinel/connect-microsoft-defender-advanced-threat-protection
Table 1 – summary of the alert schema changes
This table details the changes in the representation of MDATP alerts in the SecurityAlert table in Azure. The changes are in comparison to how MDATP alerts are now represented in Sentinel. Full description of the alert can be found in the attached file.
|
Description of Change |
Sample Alert Data |
|
Added: ExtendedProperties field. This field is an object containing the following details from MDATP: – MDATP category |
{ |
|
Replaced: ExtendedLinks field – The new AlertLink column displays a link to the MDATP portal for each alert. |
https://securitycenter.microsoft.com/alert/ |
|
Repurposed: AlertType field – shows the detection source (instead of a GUID of the alert in MDATP) |
Before: 360fdb3b-18a9-471b-9ad0-ad80a4cbcb00 |
|
Expanded: Entity field – More information on entities is surfaced. |
{ |
This article is contributed. See the original author and article here.
In the past few months, we have worked on an improved integration of Microsoft Defender ATP alerts into Azure Sentinel. After an initial evaluation period, we are now ready to gradually roll out the new solution to all customers. The new integration will replace the current integration of MDATP alerts which is now in public preview (see details below). The changes will occur automatically on the 3rd of August and require no configuration from customers.
Improved alert details and context
The new integration has significant advantages in improved details and context, which are meant to facilitate and expedite triage and investigation of Microsoft Defender ATP incidents in Azure Sentinel. The integration will provide a more detailed view of each alert and is designed to capture changes on alert status over time. The upgrades include increased visibility into investigation and response information from MDATP as well as a link to provide an easy pivot to see the alert in the source portal. Finally, more information on entities is provided in a more concise format so analysts can have a broader picture of the involved entities.
It is important to note that the new integration does make minor changes to the structure of alerts from Microsoft Defender ATP. A summary of the changes is presented below (table 1), and a full description of the changes, together with a sample alert, can be found in the attached file. Any scheduled rules that use one of the changed fields might be affected.
A new MDATP API
The integration is based on the newly released MDATP Alerts API. Details on the new API can be found here.
Improved discoverability of the Sentinel integration in MDATP
The Sentinel integration is now exposed in the Partner application section in Microsoft Defender ATP.
Additional Resources
Connecting Microsoft Defender ATP alerts to Sentinel – https://docs.microsoft.com/en-us/azure/sentinel/connect-microsoft-defender-advanced-threat-protection
MDATP API – https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/get-alerts
Table 1 – summary of the alert schema changes
This table details the changes in the representation of MDATP alerts in the SecurityAlert table in Azure. The changes are in comparison to how MDATP alerts are now represented in Sentinel. Full description of the alert can be found in the attached file.
|
Description of Change |
Sample Alert Data |
|
Added: ExtendedProperties field. This field is an object containing the following details from MDATP: – MDATP category |
{ |
|
Replaced: ExtendedLinks field – The new AlertLink column displays a link to the MDATP portal for each alert. |
https://securitycenter.microsoft.com/alert/ |
|
Repurposed: AlertType field – shows the detection source (instead of a GUID of the alert in MDATP) |
Before: 360fdb3b-18a9-471b-9ad0-ad80a4cbcb00 |
|
Expanded: Entity field – More information on entities is surfaced. |
{ |
This article is contributed. See the original author and article here.
Overview of Built-In RBAC roles in Azure API Management
Azure API Management relies on Azure Role-Based Access Control (RBAC) to enable fine-grained access management for API Management services and entities (for example, APIs and policies).
Reference Article: https://docs.microsoft.com/en-us/azure/api-management/api-management-role-based-access-control
As highlighted in the above article, Azure APIM provides a set of built-in RBAC roles for managing access to APIM services. These roles can be assigned at different scopes, which includes
The following table provides a brief description of the built-in roles currently offered by Azure APIM. These roles can be assigned via Azure portal or other tools, including Azure PowerShell, Azure CLI, and REST API
Custom RBAC roles in Azure APIM
If the default built-in roles do not meet specific user requirements, you can create custom RBAC roles for providing a more granular access to either APIM services or any of their sub-components.
Custom Roles in Azure RBAC: https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles
While creating a custom RBAC role, it is easier to follow the below approach in order to avoid complexities or discrepancies:
The ARM (Azure Resource Manager) Resource Provider Operations article contains the list of permissions that can be granted on APIM level.
Let us consider a few scenarios where we envision the usage of custom RBAC roles to enable fine-tuned access to APIM services or their components.
Scenario 1: Deny users from deleting APIM services
RBAC roles that enable having complete write access to APIM services (such as API Management Service Contributor role) have provision for performing all management operations on an APIM service.
To avoid intentional/unintentional deletion of APIM services by any user having write access other than the APIM Administrator, you can create the below custom RBAC role for denying the operation Microsoft.ApiManagement/service/delete to users.
In this example, let us use the Azure Portal for modifying the built-in RBAC role Contributor and create a custom role for denying APIM service deletion action for all services under a particular Azure subscription. This custom role would allow users to perform all default owner operations except deleting APIM services in the subscription.
Step 1:
Maneuver to the Access Control (IAM) blade of a sample APIM service on the Azure Portal and click on the Roles tab. This would display the list of roles that are available for assignment.
Step 2:
Search for the role you wish to clone (APIM Service Contributor in this case). At the end of the row, click the ellipsis (…) and then click Clone
Step 3: Configure the Basics section as follows
Step 4: Configure the Permissions section.
Retain the default permissions listed for this role.
Click on +Exclude Permissions and search for Microsoft API Management
Under Not Actions, select the permission ‘Delete: Delete API Management Service instance’ under Microsoft.ApiManagement/service on the succeeding Permissions page and click the Add button.
Step 5: Configure the Assignable Scopes section.
Delete the existing resource level scope. Click on +Add Assignable Scopes and set the scope to Subscription level. Click Add.
NOTE:
Hence, for a custom role where the assignable scope is configured to be at resource level, you could consider replacing it with a subscription or resource group level scope to prevent exhausting your custom role limit.
Constraints associated with custom roles can be found documented in the below article:
https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles#custom-role-limits
Step 6: In the JSON section, you could also Download your custom RBAC role in JSON format for future usage or reference.
Step 7: Review the custom RBAC role details in the Review + Create section and click on Create.
It may take a few minutes for the custom role to be created and displayed under the list of available roles.
In this scenario, the newly created custom role would be available for assignment under the Roles section on the subscription’s Access Control (IAM) blade since the assignable scope was set at subscription level during creation.
NOTE:
Step 8: Assign this custom role to a user. Any user having this role would be able to perform all the operations that are offered by default by the APIM Service Contributor role except deleting APIM services in the subscription.
Scenario 2: Deny users having Reader access from reading Product subscription keys
Let us consider the built-in APIM RBAC role ‘API Management Service Reader’ role for this scenario.
Users often have a misconception that only the APIM Administrators would be able to view the Product subscription keys on the Azure Portal. However, that is not the case.
The ability to read subscription keys from products (an action which is defined as Microsoft.ApiManagement/service/products/subscriptions/read) is allowed by default for users having the ‘API Management Service Reader Role’. Same is the case for navigating to the keys via APIs/subscriptions.
Hence, as a workaround, you can create a custom RBAC role in order to block the subscription keys – read action.
NOTE:
The action Microsoft.ApiManagement/service/users/keys/read does not correspond to reading subscription keys. The 2 actions are completely different.
Every user has two “secrets”, a primary and a secondary. These secrets are used to generate an encrypted SSO token that users can use to access the developer portal. These keys are not related to the subscription keys that users use to call the APIs. The /service/users/keys/read permission corresponds to the ability to read the user secrets, whereas the /service/products/subscriptions/read permission corresponds to reading subscription keys under products, which is allowed by default under the ‘API Management Service Reader’ role.
Additionally, the Microsoft.ApiManagement/service/users/subscriptions/read permission corresponds to the ability to read subscriptions associated with users via the “Users” blade on the Portal, which is also allowed by default under this role.
Here, we are creating and assigning a custom RBAC role using PowerShell for denying users having Read access over the APIM service from reading the subscription keys. Basically, this role denies users from performing the operation Microsoft.ApiManagement/service/products/subscriptions/read
The sample PowerShell script is as below:
$role = Get-AzRoleDefinition "API Management Service Reader Role"
$role.Id = $null
$role.Name = 'Deny reading subscription keys'
$role.Description = 'Denies users from reading product subscription keys'
$role.NotActions.Clear()
$role.NotActions.Add('Microsoft.ApiManagement/service/products/subscriptions/read')
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add('/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ApiManagement/service/<service name>')
New-AzRoleDefinition -Role $role
New-AzRoleAssignment -ObjectId <object ID of the user account> -RoleDefinitionName 'Deny reading subscription keys' -Scope '/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ApiManagement/service/<service name>'
Known Limitations
For example, consider a scenario where users on the Azure Portal should have read and write access only over APIs that are associated with a particular Product. For this, you can configure an RBAC role where the assignable scope has been set at “Product” level and add the desired Actions and NotActions.
Now, even if you add the permission “Microsoft.ApiManagement/service/apis/*” at product scope, when the user who is assigned this role attempts creating a new API inside this Product, the operation would still fail.
If a user needs to create a new API in the service (irrespective of whether it is inside the same Product), they should be able to read all APIs in the service and have write permissions granted at the APIM service scope instead of Product scope.
This is because, when a user attempts to create a new API or add a new version/revision for an existing API, there is a validation check that happens in the background to verify if there is any other API in the service which is using the same path that the user is attempting to create. If the user performing this operation does not have permissions to read all APIs in the service, the operation would fail.
Hence, you would have to grant the user the permission to read all APIs in the service (granted at the service scope).
For example, if user has configured streaming of APIM Diagnostic Logs to a Log Analytics Workspace and wishes to create a custom RBAC role only for viewing these diagnostic logs, it wouldn’t be possible to configure this role at the APIM scope. Since the log destination is Log Analytics, the permission has to be configured at the Log Analytics scope.
The APIM ARM operation “Microsoft.ApiManagement/service/apis/diagnostics/read” only controls access to the diagnostic configuration for the APIM service and not to the diagnostic telemetry that APIM streams to external resources such as Log Analytics/Application Insights, et cetera.
This is because there are no APIM ARM operations that support actions corresponding to “Microsoft.ApiManagement/service/apis/operations/test”.
However, this limitation can be overcome if the API is protected by a subscription key. When the permission “Microsoft.ApiManagement/service/subscriptions/read” is denied to a user, the user cannot test an API protected by a subscription key since they wouldn’t be able to retrieve the subscription key required for testing the API operation.
A JSON sample for creating this custom role can be found attached below:
{
"properties": {
"roleName": "Deny Testing APIs",
"description": "Deny Testing APIs",
"assignableScopes": [
"/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ApiManagement/service/<service name>"
],
"permissions": [
{
"actions": [],
"notActions": [
"Microsoft.ApiManagement/service/subscriptions/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}
APPENDIX
a) Azure Portal Tutorial – https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles-portal
b) PowerShell Tutorial – https://docs.microsoft.com/en-us/azure/role-based-access-control/tutorial-custom-role-powershell#create-a-custom-role
c) Azure CLI Tutorial – https://docs.microsoft.com/en-us/azure/role-based-access-control/tutorial-custom-role-cli
d) REST API Tutorial – https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles-rest
e) ARM Template Tutorial and Sample – https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles-template
This article is contributed. See the original author and article here.
How to Manage SharePoint via PowerShell – Part 1
Anthony Bartolo
How to Manage SharePoint via PowerShell – Part 2
Anthony Bartolo
ITOpsTalk: Traditional Failover Clustering in Azure
Pierre Roman
LearnTV: 92 & Pike w/ Jen Looper!
Chloe Condon
On this episode we chat with Jen Looper! 👩🏼?:school: Jen is a Cloud Advocate Lead on the Academic Team at Microsoft where she helps create curriculum, content, and experiences for educators, students, new learners looking to upskill in tech. We chat with Jen about Maya Mystery.
Welcome to part four of this blog series! So far, we have a Kafka single-node cluster with TLS encryption on top of which we configured different authentication modes (TLS and SASL SCRAM-SHA-512), defined users with the User Operator, connected to the cluster using CLI and Go clients and saw how easy it is to manage Kafka topics with the Topic Operator.
Using Graph Explorer Sample Data via REST
Todd Anglin
React For Beginners workshop
Aaron Powell
React is a JavaScript library for creating high-performing, maintainable JavaScript applications and brings a fresh approach to thinking into the JavaScript community.
Being a declarative user interface library that is un-opinionated about the rest of your application it is easy to reason about it is simpler to learn and master the basics than a full application framework like Angular. Also thanks to the simple nature of React, the patterns and lessons you will learn are transferable to other libraries and frameworks.
A Guide to Running a Virtual Workshop
Aaron Powell
Demystifying ARM Templates – Variables
Frank Boucher
Learning-ARM tutorials
Frank Boucher
In this repository you will find a series of tutorial paired with videos to guide you through learning the best practice about Azure Resource manager (ARM) template.
Each video is featured in the same page as the content. The videos are part of Azure DevOps – DevOps Lab show.
How to use Azure Go SDK to manage Azure Data Explorer clusters
Abhishek Gupta
Getting started with Azure Data Explorer using the Go SDK covered how to use the Azure Data Explorer Go SDK to ingest and query data from azure data explorer to ingest and query data. In this blog you will the Azure Go SDK to manage Azure Data Explorer clusters and databases.
This article is contributed. See the original author and article here.
Greetings!
We’re back with another mailbag, this time focusing on your common questions regarding Azure AD Identity Protection. Security is always top of mind and Identity Protection helps you strike a balance between the usability required for end users to be productive while protecting access to resources. We’ve got some really great questions from folks looking to improve the effectiveness of their alerts and to increase their overall security posture. We even have a sample script for you! I’ll let Sarah, Rohini and Mark take it away.
—–
Hey y’all, Mark back again for another mailbag. You’ve been asking some really great questions around Azure AD Identity Protection. So good, in fact, I’ve kept putting this off for an embarrassingly long time. Then I called in for some help from some excellent feature PMs Sarah Handler and Rohini Goyal.
Make sure that before you bulk dismiss users, you’ve already remediated them or determined that they’re not at risk. Then we have a GraphAPI call you can make to dismiss the user risk. We’ve put together a little sample script to help you with doing bulk dismissal.
We’ve provided a sample PowerShell script and examples to enumerate risky users, filter the results, and dismiss the risk for the collection.
We detect anonymizers in a few ways. For Tor, we continually update the list of Tor exit nodes. For VPNs, we use various third-party intelligence to determine whether an anonymizer has been used.
There are two ways to address false positives: giving feedback on false positive detections that occur and reducing the number of false positives that get generated. If while investigating risky sign-ins you find a detection to be a false positive, you should mark “confirm safe” on the risky sign-in. There are two ways to prevent false positives in Identity Protection. The first is to enable sign-in risk policies for your users. When a user is prompted for a sign-in risk policy with MFA and passes the MFA prompt, it gives feedback to the system that the legitimate user signed in and helps to familiarize the sign-in properties for future ones. The second is to mark common locations that you trust as trusted locations in Azure AD.
First, you want to make sure you’re putting in your public egress end points. This helps with our detection algorithms. We’ve recently increased the named locations to 195 named locations with 2,000 IP ranges per location. You can read more in our docs.
But we know that many times networking teams make changes and don’t notify the Azure AD Admins. It’s good to have a process to work through the Sign-In logs and look for IP ranges that are not part of your named locations and add those as well as remove IPs that no longer are your egress point.
Leaked credentials detection does not connect to Troy Hunt’s “Have I been Pwned”. Troy does an excellent job with his service correlating and collecting public dumps. Leaked credentials alerts take into account those public dumps as well as non-public dumps we call out in our docs, more info here. If you want to supplement the Azure AD leaked credentials alerting with other feeds, that is entirely up to you.
Leaked credentials will only detect on leaks going forward. When we find clear text username and passwords pairs, we don’t keep them. We process them through and delete them. We’ve updated our documentation to call this out and provided more info.
We hope you’ve found this post and this series to be helpful. For any questions you can reach us at AskAzureADBlog@microsoft.com , the Microsoft Forums and on Twitter @AzureAD , @MarkMorow, @Sue_Bohn, and @Alex_A_Simons
-Rohini Goyal, Sarah Handler and Mark Morowczynski
Recent Comments