The last couple of years I was more focused on Security and Compliance-enablement in Microsoft Azure. This year I focused on Robustness. When running in Azure – like other distributed system environments – failures are real and retries are a common remedy to support robust applications. In the session I discussed the need and the mechanisms, with many examples in Azure.
Here is the talk description:
Fail and Retry
Does your application reach out to services or databases over a network. Do you assume that these calls always succeed? In this talk we will cover different reasons for failures and organize them into those that make sense to retry (e.g., “transient” failures) and those that don’t. Where retrying makes sense, we’ll cover some tools and techniques to handle retries automatically, sort out how to select appropriate retry parameters depending on the scenario (e.g., batch job vs. interactive UI with a user waiting), and consider how to test such scenarios (hint: there are some tools to help force transient errors). Planned examples will include C# in Azure, but open to demonstrating other languages and platforms. You can hit me up on Twitter to request a specific scenario (https://twitter.com/codingoutloud/status/1574138969134088192), though the concepts and patterns are generic.
Today I had the opportunity to speak at the Granite State Code Camp (#GSCC2021) in Manchester, NH. This was the first time I’ve given an in-person talk since the start of COVID and it was great to see so many smiling facing (even when partially obscured by a mask!).
Last year my focus was a more in-the-weeds talk called Running Azure Securely – which of these Azure security features are for me?. This year I stepped back a level and focused on Compliance. In the session I discussed security vs. compliance, the shared responsibility model, and touched on a few other features, but spent a good bit of time focused on what I am thinking about as the “Policy stack” where one can gather lots of insight about your workload’s compliance with technology controls indicated by various compliance standards – based on the Azure Policy capabilities, a pillar of governance, and rolled up and available from Azure Security Center Microsoft Defender for Cloud.
Azure Security Center as a brand is no more – it is part of a rebranding to Microsoft Defender for Cloud. I assume this renaming, announced at Ignite, is because it is a feature set that can span beyond Azure – for example, keeping an on on-premises resources and resources in non-Azure clouds like AWS.
The session was interactive (as preferred!) and many thanks to Kevin and Vishwas and the nice lady whose name I didn’t catch who I think worked for the college for help in overcoming technical limitations in the room I was speaking from.
Tonight I had the opportunity to speak at #VirtualBostonAzure to talk about raising the visibility of security signals in your environment by turning on your WAF. In demos the WAF available in Azure Front Door was used.
will check public DNS records for a CNAME, returning whatever it is mapped to, if anything.
In the above screenshot:
nothing returned from dig – this is before any DNS entry was created for the demo subdomain
a cascade of CNAMES are returned from dig – this is after a DNS entry was created for the demo subdomain – and it pointed at an Azure Web App — the cascade here includes my subdomain => an azurewebsites.net subdomain (bostonazuredemo.azurewebsites.net) => a second azurewebsites.net subdomain (waws-prod-dm1-139.sip….) => a cloudapp.net domain => and finally an IP address
a single CNAME is returned from dig – this is after the Azure Web App was deleted (), but the DNS subdomain entry (bostonazuredemo.azuresecurely.com) was left intact – creating a dangling subdomain at risk of being hijacked — anyone who registered bostonazuredemo.azurewebsites.net (and it was open for anyone) would automatically have bostonazuredemo.azuresecurely.com already wired up to it.
a cascade of CNAMES are returned from dig – but different than the first – this is after bostonazuredemo.azurewebsites.net was registered again, by a hacker, and bostonazuredemo.azuresecurely.com was hijacked
Azure offers thousands of security features. Some of them are easy to use and others are complicated. Some are free to use and some look really, really expensive. Which ones should I be using for my applications?
In this talk we’ll look at some ways to reason about which security controls you might want to apply and why. We’ll consider groups of Azure security features through a pragmatic lens of security best practices and defense-in-depth/breadth, but tempered by the reality that “more security” is not always the answer, but rather “what is the right security” for a situation. By the end of this talk you should have a better idea of the security feature set offered by Azure, why/when they might or might not be needed, and have discussed some ways to reason about how which are relevant you by helping you think about how to assess appropriately for multiple situations.
Do you have specific questions about the applicability of Azure security features already? Feel free to tweet your questions at Bill in advance to @codingoutloud and he’ll try to work answers to any questions into the talk in advance.
If you know your way around SQL Server, then you will find Azure SQL Database to be familiar territory. But some aspects are more familiar than others, which is especially true for security-related differences.
In this session we review the key differences around identity management and authentication (including multi-factor authentication), managing server credentials (or, even better, not needing to in some cases), how to audit logins (probably not what you expect), an overview of encryption and data masking options, and the supporting role of Azure Key Vault. We will also touch on compliance and disaster recovery to give the complete picture of powerful features you’ll definitely want to know about to protect your data.
This talk will cover relevant capabilities for both traditional Azure SQL Databases and the newer Azure SQL Managed Instances.
This talk assumes you are already familiar with SQL Server or another enterprise database.
On Tuesday July, 30, 2019 I had the opportunity to speak at North Boston Azure. The talk was part of a series on Running Azure Securely and was called Are all these Azure security features for me? and was not really a “talk” in that it was highly interactive. For those who attended, you will recall we filled in some slides collaboratively. Thus, they may not appear so polished for those of you who did not join live. Either way, please find the slides (“collaborative” and all) below.
This was an experimental approach for me and the feedback from the audience tells me it worked pretty well. The group at North Boston Azure was already knowledgeable and engaged, so hopefully made for a interesting experience for all involved (was certainly fun for me).
Ever try to figure out how to track who logged into your Azure SQL database? You checked all the usual ways you might handle that with a SQL Server database, but one-by-one find out they just don’t work. Here’s one way to do it.
To track who is logging into your Azure SQL database, enable auditing (here’s how to do that) with audit entries directed to an Azure storage blob. There are two ways to do this: at the database server level and at the individual database level. Either is fine, but for the example that follows, auditing is assumed to be at the db server level. The example query can be adjusted to work with auditing at the database level, but one of the two auditing options is definitely required to be on!
Run this query to find out all the principals (users) who have logged in so far today into your Azure SQL database.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The query might take a while time to run, depending on how much data you are traversing. In one of my test environments, it takes nearly 20 minutes. I am sure it is sensitive the amount of data you are logging, database activity, and maybe settings on your blob (not sure if premium storage is supported, but I’m not using it and didn’t test with it).
Note: There are other ways to accomplish this, but every way I know of requires use of Azure SQL auditing. In this post we pushed them to blobs, but other destinations are available. For example, you could send to Event Hubs for a more on-the-fly tracker.