Today, we launched a Microsoft Graph Security connector for Power BI along with a sample dashboard and template to enable rapid development of enterprise-wide security reports. Gain greater visibility into active threats and trends to help you better understand and manage security and risk.


You can now leverage the new connector included in the Power BI Desktop February 2019 update to:



This Power BI connector for Microsoft Graph reduces the time and resources needed to integrate multiple data sources, simplifying the creation of reports across security solutions. For further details on integrating with the Microsoft Graph Security API, learn about the API and access the schema.


Getting Started


Use this connector in a new or existing Power BI dashboard. This connector is included in the Power BI Desktop February 2019 update



  1. Your Azure Active Directory (AD) tenant administrator must first grant consent for the connector; follow the steps in the connector documentation.

  2. Select Get Data -> More… from the Home ribbon in Power BI Desktop after installing the Power BI Desktop February 2019 update.

  3. Select Online Services from the categories list.

  4. Select Microsoft Graph Security (Beta) and connect as illustrated below.  GetData.PNGMicrosoft Graph Security Power BI Connector

  5. Choose a Version (v1.0 or beta) and sign into Azure Active Directory, when prompted. Your user account needs to have Security Reader role permissions per the user delegated Microsoft Graph Security authorization requirements.

  6. Select the entity of choice and click load to display results as illustrated in the following diagram. Result.PNGResults

  7. You’re now ready to use the imported data in Power BI Desktop. Check out the Microsoft Graph Security Power BI connector documentation for advanced query options and other details.


User Scenarios


We’ve provided some examples below of reports created using the Microsoft Graph Security Power BI connector. A sample dashboard and template are also available for download from the Microsoft Graph Security GitHub repo. Feel free to slice and dice the information for each of the schema properties to build your own visualizations.


Visualize Alerts across different Security Products


You can now create a visual of security alerts originating from different security products deployed in your organization trending over a duration as per the diagram below.


Dashboard-Alerts_By_Security_providers_trend.pngVisualize Alerts across different Security Products


Visualize Top Threats Targeting your Organization


Create a visual, per the diagram below, to get the top threats that impact your organization by categorizing your security alerts across the different security products running in your organization. This in turn enables you to get a complete picture of what’s top of mind for your organizational security investigations.


Dashboard-Alerts_By_Security_categories_trend.pngVisualize Top Threats Targeting your OrganizationVisualize Top Targeted Users


Get a pictorial representation of users who were associated with the security alerts that originated from the different security products deployed in your organization per the following diagram to manage user risk information and potential top targeted users.


Dashboard-Alerts_By_Users_1.pngVisualize Top Targeted Users


What’s Next?


The Power BI dashboard and template using the Microsoft Graph Security Power BI connector can help jumpstart development of your custom reports. Build and contribute your own security templates and dashboards to the Microsoft Graph Security Power BI sample GitHub repo, following the contribution guidelines. Your contributions will be recognized via weekly blogposts on the Microsoft Security Graph tech community.


Try the Microsoft Graph Security connector and please share your feedback by filing a GitHub issue or by engaging on the Microsoft Security Graph API tech community or StackOverflow.


 


 




https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Gain-rich-insights-with-the-new-Microsoft-Graph-Security-Power/ba-p/334467

Today, we launched a Microsoft Graph Security connector for Power BI along with a sample dashboard and template to enable rapid development of enterprise-wide security reports. Gain greater visibility into active threats and trends to help you better understand and manage security and risk.


You can now leverage the new connector to:



This Power BI connector for Microsoft Graph reduces the time and resources needed to integrate multiple data sources, simplifying the creation of reports across security solutions. For further details on integrating with the Microsoft Graph Security API, learn about the API and access the schema.


Getting Started


Use this connector in a new or existing Power BI dashboard.



  1. Your Azure Active Directory (AD) tenant administrator must first grant consent for the connector; follow the steps in the connector documentation.

  2. Select Get Data -> More… from the Home ribbon in Power BI Desktop.

  3. Select Online Services from the categories list.

  4. Select Microsoft Graph Security (Beta) and connect as illustrated below.  GetData.PNGMicrosoft Graph Security Power BI Connector

  5. Choose a Version (v1.0 or beta) and sign into Azure Active Directory, when prompted. Your user account needs to have Security Reader role permissions per the user delegated Microsoft Graph Security authorization requirements.

  6. Select the entity of choice and click load to display results as illustrated in the following diagram. Result.PNGResults

  7. You’re now ready to use the imported data in Power BI Desktop. Check out the Microsoft Graph Security Power BI connector documentation for advanced query options and other details.


User Scenarios


We’ve provided some examples below of reports created using the Microsoft Graph Security Power BI connector. A sample dashboard and template are also available for download from the Microsoft Graph Security GitHub repo. Feel free to slice and dice the information for each of the schema properties to build your own visualizations.


Visualize Alerts across different Security Products


You can now create a visual of security alerts originating from different security products deployed in your organization trending over a duration as per the diagram below.


Dashboard-Alerts_By_Security_providers_trend.pngVisualize Alerts across different Security Products


Visualize Top Threats Targeting your Organization


Create a visual, per the diagram below, to get the top threats that impact your organization by categorizing your security alerts across the different security products running in your organization. This in turn enables you to get a complete picture of what’s top of mind for your organizational security investigations.


Dashboard-Alerts_By_Security_categories_trend.pngVisualize Top Threats Targeting your OrganizationVisualize Top Targeted Users


Get a pictorial representation of users who were associated with the security alerts that originated from the different security products deployed in your organization per the following diagram to manage user risk information and potential top targeted users.


Dashboard-Alerts_By_Users_1.pngVisualize Top Targeted Users


What’s Next?


The Power BI dashboard and template using the Microsoft Graph Security Power BI connector can help jumpstart development of your custom reports. Build and contribute your own security templates and dashboards to the Microsoft Graph Security Power BI sample GitHub repo, following the contribution guidelines. Your contributions will be recognized via weekly blogposts on the Microsoft Security Graph tech community.


Try the Microsoft Graph Security connector and please share your feedback by filing a GitHub issue or by engaging on the Microsoft Security Graph API tech community or StackOverflow.


 


 




https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Gain-rich-insights-with-the-new-Microsoft-Graph-Security-Power/ba-p/334467




Recently on the OWASP DevSlop Show, Teri Radichel and I performed a security assessment of the Azure implementation for DevSlop.co. We did it based on my previous blog post, Pentesting Azure — Thoughts on Security in Cloud Computing. You may want to read that article before you continue.


You can watch the video of the security assessment here. Subscribe to the DevSlop YouTube Channel for more awesome content like this!






“Because you can’t always blame Canada” — Teri and I causing trouble at a karaoke bar in Seattle



The first step to any PenTest is setting your Scope, Goals and Rules of Engagement for yourself and your client. You would restate this in your findings report, and you should always have a signed agreement from the client before you test anything.


 


Below is the scope of the testing and assessment that we did on the DevSlop show.


Scope: https://DevSlop.co, the DevSlopPatty Resource Group, the TANYA Azure Subscription (my subscription ID would be included in the doc). Nothing more.


Rules of engagement: Do not attack other tenants, or the Azure Service Fabric (that’s Microsoft’s underlying infrastructure that makes Azure). Some manual testing, some scanning, but mostly using Azure Security Center. Also: dates and times for testing.


Goals: Lock down DevSlop.co and my entire subscription.


Inform: We informed Azure that we were going to be performing security testing activities, and received acknowledgement before starting. **


 


** It is not mandatory that you inform Microsoft in advance of a PenTest, but for most other cloud providers you must ask permission. Informing Azure in advance of your testing takes 2 minutes, and may simplify your testing. Definitely worth doing.**






I’ve greatly improved my score since the test.



Executive summary:


Turn on all the security features in Azure Security Center (app whitelisting, file integrity monitoring), select a network security model and apply it (use network security groups), fix your VM security misconfigurations and keep patching it, address the 2 database VA (Vulnerability Assessment scan) findings, and consider getting a WAF (Web Application Firewall).


 


Risk Summary:


This Azure implementation (application + network + infrastructure) is very secure from an outsider-threat, as the application has had regular security testing and is using only known-to-be-secure and up to date components and frameworks. The subscription itself is also very secure from outside threats, thanks to the usage of Azure Security Center, a security policy, and the tight controls over subscription Access (MFA+ Difficult password + excellent password hygiene).


 


This system is not very safe from an insider-threat, assuming the malicious actor could gain access to the subscription. As only this subscription, not the “top level subscription”, was in scope, this was not investigated.


 


If the application was compromised it appears that the threat protection could potentially stop some types of attacks (SQL Server or Storage attacks only), and report on the damage after, however the protections against malicious attacks is not as substantial as it could be; multiple tools would be better.


Ifyou want to learn about about what we did to get these results, read the previous article: Pentesting Azure — Thoughts on Security in Cloud Computing. If you prefer to see what we did and follow along with us, watch the video. Better yet: do both.


 


PenTest Report — The Findings


A “+” indicates a pass, while a “X” indicates a fail of the test. Multiple “+” were used when a defense offers protection in multiple ways.


 



  1. Azure Security Centre (ASC) is turned on, with the default security policy.++

  2. MFA (Multi-Factor Authentication) is enabled for subscription access, use of a 64-bit random character that is saved into a password manager is one of the factors, the other is Microsoft’s Authenticator app, which requires not only physical access to and unlocking of a second device, it also requires a finger print. It could be argued that 3 factor auth is being used. +++

  3. ASC has 100% coverage of all subscriptions that were in scope of this assessment. +

  4. TANYA subscription was *not* compliant with the Azure Policy, earning a secure score of 340/580. (points are removed for each item below)

  5. JIT was enabled on the one VM in the subscription, properly configured +

  6. Threat Protection was enabled on all possible resources, properly configured. +

  7. Regularly VAs are enabled and schedule for the one database (+), however the database is not in compliance with VA results (X).

  8. There is no network security plan or model in place. X

  9. There are no Network Security Groups (NSGs). X

  10. Adaptive Application Controls (Application Whitelisting) is not enabled. X

  11. File Integrity Monitoring is not enabled. X

  12. DevSlop.co is not protected by a WAF (web app fire wall). X

  13. DevSlop.co forces HTTPS only on the app service. +

  14. There are no other security tools installed, such as IPS/IDS (intrusion prevention and detection systems), SIEM, or any other products or tools. X


Score: 10/17






No one outside of the DevSlop project team has permission to do testing on our site, DevSlop.co. If you want to test it, you must reach out to us and *ask permission*.



Database Specific Findings:



  1. Firewall rules not restrictive enough/non-existant X

  2. Using DB Owner privilege for an app that definitely does not require it (apply least privilege) X

  3. Sensitive data columns are not labelled properly X

  4. Regular VAs configured +

  5. Threat Protection & Detection Enabled +

  6. JIT enabled +

  7. Auditing and logging enabled +

  8. Database not internet accessible. +


5/8


 


Compute-Specific Findings (on one single VM):



  1. Missing disc encryption on server X

  2. 66 Critical security misconfigurations X

  3. 28 Warning security misconfigurations X

  4. JIT Configured +


1/4 (note: it does not list all the things we did correctly in this section)










You may think from this report that the security of the DevSlop.co Azure implementation (network + app + infrastructure) is not very good, but it’s actually not that bad at all. This report is aiming for perfection, and we are actually doing “okay”, especially considering our app doesn’t carry any real-world value. This is definitely something that would require an in-depth discussion on risk to explain further; perhaps a future blog post.


 


If you want to know more about Teri Radichel and cloud security you should read her blog, or hire her. You can also see her on the conference circuit at events such as B-Sides Vancouver in March, 2019 (I  will be there too!).










Please follow me on Twitter, on LinkedIn, and subscribe to this blog, watch the DevSlop show on Mixer, Twitch or subscribe and watch the reruns on YouTube. Thanks for reading!


 


** Special thanks to @sigje and Teri for helping with this post. They both have great blogs that you should definitely follow. I do.







https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Pentesting-Azure-The-Report/ba-p/333459