Customer Questions about Azure Security

Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability, and compliance on the Microsoft Cloud Platform. Hey everybody, welcome to episode 25. We have a full house this week. It's myself, Gladys, Mark, and Sarah. We also have a special guest, Chuck Enstall, who's here to talk to us about some of the common questions he gets from customers relating to Azure Security. But before we get to Chuck,

let's take a look at the news. Mark, do you want to kick things off? Yeah, just starting off, there's an expansion of our PCI DSS certification. We've got the link in there. I'm not a huge person that's detailed into the PCI DSS certs, but they did expand the scope of it. The next one that we've got is, there's a report that I put out there, and I got a link to the blog that describes it. We're definitely starting to see an increase in the firmware layer attacks.

Like every piece of software, there's vulnerabilities and all the joy of that. We wanted to make sure that folks were there. It's a nice awareness piece there, and also talks a little bit about how we focus on that with our secured core capabilities within Windows. Next one is, obviously, there's been a fairly decent impact from the Exchange vulnerabilities that were published not too long ago.

Our Dart team actually recorded our detection response team that does in-center response with customers, recorded really nice overview of the attacks and how they work and what to do about it. Wanted to make sure that you all saw that YouTube video is a big one. From the things that I'm working on, we're starting to take a look at the Azure Security benchmarks and what are the things we can do to improve it. I would love to get any feedback at me up on LinkedIn or Twitter.

If there's anything that you're looking for in particular. We haven't really locked on the specifics plan yet, but we're thinking about through a shared responsibility model, we've gotten a decent amount of feedback of, okay, who does what, how much this is Microsoft, how much is this, is the enterprise identity or network, enterprise-wide teams across workloads, and how much of this security best practice would land on a specific workload owner.

We're thinking about that and how we represent that. Love to get some feedback from you all on that one. The next one is the Cyber Reference Architecture, the very big complicated diagram that has all Microsoft's cyber capabilities or at least the main ones. We can't fit them all on it anymore. It's getting ready to come out. It can't give you a specific date, but it should be a matter of weeks from the recording this podcast. We'll be talking about that, I'm sure as it gets even closer.

But wanted to give you all heads up that that updated version is coming. I continually get questions on LinkedIn and Twitter and whatnot for that.

Then the last one is a little bit more for, it illustrates one of the things that we're thinking about as we're working on some DevSecOps guidance, is we're starting to appreciate how important it is when you do DevSecOps to look at the world through the lens of developers, security people, and operations, because each has a very important goal in an application. One is that it meets the business needs for purpose, it actually enables the organization.

That's the Dev world representing the business, the ops is the reliability, stability, maintainability elements. Then security is that it stays safe and it meets all those security assurances of confidential integrity availability. We're really thinking about that need to merge the cultures. The last one was just an article that was a really interesting viewpoint that showed what the world looks like if you let the developers win every argument.

The world is equally as dystopian as if you let the security people win every argument as well. But it was just an interesting insight there that I found interesting. So I thought that showed up with the group. Hello everyone. Besides Microsoft releasing an enormous amount of security information as part of the Ninja training, which I have mentioned in previous podcasts, we have been expanding the learning path we provide within the Microsoft learning site. That's www.microsoft.com.

Since during our last podcast, Michael went through a high level view of the site capabilities. I wanted to quickly mention the SC-200 training provided within that site. He has eight parts focusing on different security solution. That includes Azure Sentinel, Azure Security Center, Azure Defender for Endpoint and others.

So be sure to check out this material, as it's an excellent resource for those of you that want to start in the IT security field, or even expand further knowledge to support Cloud security services. In addition, last year, Microsoft opened many learning paths in LinkedIn learning to be delivered for free until June 2021. Well, Microsoft is extending access to those learning path until NO 2021. So make sure to add those as part of your learning as well.

Another thing that I wanted to share is that EDR support for Windows 2019 has been added to Microsoft Defender for Endpoint. This means that now the Windows 2019 VMs can have this capability enabled in that, which extends the capabilities that are included within Azure Defender. So make sure to enable these if you have the service already.

Also, as part of identity, which I'm going to share a couple of news in here, customers can now quickly configure single sign-on and user provisioning to AWS single sign-on using the Azure AD app gallery. This means that now AWS single sign-on can be quickly connected to Azure AD for centralized access management of AWS resources. Of course, it means that the end users can sign into AWS single sign-on using the Azure AD credentials to access all their assigned AWS resources.

The next identity related news is that the AD Federation Services Activity and Inside Report is now available in the Azure portal, which lets customer quickly identify which applications are capable of being upgraded to Azure AD. It assesses all the AD application for compatibility with Azure AD, checks for any issues, and gives guidance on preparing individual application for migration to Azure AD. Finally, I wanted to talk about the new Azure AD logging that has been enabled or is on preview.

This include provision and alerts for service principle, extending some of the logs are extending the ADFS logging, and even providing some sign-in alerts related to MFF. A whole bunch of stuff took my interest this week. The first one is GitHub Advanced Security is now available in beta. The way I looked at this when I saw it is it reminds me of Azure Security Center, but for your code.

If you've got code in GitHub, it will actually scan over your repos looking for common issues, and it will give you essentially a dashboard, which gives you a nice idea of improving your security, what issues are being found, and so on. I absolutely love that. They've now added the ability to do scanning for secrets in private repos.

This is nice because we hear on more than one occasion where someone's embedded a credential and then uses that credential during normal operations, and then they happen to check that credential into GitHub. Now the attackers have access to the credential. That's also available in the GitHub Advanced Security. Another topic that is related to GitHub is I think we call CodeQL. It's a code query language.

The best way of looking at CodeQL is a way of querying code, looking for specific kinds of patterns, as you would say a SQL query, but for code. What we've done is we've open sourced the CodeQL queries that are used to hunt for salariegate type activity. This is really cool. I'm a huge fan of CodeQL.

The best way I think of thinking about CodeQL is, again, imagine SQL, but for querying code and querying kinds of constructs in code, like if you see this kind of data in this kind of code construct, then we may have a SQL injection vulnerability here, those kinds of things. The other nice thing about CodeQL is it really democratizes these rules that are used for finding new classes of vulnerability.

We have, upon GitHub, a plethora of rules that have been written by other people for finding specific kinds of vulnerabilities. So if you're a developer or you run a development shop or you're in charge of a development team, you really should spend some time looking at CodeQL in GitHub. Another thing that took my interest this week was we now have, in IoT Hub, we've made some security changes. We are now able to sort of fine tune the way some of your IP filters work.

You must add your computer's IP address into the allow list now to make it work correctly so that you can actually access it through the portal. Historically, that wasn't the case. And also, we've made some pretty significant networking changes, running IoT Hub using Azure portal, using Client Store, and the same VNet, as an IoT Hub private link. So do be aware of some of the networking changes that have come down the pike for IoT Hub.

For some reason, we seem to be getting a lot of changes, updates in SQL and Synapse. One of the ones that I noticed this week was dynamic data masking granular permissions. Dynamic data masking allows you to mask out certain kinds of sensitive data. It's not encryption. It's not really an air quotes security control, but it's there certainly to help accidental disclosure of sensitive data.

So for example, in the US with a social security number, you could tell SQL Server to say, when data from this column is returned, it's a social security number. So mask out all the characters except the last four digits. We now have the ability to set the policies at a much more granular level. So you could set the actual permissions and the policies that are in place right down to, at the schema level, at the table level, and right down to the column level as well.

So nice to see some fine tuning of that ability. For media services, we've added a whole bunch of new security features there as well, including things like customer managed key support and managed identities. So again, this is one of the three main areas or two examples of three of the main areas that we see happening across the board, increased use of managed identities and increased use of support for customer managed keys.

So media services now has the ability to have customer managed keys and managed identities. Next one is in public preview, as your event grid now supports system assigned managed identities. So another feature that I saw was in public preview, as your event grid now has support for system assigned managed identities. What you can do is you can put a managed identity on a publisher.

So when it publishes events, let's say it pushes those events out to a storage account, you could have a policy, an RBAC policy on the storage account that says, that event grid can write to me and nothing else or perhaps, you know, something reading the events. But ultimately, you've got a fantastic ability here to restrict who can write to the likes of say, service bus or event hubs, blob storage and as your storage here.

This next one is not really truly security, but I was really excited to see it. We have a thing called as your communication services, which lets you do things like sending and receiving text messages, phone calls and so on. You know, is it a security feature? No. But it really caught my attention because I didn't even know this is coming down the pike. Apparently it's been in preview for some time, but I didn't even know it's coming down the pike.

But for people who wanted to build custom sort of two factor authentication mechanisms, not that you should, but I'm just saying if you wanted to, you could certainly use a service like this. Back to the SQL topic, some papers I noticed this last couple of weeks. One is called security delegation of authority. And another one is the intro into security principles in the context of database systems. This is really cool. Here's why this is so cool. SQL databases have their own security model.

It's not the Azure security model. It's not a Windows security model. It's not a Linux security model. They're different models and there are good reasons for that. And so when you got this sort of boundary between Azure security and SQL security, you sort of had to understand how to map one to the other and how to do away with that kind of impedance mismatch. And we've been trying over the last few years to really help in that area. So this document is absolutely fantastic.

It talks about basically how SQL database security models work. And I think once you understand that, it becomes a lot easier to map on to sort of how to use Azure security to complement SQL security as well. And the last one is Azure Active Directory only authentication for Azure SQL. So it turns out there's a little story behind this. The news about this coming out actually leaked a little bit early and people were running around trying to turn this feature on. And they couldn't find it.

And the reason was because it wasn't available yet. But it's coming out in April. So what this allows you to do is in Azure SQL DB, you can go in, you can say, use Azure Active Directory for all authentication from this point forward. No more SQL authentication. Very similar to the on-prem ability where we can say use Windows authentication only. But in this case, we're using Azure Active Directory authentication only.

That is absolutely fantastic to see because again, it gets rid of one of those sort of legacy security things that we have as a holdout from the old days of SQL security. And that's all I have. OK, so my God, loads of stuff there. So let me do a few. So of course, it would be wrong for me not to talk about something Azure Monitor E. So ExpressRoute monitoring in Azure Monitor has now gone GA.

So what that is, is if you're using Azure ExpressRoute, you can now look at the metrics and the config details of ExpressRoute just through Azure Monitor. So it means you can see things like peerings, connections and gateways. You can see the health status. You can see important circuit metrics like availability and throughput, any packet drops and other bits and bobs like that, which of course is important if you are connecting your on-premise to Azure through an ExpressRoute.

Another thing that's gone GA is networking for key vault references on Windows in App Service and Azure Functions. So Windows apps that have virtual network integrations can now access restricted network vaults, which is really cool because of course, the more we can restrict access to secrets, the better. And this is just for Windows at the moment, but it is coming for Linux very soon. There is an issue at the moment, literally at the point of us recording this.

So hopefully, if you're listening to this in the future, this will be gone. But I guess I should mention it because it's in the news update. There is a known issue which prevents versionless references from automatically updating when they're behind network restrictions. It is going to be fixed soon. We're aware of it, but it is recommended just at the moment not to use both those features at the same time.

But hopefully by the time, unless you're super keen and you listen to this podcast the day it comes out, which I hope at least some of you do, then hopefully we'll affix that, but just a note. Next one is another GA announcement. Encryption scopes in Azure Storage are now generally available. So they allow you to provision multiple encryption keys in a storage account for blobs. It used to be that you could only use one account scoped encryption key.

And the last thing is Azure Private Link for Azure Cash for Redis is in GA now. So Private Link, as you may know from all the other products that also have Private Link, it provides private connectivity from a virtual network into your cash instance. By the way, I know some people say cash in my part of the world, I say cash. But what it means is that you can actually access the cash without going, putting your data through the public internet.

So what this means specifically for this one is that you can connect to an Azure Cash for Redis from a virtual network. And now that's often a preference for customers to just not have things go out to the public internet. Some customers may need that for regulatory purposes or just to meet their internal security standards. So again, if you've been waiting for that, here it is. And that is all of my news for this week. All right, now we've got the news out of the way.

Let's turn our attention to our guest. This week we have Chuck Enstall, who is a Azure Security Architect. He's a global black belt, and he's here to talk to us about some of the questions that he's seen from customers and some of the areas of perhaps a friction or areas where there may be a little bit of a knowledge gap. So before we get stuck into it, Chuck, do you want to give us a little bit of a background on yourself, how long have you been in Microsoft, what you do?

Thanks, Michael, for having me. I appreciate it. So yeah, I've been in Microsoft for a little over 13 years in total. I'm a retread. So started in 2005, left, spent a number of years at Apple, and then came back into one of the earlier CSA roles when Azure was still in incubation. Always had a focus on security and then jumped into the Azure Security Architect role. Myself and my colleague Tom Quinn were, I think, the first two guys.

Tom was there before me kind of doing this on truly a global scale. And then we started to add some folks as the field realized this was a pretty valuable role. And so in fact, Marcus, I most was one of my interviewers. So I really had to slide some cash under the table in order to get to this role with Mark. So but yeah, so I've always been in a technical pre-sales role at Microsoft, mostly focused around Windows Server and everything that goes along with it.

So domain services, remote desktop services, certificate services, things like that. But yeah, I've been doing this role now since probably 2018. One of the things that we mentioned is this notion of global black belt. So so what is a global black belt and what is your role? Yeah, so great question. It's it's actually a title, a moniker that we at least maybe I typically don't use with customers because it has very little relevance or context.

But the the understanding is that you're kind of a resource of last resort, potentially someone who if there is no one else to ask or have a question answered. Let's let's go to the global black belt. So we're a point of escalation from the field and we kind of sit in between our engineering team. So the CXP CXC, you know, the product groups themselves and try to keep some of that constant incoming flak off of their plates.

So that we can answer that and go deep and potentially across a number of products, features, solutions that Microsoft offers. So we're not looking at it in a siloed way. And we're looking at things that are in Azure, things that are on premises, clients, server, both things that are in other clouds. So we kind of help tie it all together with the customer. The only thing we don't do is anything really hands on.

We're not consultants that we we offer that up for either the our CEs or MCS or something like that or or a qualified partner to actually do the finish the implementation or CXC. I really had to kick this off with a question. I want to get your view on it because I see this all the time with customers across the entire spectrum. And that is that there's often quite siloed.

And you sort of mentioned that we're quite siloed areas of expertise like we'll be designing something with a customer going through the business requirements and so on. And then we'll get the security guys in and say, yeah, yeah, yeah, you know, we need to do this that and the other. And then most then so hard, but we can't do this because we need the networking. We need the networking folks and then the networking folks say, well, we need the identity folks.

So I mean, do you see this as well where there's almost this almost these walls between security, networking and identity? I mean, do you see this getting better or is this just something we're going to have to live with for a while? So it's a great question. And I see it every week. It has gotten better. If you if you look back decades, it was very siloed. It has gotten better if there's one organization inside of a company that is siloed more than any others. It oftentimes is security.

We'll go in and we'll work with an organization trying to remove some blockers, you know, increase their agility, you know, velocity, whatever you'd like to call it. And so you look around and they've created a cloud center of excellence or whatever they call it. And you've got all the appropriate stakeholders from, you know, so application, architects, storage folks, networking. And then where's the security folks? We never invite them because they're just, you know, crotchety there.

They always just say, no, they don't understand cloud. And and that's really a miss. And then you say, well, here is probably why we're having these issues, right? Why security is saying no. So yeah, I do see that silo. It's still going on when we do come in and have conversations about a security topic.

If we're, you know, we start to ask ahead of time, make sure the account team invites all the appropriate stakeholders because we don't want to get five, 10, 15 minutes in and we start talking about something. And then it moves to identity and they go, hold on, Chuck. We don't have our identity folks on the call. Ouch. Well, why? I mean, it's no longer that siloed. It is something that's very fluid. We have to have all those folks together in order to really make progress.

And it gets to a point where you can't say, well, that's really not what I do. There's no longer a hard, clear cut, my job, not my job type of thing. And we see that in organizations still. It is getting better. But we also see that oftentimes in inside of Microsoft. So I think it is getting better. We're striving to do that internally. We're we're actually helping our customers kind of understand that.

Invite the network folks, invite the identity folks, even though if you don't think they're required, it's good for them to know, right? Kind of cross train. The same thing, invite the security folks early and often. They're going to become your best friends. It's going to be easier for them to sign off and produce a risk report on a particular application if they're involved and they feel they're a stakeholder. So it is still a siloed approach. I think it is getting better.

I think it's just going to take some time. Yeah. And the way the way that I like to think about this is like, you know, I feel like we're redrawing the lines. There will be some new lines, right? Hopefully not as siloed as we've been. But like the lines that were we really haven't questioned them since like, I don't know, the late 90s, early 2000s, when enterprise computing, you know, kind of took over from a mainframe and desktop.

Like I feel like we're going back and questioning stuff that was being settled when Active Directory came around. So I'm curious, Chuck, like as as organizations kind of embark on DevOps, which is emerging of the two cultures and and DevSecOps, which is emerging of the three to make sure it's, you know, reliable, it's it's performant and meets the business requirements and it's secure. Like, are you seeing progress within there? Or is it, you know, still too early to tell?

I'm kind of curious how how that plays out and also the sort of cloud ops versus, you know, on-prem ops as cloud teams kind of bring in their own security people. So I'm curious what you're seeing in those spaces, in the emerging space. So Mark, that is an excellent point. And there's still some confusion around that. I think largely because security folks, networking people, they've never considered themselves any sort of a developer or scripter or automation person, right?

That was for IT operations or development. Yeah, that's that's another one of those, I think pillars that really needs to be understood at some fundamental level, that this idea of being able to write a simple script. And that's PowerShell, Azure CLI, whatever it is, Bash script, you need to have some competency there. And that's going to make things better all around. And by the way, I love to use the word sec DevOps. I like to put security first. It's more important.

But that really I've given up on that. I just like to think and I'm like, it is going secure DevOps, but I'm now dev sec ops. Yeah, I'm just trying to bring it back. But but I think that's right, it's very, very important that security folks and what we're seeing, interestingly enough, is I think some of the folks that are instant response focus, sock professionals are kind of ahead of that curve in many ways. But they're kind of after the fact they're consumers of this data.

And then they're writing all these scripts to kind of do correlations. What we'd like to see is the security architects really get into this process and integrate into those teams so that they can do that. Dev sec ops process and learn from the developers learn from the IT operations. And we have to break down those walls of silos even further so that we do get good across domain, SME sharing any of subject matter experts sharing these capabilities. Hey, let me show you how to do this.

Oh, good. Let me show you how to do this. And that's when things really start to fire on all cylinders and start to move forward. We do have, I think, much more work to go when it comes there, especially just companies trying to even decide on a standardization from an automation perspective. And I think Terraform is really kind of leading there. But we've got folks using Ansible and Chef and Puppet and Arm. And it's great that they're doing it.

But even that starts to sometimes seem overwhelming to some of these security folks and networking folks that say, listen, you know, I'm too old for this. My career does this really matter. So I think part of our job at Microsoft is to really show them. Yeah, this can make your job easier. It can make it better. You can focus on higher order processes. So I love that call out, Mark. Chuck, how does compliance fit into all of this? Compliance is a big word, right?

Means different things to different people. But what do you get asked about? Well, thanks for that question, Sarah. And by the way, good to talk with you again. It's been a month or so. I know. I know. Those of you who don't know, Chuck, and I was also one of Chuck's colleagues. I was, I think, the fourth person with David Sanchez, who's been on the podcast before. Chuck's been to visit me down on the side of the world.

You were very surprised when you asked for nonfat milk and they said, we have milk. Yes, I was embarrassing. And thank you for being my cultural attache to that. And speaking of David, it was more embarrassing. I first met David prior to him joining the global black belt team. And we were in Madrid. And he took me to a Starbucks. And I said, how do you ask them for nonfat milk? And he kind of looked at me like, I don't think there is a Spanish word for nonfat milk, right?

So even more embarrassing, I've learned. I just drink coffee black now. So again, Sarah, thanks for that question. Compliance is a big topic. It really has a number of different connotations, depending on who you ask. I think what folks are looking for is guidance around being able to comport with numerous different compliance frameworks. So that could be PCI DSS. It could be HIPAA high-trust and high-tech, GDPR, FedRAMP. There's a number of them.

And I think it's important to really address those. And it doesn't mean that you have to be able to be a certified auditor on PCI DSS, go down to the NTH degree on the details, but absolutely work with organizations to make sure that you can show them that we have an adequate amount of controls inside of the platform that can help them obtain those objectives. And then, of course, bring in additional resources.

But just it's a dialogue that we have to enter into with organizations across the board and ongoing a conversation. So it's never going to be, hey, I've answered this question and we should be go. Now you're always going to be compliant.

The nature of Cloud itself with the shared responsibilities matrix makes it imperative for Microsoft to work very closely with organizations across any of those compliance frameworks and make sure that we're, again, constantly staying in touch because products change inside of Azure at the features that capabilities might shift. New things come up, which we just talked about some of those at the top of the podcast. And then, of course, the frameworks themselves change. So it's a great question.

It's something I think we need to give even more credence to and have more discussions with customers around compliance in general. Yeah, I want to concur with something you said about you don't have to be an expert in compliance. One thing that spent a lot of time with customers is building threat models for them. So we take a solution and we look at the threats and the mitigations and so on. And those mitigations map quite nicely to the technical controls in many compliance programs.

I just work with the customers just recently and we were talking about PCI DSS and then I just sort of talked about GDPR in general and HIPAA and high trust and high tech, as you mentioned, just in general, just in passing. One of the people on the call said, why are we learning about compliance? Why do I need to know about compliance? My response was you need to understand at least what the compliance programs are and what the implications are of these compliance programs.

I don't think you need to be a compliance alpha geek. Leave that to the compliance people and the legal people. But you need to at least understand the implications that GDPR may have on your solution or the implications that FedRent may have on your solution or the implications that PCI DSS 3.2.1 may have on your solution. You have to be mindful of these, especially if you are one of the lead architects working on the design of a system. Absolutely agree.

One of the, I wouldn't even go farther than that, speaking of threat modeling against a compliance framework. That's the number one issue that drives me in this particular role is that I get to learn. I have the opportunity to learn something brand new every single day. I learn it during interactions with our customers, with my colleagues. The field, the security field, the cloud field technology is just almost seems infinitely broad to me that I get excited.

I said, what am I going to learn new today? And in the process, maybe help someone else learn something. So this idea of, hey, I really don't know compliance and boy, there's another opportunity to get into a field that maybe even five years ago, you would not have had that opportunity to do so. Now it's all coming together. So I love it. I have a big question for you. Let's ask about how they should segregate between say their tenant, their subscription and their resource groups.

What are the general best practices that you advise customers to do there? Because big question. Oh, and how many do they need? Again, big question and may depend on the customer. But what's your general advice to anyone listening who might be trying to sort out their architecture in Azure from a security perspective and segregation perspective? Yeah. So it is a great question. And it's actually a pretty heavy topic.

It's maybe more organizational, legal things than it is technological, although there are aspects to it. So my general guidance to every company is one instance of Azure Active Directory. So kind of that one ring to rule them all. And sometimes we, I get involved with an organization that's maybe farther down the path and maybe they're suffering because of decisions they'd made early on. And we have to unwind some of that stuff. Or what's our go forward path?

If we can get in front of with some folks that are still in their infancy and using cloud in Azure or even right at the get go, then yeah, we're going to say one instance of Azure Active Directory. And what we mean by that is for production test, pre-production, non-prod, dev, whatever you want to call it, everything that's running in Azure, one directory infrastructure.

And that's atypical from what folks have done on premises where we used to have, here's my non-prod domain, here's my production domain. And that was fine, but we don't have this concept of domains inside of Azure Active Directory. And we've seen, oftentimes folks would do different synchronizations, right? They'd have a directory synchronization from non-prod into a tenant and one from prod into a tenant. And it really does bad things.

Operationally from a cost perspective, from a security visibility, we start to have these identity spread out all over the place. It's confusing and confounding to the end users. So we want all that to go into one directory. And Sarah, as you've heard me say to customers where we've tag-teamed, it would need to be a constitutional amendment to add another directory, right? Are there good reasons for it? Sure, but let's make sure they're really good.

So let's keep with that one directory so that my identity in the cloud is a single, at a single point. And then I can use very, very strong role-based access controls to work toward that kind of zero trust architecture, that least privilege access model based on that single identity. I have non-repudiation, less things to worry about, right? Less reduce the attack service. There's a lot of benefits to a single directory.

And then as you convince folks to say, this is the way, maybe that's kind of a Mandalorian thing, but this is the way, then everything else starts to kind of fall into place. So now I have one root management group to which I kind of fix Azure policy and policy initiatives, role assignments, things like that, that can then be inherited in the kind of nested inheritance model that we have with management groups. Things start to kind of get easier at that perspective. And then the subscriptions.

I know we've seen a lot of folks trying to pack as much as they can into a subscription and then use role-based access control at the resource group levels to kind of segregate things. There are no charges for a subscription. So we say, why not look at segregating things, separating things based on a subscription boundary? And it gives you a lot of additional benefits as well.

So I'm less likely to run into some, any sort of limitations or quotas that we see around subscriptions, around the number of role assignments that you can have, the number of NSGs and things like that, that oftentimes are at a subscription level. So having that separated really frees up the amount of resources we have available, gives you a little bit extra headroom.

It also has a very nice billing boundary, but it also gives me the ability to really separate from a security view based on those role-based access control. So that way I don't have a subscription owner who has a look into everything in the subscription where maybe I don't want them to have any view into this other subscription and the data there.

So I think when we look at it, we say single-tenant, maybe as many subscriptions as you're willing to have out there to use that as your first security boundary and then secure stuff even farther as you get into those resources that run in the resource groups. So it gives you quite a bit of additional flexibility and I think more granular control if you do that.

So and again, taking this back to automation, once we get this all automated or to some degree of automation, having a lot of subscriptions really doesn't matter anymore, right? As far as, oh, that's too many subscriptions to manage. It really at the end of the day, you're managing the resources and you're going to have the same amount of resources irrespective of if you have one subscription or 50 subscriptions.

So in following on from that, this idea of subscription limitations and quotas, if we are using role-based access controls appropriately and as we should, if we've got these resources spread over more subscriptions, I'm less likely to bump into some of these could become very critical showstopping limitations such as the number of role-based access controls is limited per subscription.

You hit a boundary of 2,000 role assignments that you can do for Azure resources in a subscription and that sounds like a lot, right? 2,000. We have had customers that have hit it. So really, how do we unwind that? Start moving those resources into different subscriptions.

So we're trying to just get ahead of these types of things, making sure that the customers aren't painting themselves into a corner, these organizations, because we'd rather have them understand long-term what they might run into six months a year from now or even further out and why we were recommending multiple subscriptions so that they can make a very, very informed decision.

First access controls is one of those, another more network-oriented control would be this idea of network security groups. There is a limit to 5,000 NSGs or network security groups that you can have in a subscription. And again, you think, oh, check 5,000. Have had customers who have hit it. Seems crazy, but a lot of folks are using NSGs that are assigned to the NICS, which is perfectly legitimate, allowable, but you can imagine that there's quite a few NSGs that start to pop up.

So again, if we can, we recommend, hey, potentially use on the subnets and not on the NICS, maybe separate those virtual machines and therefore the NICS into different subscriptions, I less likely to run into those boundaries. And that all, we take that in from a security perspective. So I just wanted to add that little bit to this idea of multiple subscriptions. It might be something really to think about as you're looking at your overall governance and standards for deploying in Azure.

Yeah, I had a customer hit, I can't remember what the limit was, because they thought that absolutely everything was always infinite. And turns out that wasn't correct. I mean, like you say, the numbers are, the limits are large, extremely large, but it's still worthwhile knowing what they are just in case. And like you say, actually the solution that this one customer came up with was to basically have more than one subscription and the problems magically went away.

So on that, we always ask our guests to leave our listeners with a final thought. So what would your final thought be? So final thought, it might be final thoughts, but I guess my final thought is it always approach every opportunity as new, as fresh. So in other words, in my mind as an architect, as an engineer, I know that X, Y, and Z always work. I would say, you certainly keep that, that's experiential.

But approach it with the blank slate, like this is a brand new problem, I'm going to approach it and really think about the problem and especially given that oftentimes this is brand new territory. So always come at everything fresh. Don't try to pre-solution within the first 30 seconds of a particular conversation. So and be open and willing to think about something completely new and different, some new type of approach and always think in the mind of an attacker.

So who could get to this and how? Kind of be nefarious and devious in your own head to see where we can shore up those defenses. So I think you should bring up the think like an attacker stuff. Yeah, if you have people in your organization who think like attackers, you need to be grooming those people to really work. No, I'm actually quite serious.

Yes. Normally, and Sarah can back me up here, I never interject after a final thought until this time because this is something that I am deeply passionate about. Having worked with so many customers who design things without realizing what an attacker can actually do. And even with threat modeling, we're showing the potential risks that an application may have. This is a critically important part.

If you have people who really do have that skill set, you need to be grooming them and helping them work with other people to make sure that they're securing the environment. Yes, a really good point. Thank you very much. So with that, let's bring this to an end. Chuck, thank you so much for joining us this week. I always learned something from our guests and this was absolutely no exception. And to our listeners out there, thank you so much for listening. Stay safe and we'll see you next time.

Thanks for listening to the Azure Security Podcast. You can find show notes and other resources at our website azsecuritypodcast.net. If you have any questions, please find us on Twitter at Azure SecPod. Music is from ccmixter.com and licensed under the Creative Commons license.