May 21, 2025 • 41 mins
If you're using Azure, one misconfiguration could expose your business. Do not wait for the worst to happen, and listen to our latest podcast to help you fix this.
Joining us today are Bob Bracke and Jorik Van Damme - both Azure consultants at The Collective. Together, we'll dive into the Azure Achilles' heel and explore the risks of a default Azure setup. Get ready for practical insights, best practices and strategies to strengthen your cloud environment, one episode at a time.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Jordy (00:00):
If you're using Azure, one misconfiguration could expose your business to disaster.
Do not wait for the worst, but let's fix it today.
Welcome to the Collective podcast.
The podcast where we delve into the ever evolving world of corporate security to help businesses stay ahead of the curve, whether you're a small startup or a global enterprise.
I'm your host, Jordy Decock, working for the Collective, where we pride ourselves on a hands on approach, working closely with our clients to cut through the noise and deliver the solutions they actually need.
(00:29):
No unnecessary fluff, no overselling each app.
In this episode, I'll be joined by experts, practitioners and thought leaders diving into today's most pressing security challenges.
We're here to provide insights, strategies and actionable advice to keep your organization safe and secure in a digital first world.
Joining me today are Bob Bracke and Jorik Van Damme, both Azure consultants at the Collective.
(00:52):
Together we'll dive into the Azure Achilles heel and explore the risks of a default Azure setup.
Get ready for practical insights, best practices and strategies to strengthen your cloud environment one episode at a time.
Welcome both and thank you for joining us today.
It's actually great that you guys come in for this episode because yesterday I was playing around with Azure in my home lab because I needed a way to store all the pictures my wife and I have and what I liked was the basic tutorial they gave me to set this resource up.
(01:23):
So I was wondering, maybe you guys can answer me if my storage is secure enough now.
Bob (01:29):
Well, this is exactly what happened earlier in my assessment this week.
This is something we see often people.
Jordy (01:35):
Just setting up their Azure by default.
Bob (01:38):
Or it's just really easy to get started, but it often involves some not misconfigurations, but there's definitely room for improvement.
Jorik (01:48):
Yeah, and something we encounter quite often we see it teams who try to experiment with Azure, they're trying to find out if it's the right way forward for their business by starting to just click around in the portal and see if it might actually be something for them.
And then often what happens is they try to evolve the environment and then build upon it and organically it grows and grows and so without going back on the stuff they put in at the start and so losing track of how secure it is or just generally forgetting to go back on it and then actually improve it from a security standpoint.
(02:28):
And this causes actually quite a bit of environments to be built on an unstable unstructured core, which leaves the Organization vulnerable from the inside out.
Azure obviously offers a lot of flexibility, but as we'll discuss today, the default options are very insecure.
So it kind of takes some knowledge and some basic understanding of how to set up these resources before actually going into it and just clicking.
(02:55):
Next.
Next finish.
Jordy (02:56):
Yeah, I was gonna say that's what I enjoyed about it.
That's what I liked.
I mean, I don't know about other cloud providers, but Azure does that great.
Bob (03:05):
Yeah, for sure.
That's really one strength of Azure.
It really is something that is really easy to get started.
But like Jorik said, that's something that's often forgotten because it needs to be either taken into production quickly or it's just not reviewed again, which often leaves room for vulnerabilities to be able to slip into the environment.
Jorik (03:31):
And there's just so many different resource types which each have their own caveats and little nooks and crannies when it comes to configuring them.
And so, yeah, it's very difficult to get started with if you don't have any understanding of Azure itself for sure.
Bob (03:45):
And like you said, Jorik, there's, for example, let's take Azure Data Factory or Azure Signups or Fabric now even, there's like three things which basically do the same thing, but they all have different networking options, they all have different specific situations where they're used.
But it's so easy to get set up and then use one configuration for one resource type, but that's not really applicable to the other.
(04:07):
And that really sometimes sets you up for, yeah, not going to say disasters, but definitely not an amazing environment.
Jordy (04:15):
Well, I can understand because I suppose from a business perspective you're already looking into, okay, which one of those three are we going to use?
So whichever one you pick, eventually you just want to get it set up as fast as possible.
So from a business perspective, I quite understand it because that's the same thing with my home lab.
(04:36):
I just need something, I just want to set up, but if it leaves my home lab vulnerable, then I don't like that.
Jorik (04:45):
You've probably noticed with your home lab that once you've got it up and running, you didn't go look back on it to see if it was actually.
Jordy (04:52):
Set up well yesterday.
So maybe after this episode I will go back to it.
Jorik (04:57):
We might have to take a look.
Bob (04:59):
And often something we see as well is that sometimes teams just don't really care.
Right.
If you're a developer or you're like a data analyst, a data Scientist?
Yeah, you just want to get the stuff up and running, get to provide value to your business and sometimes you just don't take the security into an account because we often see this as well, that security is something that only gets applied when a business, for example, has been breached or they've really encountered serious issues with their environment.
(05:28):
And to be honest, it really is two different things.
I've been working with Azure for a couple of years now and I know some of the basics from data science and app development.
But then working with Azure, setting up the resources in a secure manner, it's just something completely different.
And it's understandable that these teams don't have the knowledge, the extensive knowledge that you need to actually set these resources up properly.
(05:53):
It's two completely different worlds.
Jordy (05:55):
Well, maybe they have it from a normal setup environment, but not to set it up secure.
Is that good way to look at it?
Bob (06:05):
Yeah, I think it's just developers want things to work quickly, I feel like.
And that's definitely possible.
That's really a strength of Azure.
But like Yogik said as well, there's so many different resource types and every resource has its different setup and different configuration for maybe doing the exact same thing.
But when you're developing code multiple hours a day, sometimes you just don't have the time or the experience to actually set these resources up properly.
Jordy (06:33):
No, that's true.
And I also think it's just security as an extra.
It's not a basic, it's usually an afterthought.
It's the first thing where you can save money and I guess that's what businesses drives do not secure some things.
Jorik (06:48):
Correct.
And it's not always up to the consuming teams.
It's usually the support cast built around having an infrastructure in Azure and usually that's an infrastructure team which manages the entire landscape.
And so it's usually up to the consuming teams to just voice what they need and then have the infrastructure team think about how can we set up securely and then having some kind of handover face towards the consuming teams on how they can start to adopt this new environment and how they can start using it rather than having them dabble in it themselves and then start to create resources just to, yeah, be a means to an end and just get started with uploading those applications as quickly as possible.
(07:32):
But yeah, that usually leaves them vulnerable.
Bob (07:35):
That's something we often encounter indeed that there's just scattered resources, so to speak.
There's an application here, an app service here, a virtual machine there, and then Often with a public IP address attached to it.
Yeah, those are the kind of things that you don't want to see, right?
These applications, and like we initially mentioned as well, these environments are often organically grown, maybe without an initial infrastructure team or like a DevOps engineer that was able to support these teams.
(08:08):
And then maybe after an incident has occurred, maybe not, maybe there's some pushback from management that the environment needs to be reviewed, needs to be assessed.
That's somewhere where we come in, for example, Then we will be able to provide these details and these guidance on how to set that up.
But oftentimes a redeploy is required for this.
(08:28):
So it also requires some inputs and not some, but often a lot of input to redeploy these applications.
And implementing security for these applications also means that developers are not as free as possible or not as free as anymore, which often increases the development life cycle because they have to take care of, okay, now I need to assign permissions to an application to, for example, a data source or I need to know which outbound URLs I need.
(08:57):
So it really adds some friction, maybe between the teams, because that's something that you hear often as well.
The infrastructure and the development team often are like a conflicting two groups.
Jordy (09:09):
Just because they have two different things they have to watch.
Bob (09:12):
Exactly.
The developers need to provide value to the business and to their end users by upgrading their apps, adding new functionality.
And the infrastructure team often needs to provision the resources for them to be able to use.
And sometimes it just needs to go quickly, but that's not always a possibility.
Jorik (09:30):
At first sight.
It might seem quickly to just deploy, deploy.
But we often encounter situations where we assess a certain environment which has been deployed, deployed, just to speed up the release process.
But then what happens is a third party or an assessment party comes in and they have a look at the environment and they say, oh, what's going on here?
(09:52):
This is totally not secure at all.
And then what ends up happening is they basically have to restart.
And so they then deploy a secondary environment which is set up the proper way and which is secured from start to finish.
And then, yeah, you often have a migration trajectory towards the new environment, which.
Jordy (10:09):
Costs double the amount, which again takes.
Jorik (10:13):
A lot of money.
And that's something that's often forgotten at the initial start of a project.
The problems always come later.
Bob (10:21):
Additionally, you said, right, it's double the cost, but it's often more expensive than twice the cost because a lot of the features require specific SKUs.
In Azure and it might be a budgetary thing that management doesn't want to prove certain budgets and that's just often a reality as well.
Doing things secure in Azure, yeah, it really costs more money, but in my opinion it really is worth the cost.
Jordy (10:45):
But doesn't it?
I mean, if I recall correct, I've heard you guys sometimes come back from customers and you were like, hey, we did this and that there.
But were able to cut their cost down just because we did something security wise.
I mean, from a business perspective you can only applaud that.
As a CIO or ciso, the only thing I want is to be cost efficient.
(11:10):
And if it makes it secure and cost efficient, I'm all for it.
Jorik (11:14):
Exactly.
And it comes down to what Bob said about the scattered resources and just basically not having an overview of all the different small environments or applications that have been dropped out there.
Not having that sort of governance layer on top basically means that there's no overview of what's out there.
And then what we usually do is basically go through with some kind of orphaned resource assessment which basically shows us what resources are no longer in use.
(11:40):
And these can quite often be very expensive.
For example, last month I think it was, we did this assessment with a customer of ours and we basically noticed that they had a full on application gateway costing like over $600 a month just sitting there not having a single.
Jordy (11:56):
Listener on it just because they didn't look back at it.
Okay.
Jorik (11:59):
And it's not really a security risk or a security issue, but just not having a centralized party looking over all the resources in Azure to basically say like guys, are you still using this?
And then cleaning it up after them.
But these things really run up the cost and it's not always going to be an application gateway costing 600amonth, but just the simple things like an orphaned private endpoint for example, which will still be 10 bucks a month.
(12:24):
It really counts up.
Bob (12:27):
It's also not always in regards to configuring the correct resources or configuring them in a correct manner or choosing the correct SKUs.
Like Yog said, you need to have a governance using Azure policies or using the like a FinOps workbook to be able to review these setup resources.
(12:47):
Yeah, it really provides a lot of insight.
It might not directly increase the security of the environment, but it can remove blind spots and it can remove the cost which can open up budgets like you said Jogli with CSO or CFO to be able to then spend the money that was reduced from the environment and spending it on actually improving the environment.
Jordy (13:10):
Yeah, I think security in people's head is something that drives up the cost and why would they come after us?
But security isn't always just making sure nobody gets in.
It's also making sure that everything is good going the same way.
All heads are looking at the same direction.
I think that's a great example you gave as well with the resource that was still running that nobody just noticed because we have a lot and well, it works.
Bob (13:38):
Perfect example.
Wednesday last week, Wednesday I was on site at a customer.
I had a meeting with the security officer and we just went through the entire Azure subscription, all the Azure subscriptions.
We identified some key pain points, some things that, like you said, the heads were not in the same direction.
These things that were set up before we started working with our customer.
Yeah, there were some discrepancies between the way that we had currently set it up and the way that things were set up.
(14:04):
And we identified those key areas and now we're working together to fix, so to say the environment.
Everything is working fine.
And I think something that the security officer said as well, that really stuck with me was that, yeah, these applications are currently not set up optimally, so to speak, but they're becoming more and more critical and we want to be able to get to a optimal situation before they become too critical to be able to migrate.
(14:32):
And with these types of migrations, yeah, you really need to, like you said as well and Jorik, you need to be able to set up a separate environment to be able to ensure that there is absolutely zero downtime, zero issues.
And that takes time as well because everything needs to be thoroughly tested.
But it really is worth it to.
Jorik (14:51):
Be able to do this and not starting early enough, as we already mentioned, multiple times.
You also notice, Bob, when we go through these trajectories, they usually take what like two weeks, three weeks.
Dependencies on developers, dependencies on the infrastructure team, dependencies on the business itself.
When can we migrate?
When is a good time to migrate?
Usually at night, just because we want to keep the impact low.
(15:15):
And all of these things really run up the cost of such a trajectory.
And so it's very important.
I think one of the main takeaways from this part is that we should really think about securing the environment from the get go without just thinking, well, we'll fix it later, because later probably never comes until it's too late.
Jordy (15:32):
Is there a.
You mentioned it, but what would be the difference if we would, for example, be with the customer from the start, helping set up everything, bringing the architectures, explaining how we will set up things in comparison.
I know it depends on how big you see it, but just a regular company and we have to actually replace everything into a new subscription.
(15:56):
What would the impact actually be for a company?
Because I think there are a lot of companies out there in this position that are just scared to actually redeploy everything.
Jorik (16:05):
Yeah, and I totally get it, but we've been talking about migrating a lot right now.
It doesn't always have to be a full migration.
There are multiple and I say multiple, I mean really a lot of options to secure already existing resources without having to go to bigger SKUs.
For example.
One quick thing that just pops in my head is for example if they have a public SQL Server, for example, it's just a very quick thing to do to just enable selected networks, put in the firewall list of IPs that are calling the database itself.
(16:39):
And so without driving up the cost, you already reduce the risk of unknown IPs, malicious IPs just directly connecting to your database.
Bob (16:47):
Yeah, for sure.
Like something that we do as well is we really try to focus on the networking part of things as well in Azure because we really feel that's really important.
We want to have one ingress points often or application gateway or like a front door instance to be able to apply certain OWASP rules, to be able to mitigate common attack patterns.
And we also something that we really try to push as well for our customers is we have a central egress point, for example an Azure firewall or even Apollo Alto, a something else checkpoint, whatever.
(17:18):
Because that really it's again being in control and that allows you to be in control, you know, okay, you can perfectly see, okay, all these requests are being entered from these IPs via our application gateway.
We have complete control over what is going out of the network.
And like yogitech, these things don't necessarily mean that this really increases the cost because you can for example with web apps as well, you can already configure certain network rules and only allow for example the public IP of the application gateway, which already enforces the entry point to be our application gateway.
(17:50):
So there's really certain things that can be done as well.
Example, a second example rather for virtual machines, check if they are public IPs, do they need to be public?
Can they maybe be integrated with the application gateway as well?
If they have to be public, please check if there are any network security groups Are there any other ports exposed?
We preferably disallow RDP and SSH to be able to block attackers from entering.
(18:13):
Virtual machines can also be used as a honeypot, but that's something else.
And yeah, these kinds of things really it's a simple check just going through the network security groups in Azure.
Just a complete overview.
You don't have to do any fancy PowerShell or fancy rest API calls, just check it in a portal.
See if every subnet, every NIC has a network security group configured.
(18:35):
Check if there are any open ports, especially for virtual machines.
And this is there's some really easy things that can be done.
Jorik (18:42):
You bring up an interesting point with the virtual machines and then coming back to your home lab Jodi Going back to the next finish setup of a virtual machine, it will actually pre provision a public IP and if you're not careful it will actually open up the port 22 or 3389 which basically means you send out an open invitation to anyone on the Internet to just go see what's on your virtual machine.
(19:07):
Just imagine you host some kind of business critical application on there and you were not careful with your next finish setup.
Yeah, it's game over for you.
Bob (19:14):
It doesn't take long to crack a password, right?
Unless you're like Michael enforcing 48 character password generations.
Jordy (19:22):
You know that's true.
But you've talked about the firewalls and the ports.
Should I see those as low hanging fruits that are easily pick up on within your Azure environment?
Or are there other low hanging fruits that you are.
Well you just press next next confirm.
What's the first thing I'll have to do?
Jorik (19:43):
Yeah, so the firewall and the single point of ingress Bob mentioned, they are quite extensive improvements already.
They basically require you to redesign your whole entire network setup, preferably to some kind of hubspoke implementation.
Jordy (19:59):
And I assume you need some kind of confidence in what you are doing exactly at that moment.
Jorik (20:05):
Basically at that point every application needs to be reviewed just to make sure that everything can be linked to the hub.
For example, if you have overlapping IP addresses you're already in big trouble.
But there are some improvements you can do rather easily and as we already mentioned, selected networks is a big one.
Ensuring there is no public IP on your virtual machine, for example, ensuring TLS 1.3 is enforced on your storage accounts.
Bob (20:31):
For the storage accounts, maybe one for you.
Check if there is no anonymous access to your blobs that you're trying to make available because that will allow to People, if they go to the URL they can actually view the pictures or download pictures.
So be sure that no anonymous access is set.
Of course if this is a requirement for certain applications it needs to be accepted, an accepted risk.
(20:54):
But there are really some things that can be done as well.
Maybe for storage accounts as well.
Really try to avoid the SUS keys.
Yeah, they provide you a lot of access, possibly read or like God mode access to your storage account.
And something that's really somewhat annoying especially for the infrastructure teams is they are tied to the account key basically like the master password of the storage account.
(21:17):
And the thing is there's no way to be able to review if there are 1025000 storage account keys created.
The only thing that you can do is you can rotate the key but that breaks all the other keys that have been created.
So that's why we really tried to shy away from the storage account keys.
And really maybe one thing that is really important as well, try to stay away from local authentication.
(21:41):
And with that, I mean access keys or SQL authentication to the SQL database or Cosmos database for example, really try to use managed identities, try to use app registrations to leverage the Azure role based access control.
Because there really is a lot of support for these kinds of authentication and of course it is easy to use this local authentication but there really is a lot of benefit and really moving towards the role based access control.
Jordy (22:09):
Yeah, I should definitely look into it and the more I hear you talk about it I'm like oh shit, I haven't done this right or I haven't thought this through.
Even working for a security company, you know, it's your home lab.
But as more as you talk about it and indeed anonymous entry, I mean there are pictures of my kid in there.
(22:30):
I don't, I don't want them to be out there.
Bob (22:32):
So.
Jorik (22:32):
Yeah, and again once it works you're not going to look back.
No, no, that's how to improve the security.
And with anonymous blob access it will probably work.
Jordy (22:40):
I just, I just want to have the time to look back at it.
It's, you know, it's a project that once the project is done I.
Jorik (22:46):
I move on to the next one.
Jordy (22:48):
It's, it's one of many on the to do list.
So yeah, we've talked a bit deeper about the storage accounts.
You also mentioned the virtual machines.
I mean I believe most of the companies who use Azure definitely run virtual machines.
What are the first Things for them to look at once the virtual machine has been deployed.
(23:10):
I mean, one of the first things I would personally do is check if.
Does it have to be on 24 7?
Is there, is there a timing that I can schedule?
Are there other things?
Jorik (23:19):
Definitely.
And you bring up a very good point.
Scaling down the virtual machine at night, for example, when it might not be used, has two benefits actually.
So for one, it will reduce your cost because it's not running at night.
And then secondly, people can't attack your machine at night because it's just shut down.
Jordy (23:35):
And most malicious threats are from foreign countries, are from different time zones.
Russia, China, Korea, America.
So them being offline at night here in Belgium is like a big advantage.
Jorik (23:48):
Yeah, for sure.
And some of the other things I often see at customers is the local account used on the virtual machine is not looked after at all.
The policies we usually deploy to our customers contain some sort of password rotation for these admin accounts.
On the other hand, you might have a minimum password requirement, size and length or complexity to further reduce the risk of brute forcing on your virtual machine.
(24:14):
Because some of these machines have to be public.
I mean, you can't get around it.
But in that case there's other solutions, such as the single point of ingress, for example.
But securing your host operating system is a very important thing.
And making sure it receives periodic updates, patching latest security improvements sent out by Microsoft.
(24:36):
Because once you deploy a virtual machine out of the box, it won't get any updates.
So you have to make sure that there's an update management plan in place saying that these times of week it can receive these updates whether the machine has to restart or not.
And then if you have a machine that shuts down at night, hey, perfect.
Because then it also restarts, pulls in all the updates, and then it's secure against the vulnerabilities Microsoft has already identified.
Jordy (25:01):
And is it something we should only look at with virtual machines?
Or are there other, for example, applications we could use the same way to manage them?
Jorik (25:11):
So one important thing here is you have to update your own resources if they are infrastructure as a service.
But once you move on to the more Azure native services such as Azure Web applications or container apps, you basically reduce the need of having to do this yourself because Microsoft basically takes it over for you.
Maybe another takeaway for the listeners if you can please use these platform as a service components because they're way more hands off, they're way more in the direction of, okay, I can just deploy this here well, regarding some of the security configurations you always have to make, but in that scenario you can just dump your code on there and it will probably work.
Jordy (25:54):
And there's already a cost of inventing or investing money into security that is already taken off your hands.
Jorik (26:01):
Exactly.
Bob (26:02):
You're a lot less responsible as well for the resources.
Like Jorik said, you don't have to be bothered with patching or backup.
A lot of those features, especially in the past components, are already configured or taken care of by Microsoft.
So that's definitely a big plus, especially for the infrastructure team.
They can focus themselves on more, so to speak, important tasks or other pressing matters.
(26:26):
And something I heard at the customer as well last week on Wednesday is they said, yeah, if it has to run on a virtual machine, I'm just going to put it in my data center.
I want to work as cloud native as possible, especially in Azure.
There's just so much support for this and a lot of the developers are also very fond of this.
They don't want to log in to a virtual machine and click around the ui.
(26:49):
They want to just be able to provide them either with a script or provide them with a pipeline or help them out.
Creating their pipeline to automate the deployment to the resources, that really is an advantage because it's less work for the infrastructure team and it's less work for the developers because they don't have to be bothered with.
Sometimes it's also responsibility of the developers to do it securely and sometimes that's not a possibility.
(27:15):
So being able to unburden, so to speak, the developers as well, is really something I feel like they are very fond of.
Jorik (27:22):
And it's also an important part of driving the adoption towards cloud because people don't like change and so they're most likely used to what they run on premise and so pushing them towards cloud for whatever reason.
This might actually help because for a lot of certain Personas it's easier to adopt cloud technology and contrary to infrastructure as a service type of resources.
Jordy (27:47):
Okay, Bob, you also mentioned before we started the recording of this podcast that Microsoft announced something.
Maybe we should elaborate on that as well, because from what I've heard, it might have a big impact on some companies and I don't think they are always up to date about this because it's not always straightforward.
Bob (28:07):
Indeed.
So indeed what I read, maybe I spread a little bit too much of fear, but it is for new virtual machines, so that's a big nuance.
So luckily we're safe there.
But what I was saying prior to the podcast is that Microsoft, I think it was September 30, 2025, that there's not going to be any default outbound connectivity from virtual machines.
(28:31):
So then you will have to specify or create a route table to be able to route your data to the Internet specifically.
So that's really something well done by Microsoft to restrict the access and to force them towards that single exit point or single E point for your data.
I think that's something really important as well what we do and something you see as well.
When you try to create a virtual network, the first thing that you see is you get a slash 16 network range gets thrown at your face.
(28:58):
It's way too big.
You never need that many IP addresses like Joik mentioned as well previously, if you want to integrate this with other virtual networks, you get issues because you've got overlapping network ranges.
You need to resize them.
Sometimes that's not possible because certain ranges are already in use.
You need to making changes to virtual networks when there are already certain networking components like a network interface for a virtual machine, when these things are already present in the virtual network, making changes to the network ranges or moving them even is nearly impossible.
(29:30):
So it really is important to be able to think about those settings.
And what we like to do at the collective and our customers is we work with a default route like you know, it on premises or default networking setups.
We create a user defined route which basically overrides all the existing routes that Microsoft creates by default.
And we force all the traffic towards our Palo Alto, towards our checkpoint, towards our Azure firewall.
(29:54):
And we there explicitly whitelist all the required network traffics that is either it being in the same virtual network, it being connectivity towards on premise resources, either via VPN connection for example, or even access to other private Azure resources that might have been or that might be present in the environment.
(30:15):
Also I think the most important part is the Internet access.
So specifically for app services, they might have to pull from a container registry to be able to download Docker file.
We want to whitelist only specific URLs so that we ensure that if a hacker or a threat actor would be able to gain access to these applications either via code injection or SQL injection or something that they're not able to set up like a beacon or something like that they can communicate back to their home base, so to speak.
(30:45):
And really restricting the outbound access ensures that it really increases the security of the environment.
We talked about a lot about the inbound access to the virtual machines and that's obviously very important as well.
But ensuring that they cannot go back or download malicious code on the applications or the virtual machines is really also an important factor.
Jordy (31:04):
Yeah, it's great to mention as well.
That's why I brought it back up.
Maybe one question that popped in my head when were busy from a business perspective, as a ciso, I know a lot of companies are hybrid builds, not a lot of companies are still only on premise or are yet fully cloud native.
What is a big difference between making my on premise secure and my Azure security?
(31:26):
What I do believe there is a big difference and there are a few nuances that a lot of people are missing, especially because of the lack of IT profiles out there that can actually secure a Azure environment because they all think very on premise.
Jorik (31:43):
I think one of the main parts here is that on prem it's way harder to create a public service while in Azure, as you noticed yesterday with your home lab, it's super easy to create a service which is publicly exposed and open to the Internet, which this is something you don't really have on premise.
And on premise usually they have one Internet line or one ISP router, for example, which routes everything outbound or inbound.
(32:08):
But on Azure you can create a single resource which has its own ingress point, its own egress point, and is basically isolated all on its own, but still be able to connect to the rest of the resources.
While on prem you basically have an isolated network within your data center, you already have to kind of put in the effort to get it publicly exposed.
While on Azure developer you just want to try something, you just click together a web application, it just has a public endpoint right off the get go.
(32:32):
And this is something we should really be wary of in the cloud.
And so infra teams should find the perfect balance between giving the liberty to their teams on being able to create their own resources, but within some kind of boundary.
And so the infra team should really try to provide guardrails for their teams, which basically state, look, you really can't deploy any resources with a public endpoint.
(32:55):
We're going to block this through some kind of policy, for example, but then still have them be able to think for their own, see what they need, which resources they want to use, but then also allow them to actually deploy themselves.
Because in bigger environments, when you have, let's say 10 different development teams or 10 different consuming teams, if you have to create all these resources yourself, you're going to be in for a Hell of a ride.
(33:16):
You will also won't be able to monitor them all.
So you will somewhere require some kind of tool that tells you this resource is not really compliant to your standards.
What are you going to do about it?
And then you as an infra team will probably speak to the guy who created it and then be like, hey, this is not up to par with our standards, could you please revise your resource?
Jordy (33:36):
Isn't that something policies could really solve and yeah, for sure.
Jorik (33:39):
Yeah, okay, definitely.
And this is I think also one of the quick wins is find yourself a good policy baseline.
And it doesn't even need to be a deny or a deploy if not exists.
It could just be an audit mode policy which has no impact at all on any of your existing resources, but it will just generate you a very nice Overview of Look, 80% of your resources are currently not secure and it's usually a very big eye opener for security people within the company and a very big call to action.
(34:08):
And that's something we often see at our customers as well, where we usually get quite some reaction from.
And yeah, it's really a big step.
Bob (34:15):
Forward usually it's also one if we do assessments or we're starting to implement some governance as well at the customer like the policy baseline.
That's something we deploy as well because if you don't know that it exists, you can't act upon it.
And I really liked what Yogik said as well.
You need to be able to give the consuming teams the liberty to be able to play around and maybe badly worded but be able to configure the necessary things on their own because in bigger environments and then we go to more like a more DevOps mindset, more integration approach, the infrastructure team or the DevOps team needs to be a facilitator for the consuming teams and it can't be a blocking factor because then you will get annoyed people, you will get really the friction I was talking about and that's really important.
(35:00):
Something that really was important to me as well is that you said the Liberty.
But the difference between the Liberty in Azure and the Liberty on Prem is I think also a really big contrast because in Azure, and that's also a bit of the hard part about Azure.
Jordy (35:17):
It's a mind shift.
Bob (35:18):
It's a mind shift, yes, but also the connectivity and the connection with Entra id.
It's not because you use Azure that your Entra ID is configured as correctly.
So sometimes these users are added to the entra tenant for 365 or teams or whatever.
But if the Entra tenant is not properly configured, they might just have access to all the Azure resources as well and that really can cause problems.
(35:41):
So you need to set up the correct security configurations to be able to block off certain things in Entra, but also configure the correct access to specific subscriptions, preferably via privileged identity management to be able to give them specific roles or access to specific groups, or only time bound or check some multifactor authentication, et cetera.
And I think that really is also something that makes it easier in some cases and maybe in companies where there is less of an IT team, if there's really a big drive for business need and the company is developing, sometimes they haven't really, they don't have that beefy IT team yet that can provide the support.
(36:18):
And I really feel like that just rating something on prem will be a lot harder than in Azure.
Jorik (36:23):
Okay, and also to further drive the point Bob just made, sometimes there is the notion that their on premise is fully isolated of what's happening in Azure, but then they might either have some kind of VPN tunnel between both, not secure the VPN tunnel and then risk some kind of issue within Azure or some kind of break in Azure to then propagate towards their on premise network.
(36:45):
Say for example, they are very established and very mature on premise, but then they start trying out some stuff in Azure and then with all the points we discussed today, they just forget to disable some kind of public endpoint, then it routes back through the VPN gateway over to their on premise network and all of a sudden your entire business is compromised.
Another way to compromise it like this, for example, is if you have a virtual machine within Azure which is linked to your on premise domain.
(37:09):
This is perfectly possible, but if you then have Entra ID authentication on this virtual machine and you forget to lock down your Entra id, a malicious actor could just break into your Entra id, for example, log into the machine and then suddenly be domain admin, for example, on your on premise domain.
So it's very important to be wary of this.
Jordy (37:26):
Okay, yeah, it's a very good point.
Maybe we should, for all of our listeners who might be in an important role, manage IT manager, ciso, cio.
What are the basic things or keynotes they can take away from this episode and what should be the first things they can implement?
I imagine there are a lot of people who are having an Azure or after this episode are like, okay, I should do something, but where do I Begin.
Bob (37:52):
I think something easy and really low hanging fruit is deploying some policies to get some insight, especially if you're starting off and you have some bit of an Azure environment already, but you don't really have like a dedicated team that can control, so to say this environment.
Really get insight into what you have in Azure.
Try to see, okay, do I have a lot of web apps?
(38:13):
Do I have a lot of virtual machines?
Not only for the security of these resources but also like we've discussed the cost aspect because this can really open a lot of.
Yeah, what is still running?
Do we still need it?
And it's not only in regards to the cost, but also the security.
If an application has already been moved to another provider or something else, it has been decommissioned, something, sometimes there are still resources left, something that Microsoft is doing as well.
(38:36):
When you create a virtual machine, they have implemented options to be able to automatically delete the network endpoint and the disks as well.
For older machines this might not be the case.
So it's not because you delete a virtual machine, which might cost you €50amonth, but there still could be like a disk of like 2 to 3 terabytes which might cost you like €200 and you think, okay, I have deleted the virtual machine, but there might still be some lingering resources.
(39:00):
And then these policies and these workbooks really can provide amazing insight into the environment.
Jorik (39:07):
Yeah, one of the other points we've talked about today is very much try to work towards a centralized networking hub, as this will provide a lot of insight into what traffic is coming in, what traffic is going out, and even within your environment which type of applications or resources can talk to other applications or resources.
We both know that going to a deny all firewall from the get go is just not a possible feat.
(39:33):
And so what we usually do when we get into this type of situation is we just open up the firewall, any to any and then we check the logs to see what traffic is actually moving over the centralized hub.
And that way we are not a blocking factor from day one, but we kind of get to inventorize the different flows that are going over it.
After which we can then start to bring down the firewall and really start tying it down.
(39:55):
But then also from an ingress point of view, just trying to reduce the different ingress points within your environment to various different resources can drastically and will drastically improve the security posture of your environment.
Bob (40:09):
And if I can add to this as well, what we see as well something with our customers that are also making use of our security operations center is we really have a close collaboration with this team.
And for example, like Yogik said that those central egress, that central ingress points can really provide a lot of interesting logs for the security Operations Center.
(40:33):
They can spot certain misconfigurations.
They can spot certain, e.g.
kag Buggles or NTLs connections that should not be occurring.
For example, integration with the web application firewall on.
Org application gateway.
That really is crucial information to be able to stop a threat actor or even prevent them before they can even do anything.
(40:55):
And I really think, and that's something that we really want to drive home here is getting the insight into the environment is a lot more important than a lot of people think.
Jordy (41:04):
Yeah, the important thing I'm taking away from this is that next time I'm setting up an Azure resource, I'm calling one of you and not just clicking this wraps.
Also, also up the episode of today.
A big thank you to Jorik, to Bob for sharing your valuable insights.
And of course, thank you all for tuning in.
We hope you found today's discussion helpful.
(41:25):
If you did, don't forget to subscribe and share this with your colleagues, helping us reach more people who are just as passionate about building a safer digital world.
We'll be back next time with another important topic in corporate security.
Until then, stay vigilant, stay secure, and let's keep working together to shape a safer future.
If you're using Azure, one misconfiguration could expose your business to disaster.
Do not wait for the worst, but let's fix it today.
Welcome to the Collective podcast.
The podcast where we delve into the ever evolving world of corporate security to help businesses stay ahead of the curve, whether you're a small startup or a global enterprise.
I'm your host, Jordy Decock, working for the Collective, where we pride ourselves on a hands on approach, working closely with our clients to cut through the noise and deliver the solutions they actually need.
(00:29):
No unnecessary fluff, no overselling each app.
In this episode, I'll be joined by experts, practitioners and thought leaders diving into today's most pressing security challenges.
We're here to provide insights, strategies and actionable advice to keep your organization safe and secure in a digital first world.
Joining me today are Bob Bracke and Jorik Van Damme, both Azure consultants at the Collective.
(00:52):
Together we'll dive into the Azure Achilles heel and explore the risks of a default Azure setup.
Get ready for practical insights, best practices and strategies to strengthen your cloud environment one episode at a time.
Welcome both and thank you for joining us today.
It's actually great that you guys come in for this episode because yesterday I was playing around with Azure in my home lab because I needed a way to store all the pictures my wife and I have and what I liked was the basic tutorial they gave me to set this resource up.
(01:23):
So I was wondering, maybe you guys can answer me if my storage is secure enough now.
Bob (01:29):
Well, this is exactly what happened earlier in my assessment this week.
This is something we see often people.
Jordy (01:35):
Just setting up their Azure by default.
Bob (01:38):
Or it's just really easy to get started, but it often involves some not misconfigurations, but there's definitely room for improvement.
Jorik (01:48):
Yeah, and something we encounter quite often we see it teams who try to experiment with Azure, they're trying to find out if it's the right way forward for their business by starting to just click around in the portal and see if it might actually be something for them.
And then often what happens is they try to evolve the environment and then build upon it and organically it grows and grows and so without going back on the stuff they put in at the start and so losing track of how secure it is or just generally forgetting to go back on it and then actually improve it from a security standpoint.
(02:28):
And this causes actually quite a bit of environments to be built on an unstable unstructured core, which leaves the Organization vulnerable from the inside out.
Azure obviously offers a lot of flexibility, but as we'll discuss today, the default options are very insecure.
So it kind of takes some knowledge and some basic understanding of how to set up these resources before actually going into it and just clicking.
(02:55):
Next.
Next finish.
Jordy (02:56):
Yeah, I was gonna say that's what I enjoyed about it.
That's what I liked.
I mean, I don't know about other cloud providers, but Azure does that great.
Bob (03:05):
Yeah, for sure.
That's really one strength of Azure.
It really is something that is really easy to get started.
But like Jorik said, that's something that's often forgotten because it needs to be either taken into production quickly or it's just not reviewed again, which often leaves room for vulnerabilities to be able to slip into the environment.
Jorik (03:31):
And there's just so many different resource types which each have their own caveats and little nooks and crannies when it comes to configuring them.
And so, yeah, it's very difficult to get started with if you don't have any understanding of Azure itself for sure.
Bob (03:45):
And like you said, Jorik, there's, for example, let's take Azure Data Factory or Azure Signups or Fabric now even, there's like three things which basically do the same thing, but they all have different networking options, they all have different specific situations where they're used.
But it's so easy to get set up and then use one configuration for one resource type, but that's not really applicable to the other.
(04:07):
And that really sometimes sets you up for, yeah, not going to say disasters, but definitely not an amazing environment.
Jordy (04:15):
Well, I can understand because I suppose from a business perspective you're already looking into, okay, which one of those three are we going to use?
So whichever one you pick, eventually you just want to get it set up as fast as possible.
So from a business perspective, I quite understand it because that's the same thing with my home lab.
(04:36):
I just need something, I just want to set up, but if it leaves my home lab vulnerable, then I don't like that.
Jorik (04:45):
You've probably noticed with your home lab that once you've got it up and running, you didn't go look back on it to see if it was actually.
Jordy (04:52):
Set up well yesterday.
So maybe after this episode I will go back to it.
Jorik (04:57):
We might have to take a look.
Bob (04:59):
And often something we see as well is that sometimes teams just don't really care.
Right.
If you're a developer or you're like a data analyst, a data Scientist?
Yeah, you just want to get the stuff up and running, get to provide value to your business and sometimes you just don't take the security into an account because we often see this as well, that security is something that only gets applied when a business, for example, has been breached or they've really encountered serious issues with their environment.
(05:28):
And to be honest, it really is two different things.
I've been working with Azure for a couple of years now and I know some of the basics from data science and app development.
But then working with Azure, setting up the resources in a secure manner, it's just something completely different.
And it's understandable that these teams don't have the knowledge, the extensive knowledge that you need to actually set these resources up properly.
(05:53):
It's two completely different worlds.
Jordy (05:55):
Well, maybe they have it from a normal setup environment, but not to set it up secure.
Is that good way to look at it?
Bob (06:05):
Yeah, I think it's just developers want things to work quickly, I feel like.
And that's definitely possible.
That's really a strength of Azure.
But like Yogik said as well, there's so many different resource types and every resource has its different setup and different configuration for maybe doing the exact same thing.
But when you're developing code multiple hours a day, sometimes you just don't have the time or the experience to actually set these resources up properly.
Jordy (06:33):
No, that's true.
And I also think it's just security as an extra.
It's not a basic, it's usually an afterthought.
It's the first thing where you can save money and I guess that's what businesses drives do not secure some things.
Jorik (06:48):
Correct.
And it's not always up to the consuming teams.
It's usually the support cast built around having an infrastructure in Azure and usually that's an infrastructure team which manages the entire landscape.
And so it's usually up to the consuming teams to just voice what they need and then have the infrastructure team think about how can we set up securely and then having some kind of handover face towards the consuming teams on how they can start to adopt this new environment and how they can start using it rather than having them dabble in it themselves and then start to create resources just to, yeah, be a means to an end and just get started with uploading those applications as quickly as possible.
(07:32):
But yeah, that usually leaves them vulnerable.
Bob (07:35):
That's something we often encounter indeed that there's just scattered resources, so to speak.
There's an application here, an app service here, a virtual machine there, and then Often with a public IP address attached to it.
Yeah, those are the kind of things that you don't want to see, right?
These applications, and like we initially mentioned as well, these environments are often organically grown, maybe without an initial infrastructure team or like a DevOps engineer that was able to support these teams.
(08:08):
And then maybe after an incident has occurred, maybe not, maybe there's some pushback from management that the environment needs to be reviewed, needs to be assessed.
That's somewhere where we come in, for example, Then we will be able to provide these details and these guidance on how to set that up.
But oftentimes a redeploy is required for this.
(08:28):
So it also requires some inputs and not some, but often a lot of input to redeploy these applications.
And implementing security for these applications also means that developers are not as free as possible or not as free as anymore, which often increases the development life cycle because they have to take care of, okay, now I need to assign permissions to an application to, for example, a data source or I need to know which outbound URLs I need.
(08:57):
So it really adds some friction, maybe between the teams, because that's something that you hear often as well.
The infrastructure and the development team often are like a conflicting two groups.
Jordy (09:09):
Just because they have two different things they have to watch.
Bob (09:12):
Exactly.
The developers need to provide value to the business and to their end users by upgrading their apps, adding new functionality.
And the infrastructure team often needs to provision the resources for them to be able to use.
And sometimes it just needs to go quickly, but that's not always a possibility.
Jorik (09:30):
At first sight.
It might seem quickly to just deploy, deploy.
But we often encounter situations where we assess a certain environment which has been deployed, deployed, just to speed up the release process.
But then what happens is a third party or an assessment party comes in and they have a look at the environment and they say, oh, what's going on here?
(09:52):
This is totally not secure at all.
And then what ends up happening is they basically have to restart.
And so they then deploy a secondary environment which is set up the proper way and which is secured from start to finish.
And then, yeah, you often have a migration trajectory towards the new environment, which.
Jordy (10:09):
Costs double the amount, which again takes.
Jorik (10:13):
A lot of money.
And that's something that's often forgotten at the initial start of a project.
The problems always come later.
Bob (10:21):
Additionally, you said, right, it's double the cost, but it's often more expensive than twice the cost because a lot of the features require specific SKUs.
In Azure and it might be a budgetary thing that management doesn't want to prove certain budgets and that's just often a reality as well.
Doing things secure in Azure, yeah, it really costs more money, but in my opinion it really is worth the cost.
Jordy (10:45):
But doesn't it?
I mean, if I recall correct, I've heard you guys sometimes come back from customers and you were like, hey, we did this and that there.
But were able to cut their cost down just because we did something security wise.
I mean, from a business perspective you can only applaud that.
As a CIO or ciso, the only thing I want is to be cost efficient.
(11:10):
And if it makes it secure and cost efficient, I'm all for it.
Jorik (11:14):
Exactly.
And it comes down to what Bob said about the scattered resources and just basically not having an overview of all the different small environments or applications that have been dropped out there.
Not having that sort of governance layer on top basically means that there's no overview of what's out there.
And then what we usually do is basically go through with some kind of orphaned resource assessment which basically shows us what resources are no longer in use.
(11:40):
And these can quite often be very expensive.
For example, last month I think it was, we did this assessment with a customer of ours and we basically noticed that they had a full on application gateway costing like over $600 a month just sitting there not having a single.
Jordy (11:56):
Listener on it just because they didn't look back at it.
Okay.
Jorik (11:59):
And it's not really a security risk or a security issue, but just not having a centralized party looking over all the resources in Azure to basically say like guys, are you still using this?
And then cleaning it up after them.
But these things really run up the cost and it's not always going to be an application gateway costing 600amonth, but just the simple things like an orphaned private endpoint for example, which will still be 10 bucks a month.
(12:24):
It really counts up.
Bob (12:27):
It's also not always in regards to configuring the correct resources or configuring them in a correct manner or choosing the correct SKUs.
Like Yog said, you need to have a governance using Azure policies or using the like a FinOps workbook to be able to review these setup resources.
(12:47):
Yeah, it really provides a lot of insight.
It might not directly increase the security of the environment, but it can remove blind spots and it can remove the cost which can open up budgets like you said Jogli with CSO or CFO to be able to then spend the money that was reduced from the environment and spending it on actually improving the environment.
Jordy (13:10):
Yeah, I think security in people's head is something that drives up the cost and why would they come after us?
But security isn't always just making sure nobody gets in.
It's also making sure that everything is good going the same way.
All heads are looking at the same direction.
I think that's a great example you gave as well with the resource that was still running that nobody just noticed because we have a lot and well, it works.
Bob (13:38):
Perfect example.
Wednesday last week, Wednesday I was on site at a customer.
I had a meeting with the security officer and we just went through the entire Azure subscription, all the Azure subscriptions.
We identified some key pain points, some things that, like you said, the heads were not in the same direction.
These things that were set up before we started working with our customer.
Yeah, there were some discrepancies between the way that we had currently set it up and the way that things were set up.
(14:04):
And we identified those key areas and now we're working together to fix, so to say the environment.
Everything is working fine.
And I think something that the security officer said as well, that really stuck with me was that, yeah, these applications are currently not set up optimally, so to speak, but they're becoming more and more critical and we want to be able to get to a optimal situation before they become too critical to be able to migrate.
(14:32):
And with these types of migrations, yeah, you really need to, like you said as well and Jorik, you need to be able to set up a separate environment to be able to ensure that there is absolutely zero downtime, zero issues.
And that takes time as well because everything needs to be thoroughly tested.
But it really is worth it to.
Jorik (14:51):
Be able to do this and not starting early enough, as we already mentioned, multiple times.
You also notice, Bob, when we go through these trajectories, they usually take what like two weeks, three weeks.
Dependencies on developers, dependencies on the infrastructure team, dependencies on the business itself.
When can we migrate?
When is a good time to migrate?
Usually at night, just because we want to keep the impact low.
(15:15):
And all of these things really run up the cost of such a trajectory.
And so it's very important.
I think one of the main takeaways from this part is that we should really think about securing the environment from the get go without just thinking, well, we'll fix it later, because later probably never comes until it's too late.
Jordy (15:32):
Is there a.
You mentioned it, but what would be the difference if we would, for example, be with the customer from the start, helping set up everything, bringing the architectures, explaining how we will set up things in comparison.
I know it depends on how big you see it, but just a regular company and we have to actually replace everything into a new subscription.
(15:56):
What would the impact actually be for a company?
Because I think there are a lot of companies out there in this position that are just scared to actually redeploy everything.
Jorik (16:05):
Yeah, and I totally get it, but we've been talking about migrating a lot right now.
It doesn't always have to be a full migration.
There are multiple and I say multiple, I mean really a lot of options to secure already existing resources without having to go to bigger SKUs.
For example.
One quick thing that just pops in my head is for example if they have a public SQL Server, for example, it's just a very quick thing to do to just enable selected networks, put in the firewall list of IPs that are calling the database itself.
(16:39):
And so without driving up the cost, you already reduce the risk of unknown IPs, malicious IPs just directly connecting to your database.
Bob (16:47):
Yeah, for sure.
Like something that we do as well is we really try to focus on the networking part of things as well in Azure because we really feel that's really important.
We want to have one ingress points often or application gateway or like a front door instance to be able to apply certain OWASP rules, to be able to mitigate common attack patterns.
And we also something that we really try to push as well for our customers is we have a central egress point, for example an Azure firewall or even Apollo Alto, a something else checkpoint, whatever.
(17:18):
Because that really it's again being in control and that allows you to be in control, you know, okay, you can perfectly see, okay, all these requests are being entered from these IPs via our application gateway.
We have complete control over what is going out of the network.
And like yogitech, these things don't necessarily mean that this really increases the cost because you can for example with web apps as well, you can already configure certain network rules and only allow for example the public IP of the application gateway, which already enforces the entry point to be our application gateway.
(17:50):
So there's really certain things that can be done as well.
Example, a second example rather for virtual machines, check if they are public IPs, do they need to be public?
Can they maybe be integrated with the application gateway as well?
If they have to be public, please check if there are any network security groups Are there any other ports exposed?
We preferably disallow RDP and SSH to be able to block attackers from entering.
(18:13):
Virtual machines can also be used as a honeypot, but that's something else.
And yeah, these kinds of things really it's a simple check just going through the network security groups in Azure.
Just a complete overview.
You don't have to do any fancy PowerShell or fancy rest API calls, just check it in a portal.
See if every subnet, every NIC has a network security group configured.
(18:35):
Check if there are any open ports, especially for virtual machines.
And this is there's some really easy things that can be done.
Jorik (18:42):
You bring up an interesting point with the virtual machines and then coming back to your home lab Jodi Going back to the next finish setup of a virtual machine, it will actually pre provision a public IP and if you're not careful it will actually open up the port 22 or 3389 which basically means you send out an open invitation to anyone on the Internet to just go see what's on your virtual machine.
(19:07):
Just imagine you host some kind of business critical application on there and you were not careful with your next finish setup.
Yeah, it's game over for you.
Bob (19:14):
It doesn't take long to crack a password, right?
Unless you're like Michael enforcing 48 character password generations.
Jordy (19:22):
You know that's true.
But you've talked about the firewalls and the ports.
Should I see those as low hanging fruits that are easily pick up on within your Azure environment?
Or are there other low hanging fruits that you are.
Well you just press next next confirm.
What's the first thing I'll have to do?
Jorik (19:43):
Yeah, so the firewall and the single point of ingress Bob mentioned, they are quite extensive improvements already.
They basically require you to redesign your whole entire network setup, preferably to some kind of hubspoke implementation.
Jordy (19:59):
And I assume you need some kind of confidence in what you are doing exactly at that moment.
Jorik (20:05):
Basically at that point every application needs to be reviewed just to make sure that everything can be linked to the hub.
For example, if you have overlapping IP addresses you're already in big trouble.
But there are some improvements you can do rather easily and as we already mentioned, selected networks is a big one.
Ensuring there is no public IP on your virtual machine, for example, ensuring TLS 1.3 is enforced on your storage accounts.
Bob (20:31):
For the storage accounts, maybe one for you.
Check if there is no anonymous access to your blobs that you're trying to make available because that will allow to People, if they go to the URL they can actually view the pictures or download pictures.
So be sure that no anonymous access is set.
Of course if this is a requirement for certain applications it needs to be accepted, an accepted risk.
(20:54):
But there are really some things that can be done as well.
Maybe for storage accounts as well.
Really try to avoid the SUS keys.
Yeah, they provide you a lot of access, possibly read or like God mode access to your storage account.
And something that's really somewhat annoying especially for the infrastructure teams is they are tied to the account key basically like the master password of the storage account.
(21:17):
And the thing is there's no way to be able to review if there are 1025000 storage account keys created.
The only thing that you can do is you can rotate the key but that breaks all the other keys that have been created.
So that's why we really tried to shy away from the storage account keys.
And really maybe one thing that is really important as well, try to stay away from local authentication.
(21:41):
And with that, I mean access keys or SQL authentication to the SQL database or Cosmos database for example, really try to use managed identities, try to use app registrations to leverage the Azure role based access control.
Because there really is a lot of support for these kinds of authentication and of course it is easy to use this local authentication but there really is a lot of benefit and really moving towards the role based access control.
Jordy (22:09):
Yeah, I should definitely look into it and the more I hear you talk about it I'm like oh shit, I haven't done this right or I haven't thought this through.
Even working for a security company, you know, it's your home lab.
But as more as you talk about it and indeed anonymous entry, I mean there are pictures of my kid in there.
(22:30):
I don't, I don't want them to be out there.
Bob (22:32):
So.
Jorik (22:32):
Yeah, and again once it works you're not going to look back.
No, no, that's how to improve the security.
And with anonymous blob access it will probably work.
Jordy (22:40):
I just, I just want to have the time to look back at it.
It's, you know, it's a project that once the project is done I.
Jorik (22:46):
I move on to the next one.
Jordy (22:48):
It's, it's one of many on the to do list.
So yeah, we've talked a bit deeper about the storage accounts.
You also mentioned the virtual machines.
I mean I believe most of the companies who use Azure definitely run virtual machines.
What are the first Things for them to look at once the virtual machine has been deployed.
(23:10):
I mean, one of the first things I would personally do is check if.
Does it have to be on 24 7?
Is there, is there a timing that I can schedule?
Are there other things?
Jorik (23:19):
Definitely.
And you bring up a very good point.
Scaling down the virtual machine at night, for example, when it might not be used, has two benefits actually.
So for one, it will reduce your cost because it's not running at night.
And then secondly, people can't attack your machine at night because it's just shut down.
Jordy (23:35):
And most malicious threats are from foreign countries, are from different time zones.
Russia, China, Korea, America.
So them being offline at night here in Belgium is like a big advantage.
Jorik (23:48):
Yeah, for sure.
And some of the other things I often see at customers is the local account used on the virtual machine is not looked after at all.
The policies we usually deploy to our customers contain some sort of password rotation for these admin accounts.
On the other hand, you might have a minimum password requirement, size and length or complexity to further reduce the risk of brute forcing on your virtual machine.
(24:14):
Because some of these machines have to be public.
I mean, you can't get around it.
But in that case there's other solutions, such as the single point of ingress, for example.
But securing your host operating system is a very important thing.
And making sure it receives periodic updates, patching latest security improvements sent out by Microsoft.
(24:36):
Because once you deploy a virtual machine out of the box, it won't get any updates.
So you have to make sure that there's an update management plan in place saying that these times of week it can receive these updates whether the machine has to restart or not.
And then if you have a machine that shuts down at night, hey, perfect.
Because then it also restarts, pulls in all the updates, and then it's secure against the vulnerabilities Microsoft has already identified.
Jordy (25:01):
And is it something we should only look at with virtual machines?
Or are there other, for example, applications we could use the same way to manage them?
Jorik (25:11):
So one important thing here is you have to update your own resources if they are infrastructure as a service.
But once you move on to the more Azure native services such as Azure Web applications or container apps, you basically reduce the need of having to do this yourself because Microsoft basically takes it over for you.
Maybe another takeaway for the listeners if you can please use these platform as a service components because they're way more hands off, they're way more in the direction of, okay, I can just deploy this here well, regarding some of the security configurations you always have to make, but in that scenario you can just dump your code on there and it will probably work.
Jordy (25:54):
And there's already a cost of inventing or investing money into security that is already taken off your hands.
Jorik (26:01):
Exactly.
Bob (26:02):
You're a lot less responsible as well for the resources.
Like Jorik said, you don't have to be bothered with patching or backup.
A lot of those features, especially in the past components, are already configured or taken care of by Microsoft.
So that's definitely a big plus, especially for the infrastructure team.
They can focus themselves on more, so to speak, important tasks or other pressing matters.
(26:26):
And something I heard at the customer as well last week on Wednesday is they said, yeah, if it has to run on a virtual machine, I'm just going to put it in my data center.
I want to work as cloud native as possible, especially in Azure.
There's just so much support for this and a lot of the developers are also very fond of this.
They don't want to log in to a virtual machine and click around the ui.
(26:49):
They want to just be able to provide them either with a script or provide them with a pipeline or help them out.
Creating their pipeline to automate the deployment to the resources, that really is an advantage because it's less work for the infrastructure team and it's less work for the developers because they don't have to be bothered with.
Sometimes it's also responsibility of the developers to do it securely and sometimes that's not a possibility.
(27:15):
So being able to unburden, so to speak, the developers as well, is really something I feel like they are very fond of.
Jorik (27:22):
And it's also an important part of driving the adoption towards cloud because people don't like change and so they're most likely used to what they run on premise and so pushing them towards cloud for whatever reason.
This might actually help because for a lot of certain Personas it's easier to adopt cloud technology and contrary to infrastructure as a service type of resources.
Jordy (27:47):
Okay, Bob, you also mentioned before we started the recording of this podcast that Microsoft announced something.
Maybe we should elaborate on that as well, because from what I've heard, it might have a big impact on some companies and I don't think they are always up to date about this because it's not always straightforward.
Bob (28:07):
Indeed.
So indeed what I read, maybe I spread a little bit too much of fear, but it is for new virtual machines, so that's a big nuance.
So luckily we're safe there.
But what I was saying prior to the podcast is that Microsoft, I think it was September 30, 2025, that there's not going to be any default outbound connectivity from virtual machines.
(28:31):
So then you will have to specify or create a route table to be able to route your data to the Internet specifically.
So that's really something well done by Microsoft to restrict the access and to force them towards that single exit point or single E point for your data.
I think that's something really important as well what we do and something you see as well.
When you try to create a virtual network, the first thing that you see is you get a slash 16 network range gets thrown at your face.
(28:58):
It's way too big.
You never need that many IP addresses like Joik mentioned as well previously, if you want to integrate this with other virtual networks, you get issues because you've got overlapping network ranges.
You need to resize them.
Sometimes that's not possible because certain ranges are already in use.
You need to making changes to virtual networks when there are already certain networking components like a network interface for a virtual machine, when these things are already present in the virtual network, making changes to the network ranges or moving them even is nearly impossible.
(29:30):
So it really is important to be able to think about those settings.
And what we like to do at the collective and our customers is we work with a default route like you know, it on premises or default networking setups.
We create a user defined route which basically overrides all the existing routes that Microsoft creates by default.
And we force all the traffic towards our Palo Alto, towards our checkpoint, towards our Azure firewall.
(29:54):
And we there explicitly whitelist all the required network traffics that is either it being in the same virtual network, it being connectivity towards on premise resources, either via VPN connection for example, or even access to other private Azure resources that might have been or that might be present in the environment.
(30:15):
Also I think the most important part is the Internet access.
So specifically for app services, they might have to pull from a container registry to be able to download Docker file.
We want to whitelist only specific URLs so that we ensure that if a hacker or a threat actor would be able to gain access to these applications either via code injection or SQL injection or something that they're not able to set up like a beacon or something like that they can communicate back to their home base, so to speak.
(30:45):
And really restricting the outbound access ensures that it really increases the security of the environment.
We talked about a lot about the inbound access to the virtual machines and that's obviously very important as well.
But ensuring that they cannot go back or download malicious code on the applications or the virtual machines is really also an important factor.
Jordy (31:04):
Yeah, it's great to mention as well.
That's why I brought it back up.
Maybe one question that popped in my head when were busy from a business perspective, as a ciso, I know a lot of companies are hybrid builds, not a lot of companies are still only on premise or are yet fully cloud native.
What is a big difference between making my on premise secure and my Azure security?
(31:26):
What I do believe there is a big difference and there are a few nuances that a lot of people are missing, especially because of the lack of IT profiles out there that can actually secure a Azure environment because they all think very on premise.
Jorik (31:43):
I think one of the main parts here is that on prem it's way harder to create a public service while in Azure, as you noticed yesterday with your home lab, it's super easy to create a service which is publicly exposed and open to the Internet, which this is something you don't really have on premise.
And on premise usually they have one Internet line or one ISP router, for example, which routes everything outbound or inbound.
(32:08):
But on Azure you can create a single resource which has its own ingress point, its own egress point, and is basically isolated all on its own, but still be able to connect to the rest of the resources.
While on prem you basically have an isolated network within your data center, you already have to kind of put in the effort to get it publicly exposed.
While on Azure developer you just want to try something, you just click together a web application, it just has a public endpoint right off the get go.
(32:32):
And this is something we should really be wary of in the cloud.
And so infra teams should find the perfect balance between giving the liberty to their teams on being able to create their own resources, but within some kind of boundary.
And so the infra team should really try to provide guardrails for their teams, which basically state, look, you really can't deploy any resources with a public endpoint.
(32:55):
We're going to block this through some kind of policy, for example, but then still have them be able to think for their own, see what they need, which resources they want to use, but then also allow them to actually deploy themselves.
Because in bigger environments, when you have, let's say 10 different development teams or 10 different consuming teams, if you have to create all these resources yourself, you're going to be in for a Hell of a ride.
(33:16):
You will also won't be able to monitor them all.
So you will somewhere require some kind of tool that tells you this resource is not really compliant to your standards.
What are you going to do about it?
And then you as an infra team will probably speak to the guy who created it and then be like, hey, this is not up to par with our standards, could you please revise your resource?
Jordy (33:36):
Isn't that something policies could really solve and yeah, for sure.
Jorik (33:39):
Yeah, okay, definitely.
And this is I think also one of the quick wins is find yourself a good policy baseline.
And it doesn't even need to be a deny or a deploy if not exists.
It could just be an audit mode policy which has no impact at all on any of your existing resources, but it will just generate you a very nice Overview of Look, 80% of your resources are currently not secure and it's usually a very big eye opener for security people within the company and a very big call to action.
(34:08):
And that's something we often see at our customers as well, where we usually get quite some reaction from.
And yeah, it's really a big step.
Bob (34:15):
Forward usually it's also one if we do assessments or we're starting to implement some governance as well at the customer like the policy baseline.
That's something we deploy as well because if you don't know that it exists, you can't act upon it.
And I really liked what Yogik said as well.
You need to be able to give the consuming teams the liberty to be able to play around and maybe badly worded but be able to configure the necessary things on their own because in bigger environments and then we go to more like a more DevOps mindset, more integration approach, the infrastructure team or the DevOps team needs to be a facilitator for the consuming teams and it can't be a blocking factor because then you will get annoyed people, you will get really the friction I was talking about and that's really important.
(35:00):
Something that really was important to me as well is that you said the Liberty.
But the difference between the Liberty in Azure and the Liberty on Prem is I think also a really big contrast because in Azure, and that's also a bit of the hard part about Azure.
Jordy (35:17):
It's a mind shift.
Bob (35:18):
It's a mind shift, yes, but also the connectivity and the connection with Entra id.
It's not because you use Azure that your Entra ID is configured as correctly.
So sometimes these users are added to the entra tenant for 365 or teams or whatever.
But if the Entra tenant is not properly configured, they might just have access to all the Azure resources as well and that really can cause problems.
(35:41):
So you need to set up the correct security configurations to be able to block off certain things in Entra, but also configure the correct access to specific subscriptions, preferably via privileged identity management to be able to give them specific roles or access to specific groups, or only time bound or check some multifactor authentication, et cetera.
And I think that really is also something that makes it easier in some cases and maybe in companies where there is less of an IT team, if there's really a big drive for business need and the company is developing, sometimes they haven't really, they don't have that beefy IT team yet that can provide the support.
(36:18):
And I really feel like that just rating something on prem will be a lot harder than in Azure.
Jorik (36:23):
Okay, and also to further drive the point Bob just made, sometimes there is the notion that their on premise is fully isolated of what's happening in Azure, but then they might either have some kind of VPN tunnel between both, not secure the VPN tunnel and then risk some kind of issue within Azure or some kind of break in Azure to then propagate towards their on premise network.
(36:45):
Say for example, they are very established and very mature on premise, but then they start trying out some stuff in Azure and then with all the points we discussed today, they just forget to disable some kind of public endpoint, then it routes back through the VPN gateway over to their on premise network and all of a sudden your entire business is compromised.
Another way to compromise it like this, for example, is if you have a virtual machine within Azure which is linked to your on premise domain.
(37:09):
This is perfectly possible, but if you then have Entra ID authentication on this virtual machine and you forget to lock down your Entra id, a malicious actor could just break into your Entra id, for example, log into the machine and then suddenly be domain admin, for example, on your on premise domain.
So it's very important to be wary of this.
Jordy (37:26):
Okay, yeah, it's a very good point.
Maybe we should, for all of our listeners who might be in an important role, manage IT manager, ciso, cio.
What are the basic things or keynotes they can take away from this episode and what should be the first things they can implement?
I imagine there are a lot of people who are having an Azure or after this episode are like, okay, I should do something, but where do I Begin.
Bob (37:52):
I think something easy and really low hanging fruit is deploying some policies to get some insight, especially if you're starting off and you have some bit of an Azure environment already, but you don't really have like a dedicated team that can control, so to say this environment.
Really get insight into what you have in Azure.
Try to see, okay, do I have a lot of web apps?
(38:13):
Do I have a lot of virtual machines?
Not only for the security of these resources but also like we've discussed the cost aspect because this can really open a lot of.
Yeah, what is still running?
Do we still need it?
And it's not only in regards to the cost, but also the security.
If an application has already been moved to another provider or something else, it has been decommissioned, something, sometimes there are still resources left, something that Microsoft is doing as well.
(38:36):
When you create a virtual machine, they have implemented options to be able to automatically delete the network endpoint and the disks as well.
For older machines this might not be the case.
So it's not because you delete a virtual machine, which might cost you €50amonth, but there still could be like a disk of like 2 to 3 terabytes which might cost you like €200 and you think, okay, I have deleted the virtual machine, but there might still be some lingering resources.
(39:00):
And then these policies and these workbooks really can provide amazing insight into the environment.
Jorik (39:07):
Yeah, one of the other points we've talked about today is very much try to work towards a centralized networking hub, as this will provide a lot of insight into what traffic is coming in, what traffic is going out, and even within your environment which type of applications or resources can talk to other applications or resources.
We both know that going to a deny all firewall from the get go is just not a possible feat.
(39:33):
And so what we usually do when we get into this type of situation is we just open up the firewall, any to any and then we check the logs to see what traffic is actually moving over the centralized hub.
And that way we are not a blocking factor from day one, but we kind of get to inventorize the different flows that are going over it.
After which we can then start to bring down the firewall and really start tying it down.
(39:55):
But then also from an ingress point of view, just trying to reduce the different ingress points within your environment to various different resources can drastically and will drastically improve the security posture of your environment.
Bob (40:09):
And if I can add to this as well, what we see as well something with our customers that are also making use of our security operations center is we really have a close collaboration with this team.
And for example, like Yogik said that those central egress, that central ingress points can really provide a lot of interesting logs for the security Operations Center.
(40:33):
They can spot certain misconfigurations.
They can spot certain, e.g.
kag Buggles or NTLs connections that should not be occurring.
For example, integration with the web application firewall on.
Org application gateway.
That really is crucial information to be able to stop a threat actor or even prevent them before they can even do anything.
(40:55):
And I really think, and that's something that we really want to drive home here is getting the insight into the environment is a lot more important than a lot of people think.
Jordy (41:04):
Yeah, the important thing I'm taking away from this is that next time I'm setting up an Azure resource, I'm calling one of you and not just clicking this wraps.
Also, also up the episode of today.
A big thank you to Jorik, to Bob for sharing your valuable insights.
And of course, thank you all for tuning in.
We hope you found today's discussion helpful.
(41:25):
If you did, don't forget to subscribe and share this with your colleagues, helping us reach more people who are just as passionate about building a safer digital world.
We'll be back next time with another important topic in corporate security.
Until then, stay vigilant, stay secure, and let's keep working together to shape a safer future.
Popular Podcasts
NFL Daily with Gregg Rosenthal
Gregg Rosenthal and a rotating crew of elite NFL Media co-hosts, including Patrick Claybon, Colleen Wolfe, Steve Wyche, Nick Shook and Jourdan Rodrigue of The Athletic get you caught up daily on all the NFL news and analysis you need to be smarter and funnier than your friends.
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com