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 35. This week is myself, Michael, Gladys, and Mark. Unfortunately, Sarah can't be with us this week going to time zone problems. We also have a special guest. We have Michael McElvish, who's here to talk to us about Azure Defender for SQL Threat Protection. This is part one of a two-part series.
Part two will cover Azure SQL Defender vulnerability assessment, but that will be on in our next podcast. But before we get to Michael, let's turn to the news. I'll kick things off. A few things really took my interest over the last few weeks. The first one is the ability to configure applications with application configuration and Key Vault.
The purpose of this is that you can store some sensitive information in app config, and then the super sensitive stuff such as encryption keys, and the like can be stored in Key Vault. App config can seamlessly access the Key Vault on your behalf, which is absolutely brilliant. Next one is part of the YouTube video from the Microsoft Machine Learning Team. It's entitled, Securing Machine Learning Environments on Azure Machine Learning. This is pretty important.
I mean, if you have models and data that is used as the input to machine learning, it's critically important that that data be clean and correct and not tampered with. This video goes through some of the best practices around securing ML data. I also spotted a Microsoft Identity Learning Path. I'll give a link to that. I'm a died-in-the-wall security guy, and even though I know some of the basics of identity, I don't pretend to know absolutely everything.
I found this learning path incredibly useful to fill in some of those knowledge gaps. In fact, it's led me to spend quite a bit of time really getting into the bowels of OAuth 2. I wouldn't recommend that, but I found myself spending quite a bit of time again, pulling apart OAuth tokens. The last thing is that we now have general availability for private link with the Azure Managed HSM. A managed HSM is essentially a Key Vault, but there's different backend hardware.
It's a FIPS 140-2 Level 3 validated hardware. It is not a shared resource. This is your own individual HSM. For the most part, it's a very specialized piece of hardware that's used for very specialized requirements. My general guidance here is, if you don't know what that means, then you probably don't need it. But the point is it's now got private link support, which is nice to see. This is Gladys and I wanted to talk about the ransomware detection that has been added to Azure Sentinel.
As you may know, there has been many capabilities that Microsoft has added to our services to try to prevent the loss of data such as OneDrive and Exchange, saving any data or deleted files or mailboxes for 30 days, SharePoint backing up every 12 hours and retaining for 14 days. Retention policies or even litigation whole can be set within Office 365 which preserve data. E-discovery and content searches can be used in the discovery or recovery of that data.
Azure backups can help backup the data sources and VM run in Azure. But how do we speed up the detection of possible attempts to do ransomware? Well, many groups within Microsoft including the Microsoft Thread Intelligence Center or Mystic have collaborated to create Azure Sentinel Fusion detection for ransomware. Basically, alerts that are potentially associated with ransomware activities are correlated together within this Fusion Machine Learning model.
If something is detected, it triggers a high severity incident title, multiple alerts possibly related to ransomware activity detected. The correlated signal used by this Fusion Machine Learning model confronts services such as Azure Defender or Azure Security Center, Microsoft Defender for Endpoint, Microsoft Defender for Identity, and Microsoft Cloud Application Security. I am really excited about this capability since it really shows the power of a well-integrated suite of products.
Although in this case, the integration happens within Microsoft products, Microsoft services have capabilities of integrating with many third party vendors. If you missed a previous postcard where we talk about these, I recommend looking at the Microsoft Graph and other integration capabilities within our services. Those podcasts have really good information.
When it comes to ransomware, the one thing to remember is that time is the most important factor in minimizing impact and possible loss of data. The sooner alerts are raised to security analysts with the required details on various attacker activities, the faster the ransomware attacks can be contained and remediated. The next thing that I wanted to talk about is a blog title ensure compliance using separation of duties checks in access request.
It talks about the separation of duty checks feature that are now in preview in Azure AD Entitlement Management, which helps prevent user from acquiring excessive or incompatible access rights. An example given is that auditors may know one person that is in the sales department to be able to change accounting data, or maybe they don't want IT auditors to also be an IT administrator.
The separation of duty prevents user from receiving this type of combination of permissions that could lead to misuse. The last news I wanted to share is the Azure Security Center compliance over time report. This is a way to see changes over time on applying the proper compliance requirement. A couple of things caught my attention this week. The first is something I actually contributed to a long time ago when we did the first revision of this.
We have this incident response reference guide was what we put out, and it was in a downloadable PDF and we converted that and modernized it. That's out there for folks to learn a little bit of Zen and the art of how to respond to incidents from a process design perspective and a philosophical perspective, and how do you think about shaping that so that you're effective on it? A lot of good advice, a lot of hard one lessons learned from our dark team, IR team, and many customers as well.
The other thing that I wanted to talk about and share a little this week, it's a little bit of good news because one of the things that's always frustrating to me is, how much our industry is so splintered with different points of view that are selling products, or this or that, or in different ways. We always end up with this chaos that lands on customers, or Microsoft's customers, that people have to figure out, what is the truth amongst all this noise?
One of the things that was inspiring for me a little bit was, I was part of the NCCOE, the National Cybersecurity Center of Excellence, Zero Trust Ever that NIST is hosting. We got to see pretty much all the different vendors share their point of view on Zero Trust. It was as diverse as you would imagine it, it might be with all these vendors and different security product makers providing their points of view.
The cool thing was, is that I started to see that NIST diagram started to become a central theme as everyone mapping their stuff to it, and it created a level consistency. A nice glimmer of hope there that Zero Trust will help our industry become a lot more consistent and a lot more, which of course helps you execute well because you're not arguing over details that aren't as important.
The other thing that occurred to me lately, I'll do this as quick as I can, I started to see more and more how important it is for security to really look at itself through the lens of being a part of the business, and really partnering much closer with the business lines and the functions of the business.
One of the things I started to realize that has, I think is at the root of a lot of the challenges that we experience in security organizations, is that the accountability really isn't in the right place.
When you think about risk, like something goes wrong or goes right with your car or whatever it happens to be, you own all the good and the bad of it, where you park it, how fast you drive it, etc. But when we look at security and an asset from a business point of view, oftentimes anything that could go wrong normally, pretty much lands on the asset owner in the business,
except for security. We're going to blame the security guys for that, because that's obviously a technical fault that these smart humans did stuff. We often see this blaming of the CISO and blaming of the security organization when something goes wrong. We're talking 30 to 40 or 50 years of decisions were made when security wasn't important, and whoever in security now inherited that. So it's really not really that fair, quite frankly, to put it on security and own that.
It also drives bad behavior because if I don't have to own the security outcomes of a decision as a business asset owner, then I'm going to take a lot more risks than I should, versus if I actually own it, I'm going to think about it a lot more carefully. That doesn't mean we're just going to dump the responsibility on these business asset owners and say, you figure out the cyber, because they don't know.
But the more that we can security professionals be a bridge, and or rather build a bridge and help educate them and help them understand in their terms, what cybersecurity really means to them, and learn their language and communicate, I think much better off we will be in cybersecurity in the short term and the long term. So just a couple of thoughts there. Well, now we have the news out of the way. Let's turn attention to our guest.
This week we have Michael McLevich, who's here to talk to us about Azure Defender for SQL Threat Protection. Welcome to the podcast, Michael. Michael, do you want to give our listeners a little background on what you're doing, how long you've been at Microsoft? Thank you, Mikhail. I've been at Microsoft for three years now. All of the time I was a product manager for Azure Defender for SQL.
It's been rebranded a few times, so maybe you remember it is Azure's Advanced Threat Protection, which is catching attacks. You bring up an important point there. We will have a follow-on to this in September, where we will talk about the other pillar that's not being talked about today. So before we get stuck into this, let's welcome a little bit of a historical perspective as to what this product does.
I mean, amongst many other things, and please correct me if I'm wrong here, but a big part of what this product detects in real time is SQL injection vulnerabilities. Is that a fair comment? Yes. I think SQL injection is one of the attacks that we catch with the Advanced Threat Detection. But for sure, it's one of the most popular and famous SQL related attacks.
But it's also a pretty interesting attack because you're attacking, like you don't need to breach credentials or users, something like that to exploit SQL injection. You're doing that through an interface that is aimed for inserting data. The data is just not cleaned properly, but it makes it pretty unique. We have also other families of detectors. We are working on adding new detectors. From a historic perspective, I think SQL injection for a long time was our flagship detector.
Yeah, and just to add a little bit of context there. So back in the day, I worked on our web server, IIS. Obviously, IIS was used to front-end hundreds of thousands, if not more, SQL server instances. One day I got an email from this guy who went by the handle of Rainforest Puppy saying that he'd found this class of vulnerabilities through IIS, even though the vulnerability technically wasn't in IIS or SQL server technically. It was in the way custom code was written to query the database.
That was my first baptism of SQL injection vulnerabilities. Yes, that was Rainforest Puppy. In fact, RFP and I have actually hooked up again after all these years. His real name is Jeff Forrestal, a fantastic guy. But yeah, I was on the front lines there with cross-site scripting, SQL injection, memory corruption, file name canonicalization problems back in the day. I'm sure that's probably bringing back PTSD for a few people out there.
But I have a long history with preventing SQL injection vulnerabilities. Back to the product itself. You want to give us an idea of what versions of SQL server this thing protects? Yeah. We protect all the SQLs in the Cloud. That's the first. Azure SQL servers, SQL databases, managed instance, SQL servers that are inside the Synapse workspaces used to be SQL data warehouses. We also have only thread detection without Azure and ability assessment currently for open source databases in Azure.
It's not exactly SQL, but it's another plan that we have. Azure, like protecting the Azure Postgres SQL, Azure MySQL, and MariaDB. Also, in the last year and a half, we realized when you protect a database, you don't want to only protect a database. You want to protect your entire environment and your entire data environment. We spread it also to hybrid environments and outside of Azure, protect SQL servers 2012 and above, in on-premise on Azure VMs, Amazon EC2s.
Going back to the previous question, we started already in the Cloud area. I think a lot of protection and data security solutions started way back then at the on-premise era and now they're trying to move into the Cloud. We started in the Cloud. Our first product was Azure Defender for Protection of Business for Azure SQL servers. Then we realized that customers are not doing or only on-prem or only Cloud, they're choosing hybrid environments. So we moved that also those.
An interesting fact that we realized is that attackers have sometimes different targets. One target which is maybe the more obvious target, everyone is calling data the modern crown jewels. So when you protect SQL, it's obvious you're trying to protect the data. We're trying to exfiltrate the data, and they're trying to take the data out and then lock it in some ransomware manner, and just sell the data stuff like that.
But when we got ourselves into SQL servers on-prem, we also realized another interesting pattern, that is attackers are trying to attack the SQL server not to gain access to the data, but to gain access to the machine. SQL servers on-prem, and they're these big and strong machines with lots of configuration, which might confuse a few people, and they're sometimes hard to update or to change because they require a lot of expertise.
What happens there is that attackers try to brute-force all SQL server machines and using commands like XP command shell or the ability to write registries from the SQL to the Windows. They're just jumping from the SQL to the OS layer. Then they're starting things like crypto miners, run somewhere attacks on the entire machine. Actually, you bring up an interesting point there about XP underscore command shell and tweaking the registry. I think it's important to understand that.
I think it's important, our listeners understand that those features are not there in the Azure native, the cloud native versions of, say, Azure SQL DB. This is an important point because XP underscore command shell, for those of you not aware, is a way of essentially invoking anything from any command shell. So command.exe or whatever you need to run from within the context of SQL server.
That can become quite dangerous actually because if you've got a SQL server running in an elevated environment, let's say it's running as a system, which by the way, you should never do. But let's just take a pathological example and say it is. Then in theory, XP underscore command shell is now running a system. That's a very serious vulnerability. Now, the cool thing is that in the PAS offerings of Azure SQL DB, that feature is not there. It's not that you can turn it on, it's just not there.
Same with other features like being able to write to the registry, that feature is not there either. The other aspect which I think is critically important is, on-prem SQL server, you have complete control over what identity that process runs as. Whereas in the case of when it's running in the cloud, you don't. All our PAS offerings run at least privilege. They always do and you can't configure it, you can't change it.
So these are examples of something we've often referred to as the shared responsibility model, where some things are managed by Microsoft and Azure and some things are managed by the customer. This is a really good example of where we're handling some of the default configurations. So you don't have to and you don't potentially run the risk of making a mistake and exposing this as you point out, you're exposing this compute power to attackers because those features are just not there.
Yeah. I couldn't agree with you more, Michael, on how important it is to look at that shared responsibility model profile and favor the cloud because it is much better. But I also love that the SQL Defender capabilities are also hybrid because no matter how much you love the cloud and you want to get there because of that lower risk, you do have to always secure the enterprise you got.
So I'm a huge fan of this. I've been following it ever since the SQL Defender ATP or whatever it was called and it when it launched was out there. I'm applying UVA technology, the SQL injection detection. So yeah, love it. So when Michael and I were talking about this earlier in the week, he mentioned, I didn't even think about this, but using SQL Server is essentially another step in the road for pushing out ransomware and being and using the compute power of these databases as crypto miners.
Is that something that you're seeing or heard of much around SQL databases being used for ransomware? So we saw it especially with all the SQL servers and sometimes it's interesting because you see customers that they decide what to protect on based on the sensitivity of the data that is in the database or if it's production or not production. But when your goal is a crypto miner, for example, you don't care about the data in the database or if it's production or not production.
CPU is a CPU for you. So it's an interesting example where you have a component and that someone is thinking of protecting only parts of it or protecting it only if it makes some criteria in the gain function that he sees. The customer wants to protect only the data. He says, all right, there is no production data there. There is no sensitive data there. I want to protect the SQL server.
Then the SQL server is being breached and the SQL server itself, as we mentioned, doesn't have any interest in the pressure or bounty for the attacker. But from the SQL server, you can go to the compute power and run a crypto miner or start a lot of movement inside the network. Think to circle back to your point. So those are great points and I didn't mention why we started seeing those attacks all in on premise because in Azure, they are all blocked.
To be fair, you always need to talk about security together with productivity. It's always a fine balance between those. But I think it's also really important to remember that a lot of times what is comfortable for you is also comfortable for the attacker. So we see a lot of customers that indeed, I think as you said, Xp CMD shell, the ability to run commercials from the SQL is by default off also for SQL servers on RAM. Starting some year, I don't remember at which point.
The idea here is that customers sometimes prefer to go, I would say, the lazy way or the simplest way and use this tool, although there are other alternatives. But that's exactly what attackers also want to do. If it's comfortable for the customer, it would be comfortable for the attacker. If the customer can easily run things on the machine, so the attacker would also want to run things easily on the machine. And we didn't see it happening not too rarely. Unfortunately.
Yeah. You know, I remember when it was turned off, when it was turned off by default in the on-prem version of SQL Server, because I was actually involved, actually sort of actively involved in many of the conversations that led to that decision. And my somewhat flippant but serious comment was, look, when you've got a feature in a product where the number one user of that feature is the attacking community, then perhaps it's time to turn that feature off.
That wasn't the only thing that was turned off. It was XP underscore command shell, but also common support was turned off too. So that way, you know, people weren't writing com objects, you know, if you're doing SQL queries. We talked about PaaS versus IaaS. So this, as you mentioned before, this protects all versions of SQL Server, both on-prem, those running, say, AWS in EC2 instances, as well as our PaaS offerings, like as you see called DB and as you see called managed instance.
And you also mentioned the productivity aspect. I think that's always important as well. What else, what other things, you know, can this is product do? What other classes of vulnerabilities does this tool sort of detect? All right. So we have a few classes. One that we already mentioned is, of course, SQL injection. Our flagship for a long time also. Now we can maybe circle back to our SQL injection algorithm. And it's pretty interesting one.
It's, we have a few patterns for it and it's more interesting than the basic looking for one equal one. For those that are familiar with SQL injection. We have a family of UEBA, which is, which stands for a user entity behavior analysis. When we find anomalies in the communication with the database or the activity of the database. We have another algorithm which became kind of a family is the brute force detector, which we involved into having three layers of brute force.
And that's also an interesting story. And we have a threat intelligence algorithm based, which are coming from the vast, pentatonicus that Microsoft is collecting also by itself and from customers and from vendors. And we're using all this data to alert you when there is a suspicious IP is approaching your database. When I first saw this feature, one of the first things that sort of sprung to mind was, how does this work? I mean, is this something that runs in the SQL server process?
I mean, do I have to pay for the compute? Do I have to, you know, am I going to see a performance hit from running this tool? All right. So this is a great question. And it comes back again to the productivity or some kind of productivity versus security. You know, the most secure SQL server would probably be a brick, but you can't do much with the brick, right? There is always some fine balance. In the cloud, you actually pay nothing out of your performance, compute, stuff like that.
It's all running in the background. And so this is another great plus for the cloud. You just enable it and you can enable it or on the SQL server level or through Azure Security Center on the entire subscription level. They just protects all your SQL servers and that subscription. In the background, we have our own compute side by side with your compute, but it doesn't affect you. It's also very not intrusive.
It's reading the queries, the logins after they're happening and analyzing if there are any attacks. For the SQL servers on machine. And so the story is a little bit different. There indeed you need to install an agent and our analysis is running on your machine. So it takes part of your compute and part of your memory. We're always doing tests for that. We are always monitoring for the community of protected customers, what the situation is there.
And when we do deployments, we always check our standards there. Like for SQL servers on-prem, we don't have much of another option. You would always pay something out of your compute. We're trying to make it as minimal as possible. And we're aiming for less than 5% on average. But of course, and I don't want to promise you anything, it really depends on your payload. It can be much less as much as there is much less to go from 5%.
And it might be more really depending on the workload that you're on. Michael, so can you explain a little bit how the telemetry comes through? Is this interconnected into Washer Security Center? How is it shown? In the cloud, it's very easy. The telemetry, we get it from the background process. We started as part of the Azure SQL team. So there it's really nicely handled and you don't need to do anything. The detections themselves go to Azure Security Center for the on-prem version.
So there again, the situation is always a little bit more complicated. And we get the telemetry from the Log Analytics agent, also known as OMS agent. That's the current solution, that's the solution that used in Azure Security Center for a server telemetry. So we wanted to make sure all aligned there. The detections and alerts themselves go to Azure Security Center and can be exported and go from Azure Security Center as any other alert.
And that's in general, a really important principle for us, to just keep every of the defender solutions aligned with the broader scope. So Azure Defender for SQL is trying to be as similar in the management point of view to Azure Defender for servers, Azure Defender for storage, Azure Defender for app services. So a last thought from me. So, I mean, how quickly can this tool respond when it detects anomalous behavior? I mean, what sort of time frames are we looking at here?
All right, that's a great question and exactly a point that we're working on a lot lately. Our SQL injection detector is real-time detector. Our UEBA detectors take some more time and also the computer is done on our pipelines to not stress your machine currently. And you need to build a model, right? You have a lot of data to process there. So it used to take us around 20 minutes in average to alert you about anomalous behavior. And part of that pipeline was our brute force detector.
We realized that letting you know about brute force 20 minutes after it started, it's way too late, doesn't allow you enough time or doesn't give you the right time to detect to respond to this detection, which is what really matters to us. So we did a lot of work lately and we took our brute force detection down from being around those 20 minutes to less than a minute. So currently brute force detections and SQL injection detections are real-time detectors.
And we're working also to bring the other ones closely as possible to light detections. The idea with brute force is that now you can use other hooks in Azure Security Center and workflow automation to just block the brute force in the IEP out of the network and not allow it to continue. Before we wrap this up, I just thought about something.
When you were talking about Azure Security Center, one of the nice things about feeding into Azure Security Center is that there's no extra education that's needed to learn some new tool. You can use all the reporting and reporting abilities and alerting abilities that are in Azure Security Center. I mean, my guess is you could probably even open up a ticket with ServiceNow or something, right? You could even export it to your scene. Is that a fair comment?
Yeah, for sure. So you can do all of those things as you can do them for all the alerts in Azure Security Center, even raising the bar here. So if you already have some connector that opens every Azure Security Center for Server alert in ServiceNow or sending every Azure Defender for Storage alert into your scene solution, if you would now enable Azure Defender for SQL, it would be exactly the same experience, right? This is the same scheme, the same connector. It's really extendable.
So yeah, you don't need to educate your people again. And all the automations are really smoothly moving on. So if you decided to start with only one of the Azure Defender plans and then go to the others, or you started with all of them and just want to turn on one, you started with a few relevant and there are the new ones that coming out. Everything is just fit in. You are part of the same family, you are part of the same suit. So yeah, it's a great comment.
I've been learning a little bit about the integration. Does that mean also since we're talking about Azure Security Center, is it giving guidance as part of the secure score or ways for the customer to know that certain capabilities are not enabled? So I'm focusing on a SQL thread detection. We do have some integrations between the alerts and the recommendations. In the alert page, you can see the recommendations on the same resource.
You can have a resource context, which is also something really strong that we have in Microsoft. And some other alternatives can't obtain because they don't have the old cloud context. But I'm not sure what you meant with the secure score here. It's just as part of threat protection that I have seen for other products. Sometimes in order to reduce the risk, we provide guidance.
And I didn't know if SQL, the threat protection portion, basically surface data that guidance as part of secure scores on where else in Azure Security Center. Oh, so yeah. So as we started, there are two pillars for Azure Defender, threat protection, for Azure Defender for SQL. Thread protection is only one of them. We have the threat protection capabilities and the vulnerability assessment. The ability assessment is used for hardening. It goes into the security score.
You can find it among the other recommendations in Azure Security Center. And that gives you the guidance of how to avoid those attacks. We're talking about learning from that threat protection. And I guess we're going to hear more next podcast. Yeah, that's the plan. Hey, Michael. So one thing we ask our guests is if they had one final thought to leave our listeners with, what would it be? Only one last thought.
All right. I think I would say that a nice insight is to think about that attackers don't just want your data. They sometimes also want your data. But for sure, you need to protect your data. It's a multi-layered approach. You need to protect your data. You need to protect the compute benefit. And you need to protect the whole environment and care for the hygiene of your data environment to make sure the data is not stolen and the compute under it is also not stolen.
Hey, Michael. Thank you so much for joining us this week. We really appreciate you taking the time. I know you're very busy. But again, I learned a great deal. It's always good to sort of go back into talking about SQL injection vulnerabilities even though this particular feature does one heck of a lot more than just detecting SQL injection. And to all our listeners out there, thank you so much for listening. Take care 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 azuresecpod. Background music is from ccmixter.com and licensed under the Creative Commons license.