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 36. This week we have myself, Michael, we have Gladys and Mark. We also have a special guest, David Tregano, whose hits talked to us about Azure Defender for SQL vulnerability assessment. But before we get to David, let's take a look at the news. I'll kick things off.
A couple of things really piqued my interest this week. The first was based on an internal discussion that we had at Microsoft with some of the networking security folks on the Azure team. I'll be honest, I'm an app development guy, application security, security design, that sort of stuff is my main area of expertise. Security, when it comes to networking, is not an expert at all. So I'm always willing to learn new stuff.
So we had this internal discussion and the woman who was talking provided a link to the Azure networking ninja training. So I'm going to provide a link to that because the material is absolutely fantastic. Now the one is that some tools that allow you to perform network intrusions into Azure, so that you can make sure that your tooling all works, using a whole bunch of open source tools. So I'll actually provide a link to those as well.
Finally, just to keep your ideogenist and Sarah happy, I actually took SC900, which is the security and identity fundamentals exam. Pretty easy. It's an hour long exam. I actually got it done in 15 minutes. That being said, I think if you're relatively new to security in Azure, it's still well worth taking the exam. For no other reason to have another exam under your belt. As I've mentioned in many times before, I'm looking at taking all the 900 exams.
The next one on the cards is going to be the AI900. Then after that, I'll probably do the Power Platform 900. I think that's PB900, it's P-something 900. That's all I got. This is Gladys and I'm going to be focusing in this session on government. Microsoft has been releasing a lot of documentation that is geared to answer the executive order on improving the nation's cybersecurity.
Many people are familiar with the original order that was released on May 12, 2021, which was focused on government organizations. But there's also a memorandum that was released for improving cybersecurity for critical infrastructure control systems, which includes energy, nuclear, wastewater, management, system sectors, emergency services, healthcare, transportation, financial, commercial, and many other organizations as well.
Because there are so many organizations that need this guidance, Microsoft has been creating a lot of blogs, documentation, and even newer capabilities within our products to address the requirements in 2021. Some examples include the Zero Trust 3.0 book for Sentinel mapping. This is one of the guidance that is recommended to address requirements for the EO or executive order. The Azure Security Benchmark maps requirements to the NIST SP-853.
There's a lot of guidance being published also in the cyber EO section of the Microsoft Federal page as well. So please be in the lookout for the documentation and capabilities being released. I will put several links in our podcast site as well. On August 16th also, we announced the general availability of Azure Government Top Secret. This shows the Microsoft commitment to the mission of nation security. Currently, there are over 60 services, but more are coming soon.
This is close to the same amount of the services that we have in Azure Secret, which is 73. The blog also talks about data unification and services interconnection strategy, which is something we keep consistent within all our clouds. Thanks. From my side, a couple updates, mostly in the training readiness education space. The first of the videos that we recorded, they're actually formatted as interactive guides. So I think computer-based training where you click next and back for concept.
So the first versions of those are out for the cyber reference architecture. So the three that we released recently are the main capabilities diagram, the people diagram that talks about roles and responsibilities, jobs to be done, and a third one is the zero trust user access. And so those three are rolled out and available publicly. So I'm putting the links in the show notes there for y'all to check those out.
These particular videos, there's some more coming, but these particular videos are focused on folks that are a little bit more new to security, new to security technology, new to Microsoft's capabilities. We do have some coming that are a little bit more oriented towards folks that are familiar with the cyber reference architectures and have seen previous versions of the videos, but these are more for the folks that are a little bit new to it.
There's definitely some interesting information there for all audiences, but we really tried to help those folks that are a little bit new to the space with this particular set of videos, or interactive guides rather.
The other thing that I wanted to reshare because this is something that a lot of people aren't sort of used to coming from Microsoft is we have some ninja training, ninjas just our Microsoft terminology for the nice sets of training, a whole complete set of training to help you become an expert or a ninja. The defender for IoT one is the one I want to highlight, and I'll include a link for that in the show notes as well.
What this is is for our operational technology, also known as SCADA, Super Advisory Control and Data Acquisition, ICS, Industrial Control System. It goes by a lot of different names, but ultimately OT is the technology that computers that control physical machines, physical processes, taken data from sensors, et cetera. So that security technology we have for securing those environments, often 30 to 50 year old crusty electronics is out.
So, how Microsoft can help you secure that and how to use it and how to work with it and how that whole space works at large. So I wanted to highlight that for folks as well. Okay, so now we've got the news out the way. Let's turn our attention to our guest. This week we have David Tregano, who is here to talk to us about as you defender for SQL vulnerability assessment. David, welcome to the podcast. Would you mind spending a moment just explaining what you do to our listeners?
Sure, hi everyone, hi Michael. Thank you for inviting me to the podcast. So as you said, my name is David Tregano. I'm a product manager working on Microsoft. My actual job is to ensure that our customers are well protected using Azure Defender for SQL and specifically SQL vulnerability assessment that we will talk about it in a minute. And more personally, I've been in Microsoft for seven years. Interesting history because I started my journey at Microsoft as a Microsoft student partner.
So MSP, it's kind of MVP before students when I was in France, so 2008, 2009. And then 2010, I started as an intense software engineer working on Microsoft France. Then I moved to be a ADM, so application development manager. I came to Israel five years ago, still working on Microsoft as an ADM. And two years ago, I moved to a program manager slash product manager here in Azure Security Center. Thanks for that.
So just so our listeners are aware, this is kind of the second part of a two-part series. Last time we had Michael McLevich to talk to us about as you Defender for SQL Advanced Threat Protection. And so this is the second half now. So David is gonna cover the other part, which is the vulnerability assessment.
David, would you mind just spending a couple of minutes just explain what the vulnerability assessment side of the house looks like and what's sort of the philosophy and the goals behind that part of the product? I think when you look over the security posture or the security lifecycle of a resource, you have this reactive alert that you're receiving when a malicious user access to your database or when there is malicious activities in your database.
But you have all this proactive side of this lifecycle, which basically contains of scanning your databases, discovering misconfigurations and vulnerabilities and highlighting those misconfigurations and vulnerabilities, allowing our customers to fix them and remediate them before something bad happens to the databases.
So I think bottom line, this is what VA stands for, scan databases, proactively discover misconfigurations and vulnerabilities, sending these findings into a centralized place that is called Azure Defender for SQL, or should I say, Azure Security Center, part of the CSPM side of Azure Security Center. So CSPM stands for Cloud Security Posture Management. So basically, Azure Security Center has two aspects.
The first one is CSPM, as I just mentioned, Cloud Security Posture Management, allowing customers to understand the security posture on their environment, receiving recommendations and best practices from Microsoft. Not only this, but these are the big pillars of the CSPM. And what we call the second part is the CWP for Cloud World Cloud Protection, which basically you can translate it into the ATP sides of the Azure Defender plans.
So ATP for SQL, ATP for containers, ATP for VMs, et cetera, et cetera. So which versions of SQL Server are protected by VA? Basically, we do like to say that we are protecting any type, any flavor of SQL. So you can have Azure SQL Database, Synapse, Data Warehouse, SQL Managing Instance. You can have also SQL Server on-prem. You can have SQL Server hosted on an Azure VM.
So as long as you are, as long as we are supporting this SQL version, so it's basically SQL Server 12 and higher, so 12, 14, 16, 17 and 19. We also protect SQL Server that are hosted outside of Azure, so as I said, on-premise, but as well any other cloud provider. So it can be AWS, GCP, IBM, or AcuraLy by the cloud.
We are basically considering these are servers that are hosted outside of Azure, and we are of course protecting those flavors of SQL, those cloud providers, regardless of where they are, or what is the version, as long as they are hosted on the Windows operating system, we do protect them.
So last time when we spoke to Michael, he did mention AWS, and I thought, perhaps that means we have some special connector to AWS, like to allow SQL Server to run inside of a VM, say a Windows Server 2019 VM, and you just mentioned AWS, GCP, Alibaba Cloud, IBM's Cloud, Oracle Cloud, so what's actually going on there? Obviously it's not restricted to just AWS, and like reading between the lines, it sounds like we don't have like some funky connector out to AWS.
So basically for us, we do consider any cloud providers as a single cloud provider, for us it doesn't matter where the SQL slash the underlying operating system run.
So as long as you're using Azure Arc, or as long as you're using an RMS agent, we are basically able to connect your machine into Azure, and as long as the machine is connected to Azure, then we have the ability to proactively detect misconfigurations and vulnerabilities using SQL VA, and detect malicious activities using SQL Advanced Threat Protection. So are there any port requirements to gather telemetry?
For the RMS agent, it's the port 443 that needs to be open, and for Azure Arc, so Arc and Archie, so Archie means for a Azure Arc SQL enabled, so it's the extra piece of technical implementation that Microsoft built on top of the Azure Arc agent to detect automatically the SQL server and connect the SQL server as well into Azure. This is something that you need to check within our documentation, but of course, this is something that we document.
So a little later in the podcast, I'm gonna ask a question about sort of vulnerabilities you look for in configuration of a SQL database. But before I get there, and I really like your opinion on this, both from a technical perspective and that sort of philosophical perspective, SQL databases are kind of interesting beasts, right? Because you've got this sort of shell around the database, which is very, very sort of windows-ish, like if you're installing this out of a VM.
So for example, I can store it as a service, it can run as a specific account, I can change ACLs on objects that are in the file system, and so on. And then I've got, say, Azure SQL DB, right? And so around it, I've got all the Azure stuff, so I can deploy it with an ARM template, I can use a little F firewall and do port restrictions, and so on.
But then when you get inside the database, you've got all these things that are unique to SQL databases that require protection, and they're not exposed to windows directly, they're not exposed to Azure directly. So examples, we include things like, you know, various roles that are unique to SQL databases, or one, you know, very commonly used sort of security pattern with SQL databases is to deny access to underlying tables, and then grant access, say, through store procedures or views only.
I mean, this is a very interesting nuance that exists within SQL databases. Do you have any thoughts about, you know, what sort of stresses or difficulties or potential complexities that might bring to someone administering and protecting these databases? Absolutely, so you're raising actually a good concern, or I say you're raising a good matter that applies only, or should I say, actually exclusively to SQL, maybe you have this within some other OSS databases.
But in fact, within SQL, I think Microsoft made something that nobody made over the last few decades, which is taking an on-prem relational databases and try to lift and shift the database itself to be a pass application. So what you have here is kind of inception, you know, like the movie where you have dreams into dreams, and here it's the same thing. You have this resource within a resource.
So you have, as you said, you have this SQL database that sits inside a SQL server, that sits inside a virtual machine, that sits inside the cloud, which is very, very complex to manage because you have multiple personas, as you said. You have the security administrator that is here to apply and to configure policies and security policies around for the organization.
You have the IT guide that in charge of managing the virtual physical server, and then you have the application owner who is in charge of ensuring that the data is here and available and accessible and reliable. And then you also have the DBA that is in charge of ensuring that the SQL answers at scale and is reliable in terms of infrastructure, not the data itself.
So you have all these people that are actually dealing, I mean, you dealing with all these people to secure the database because database, it's not secured like, okay, just hit next, and you configured and you secured. You need to understand what is going to be the business impact when you change a configuration. You need to understand what's the security impact if you do not change a specific configuration.
You also need to take into consideration that all of these guys, all of these personas within the organization are not talking the same language, they're not using the same tools. They don't know the same products. They don't have the same agenda. So basically it's a world with a lot of frictions. And I think even from a product perspective, it's something that drives us a little bit crazy.
I think it's a real challenge from a product point of view, how you put all these people into the same room, collaborating together on improving security, posture related to SQL, without forcing them to do something they don't want, they don't understand, they don't like, it's not part of their duties, it's not part of their day-to-day journey. It's something that is interesting to explore. And even when we talk with customers, every customer has its own view about it.
You will have customers that will say, okay, I have a bunch of DBAs that are managing my on-prem databases, while I basically move to a more agile model, like I have resource owners and application owners that are managing my pass applications and pass resources.
So you have people that are managing storage account and Cosmos DB and virtual machine, and SQL on pass and on IaaS that are dealing with the same product, the DBAs that are working for years and years on the same SQL server, just upgrading three or five years after three or five years to the next version. And these people are not, as I said, talking the same language. So I think that these are the biggest challenges we are dealing with.
It's an interesting one because at the end, I think customers have the same goal, like help me to secure my SQL server, help me to avoid receiving thousands, if not more alerts a day, help me to ensure that my sensitive data hosted on my SQL, because we all know that SQL stores sensitive data. You don't have a SQL server if you want to store pictures.
You have SQL servers because you host information related to your customers, information related to your personal IP, information that helps your application, that is your money maker to help and serve your customers. So SQL is probably one of the most important pillars within organizations today. And I think that's a real challenge. How we help them to be secure without forcing them to do something they don't understand. This complexity must lead to interesting compliance issues.
How are we helping customers to balance security and compliance? I think security and compliance, I used to say that security and compliance used to, I mean, should work in a better together mindset. So if you talk with security guys, they will tell you that they should lead security and security should lead compliance. If you talk to compliance guy, they will tell you the opposite. Like compliance should lead security.
If you talk to people that are dealing with FedRAM, CIS, GDPR, or any other benchmark that we have today in the market, and God knows how benchmarks we have, and every week or every month, we have new benchmarks popping around the world that telling you, hey, now you need to deal one to three, or you need to act like one to three in case of data breaches, or security auditors, et cetera, et cetera. So that's something that SQL VA tries to connect.
So if you look in SQL VA, when we have rules or findings, we are trying to tell to our customers and users what is the associated benchmark to that rule. So in case they have auditors coming from FedRAM or CIS, they can generate reports, or they can tell, hey, you know what? These are all the rules that I passed that are related to FedRAM or CIS, or even STIG, which is the DOD benchmark that is being used across all the US governments.
So, yeah, I mean, if I'm summarizing, I think, security and compliance should help each other, but I'm sure, Michael, you have all the thought about it, but it's a very complex question that is, and again, similar to what we said about the challenges around securing SQL databases. Every organization has its own opinion and its own process about who is leading, is it security, is it compliance, is it a better together? So it really depends on the organizations we are working with.
Yeah, I do have a couple of comments about security and compliance. I want to point out, security does not equal compliance, and compliance does not equal security. And like you say, they can work hand in hand, and they should work hand in hand. But historically, I've found that customers recognize that they have to meet compliance requirements.
Say, for example, PCI DSS for handling credit cards, or HIPAA high trust for health care, FedRAM for federal customers, GDPR for European customers, SOC2, all these, all this alphabet soup. So they know they need to be compliant, and they need to be compliant with these various programs.
One thing that we've done that's actually worked really, really well is when we're building threat models for customers, so they're taking an application, and they want to understand what their security posture is so we can build a threat model. I mean, it's obviously looking at things from an application development and design perspective. But one thing we've done is actually mapped the mitigations that are in the threat model onto compliance programs.
And that's actually worked really, really well. It kind of ends up being a rosetta stone between the compliance folks, the architecture folks, and the security folks. And so that works really well. The only last little thought I'll leave is we've actually managed, this sounds a bit cynical, but it is what it is. We've actually managed to unlock funds for customers to drive security programs by using compliance programs to help drive some of that security work.
And again, we found threat modeling has a really good way of mapping between those various disciplines. So yeah, I think compliance is obviously critical. We do a great job of it, I think, and as you're in terms of being able to show people their security posture through Azure Security Center as it maps to various compliance programs. And I think anything that goes through ASC is always a good starting point.
I wanted to add a comment about what you mentioned of security not equal to compliance or vice versa. Unfortunately, lately, technology is moving so fast that actually not even compliance or governance is keeping up with the technology. And that is adding some interesting challenges to many customers because they're implementing all this technology, but the process, the procedures, the compliance document talk nothing about these new services.
And unfortunately, it's becoming really a pro block for implementation and use of this technology. So I wanted to ensure that a customer understand they need to update this documentation in order to take full value or full use of their investments. Yeah, absolutely. I think what you just said, folks, it's absolutely correct. I think we need to...
It's an interesting time because we are living a cloud world for the last 10, even 15 years, but we have customers that have started this journey of moving to the cloud and implementing, as you said, Gladys, some new technology processes and applications. And I think that security and compliance need to be associated, but not only associated. They need to be well-understand and digested. So they understand what are the common points and what are the differences that they must take care of.
Something I wanted also to double check and pay a little bit more attention is something that I mentioned in the beginning of this podcast, which is the CSPM within Azure Security Center, so for cloud security posture management. It's great that we're talking about compliance because compliance is also something that is part of CSPM, Cloud Security Posture Management, within Azure Security Center. And this is something also customers are integrating part of their posture management.
As I said, all the secure score, all the recommendations that are sold by controls within Azure Security Center, how we can help customers to understand how secure they are against Microsoft's best practices within Azure, but also outside Azure. We talked also, Michael, about this multi-cloud approach that Microsoft is, and more specifically within Azure that we are going through.
Having the ability to help our customers not only to protect their Azure resources or to improve their security posture within Azure, but how we can also help them to improve their security posture and not only for SQL, not only for Azure, but everywhere.
Customers and organizations more and more have a multi-cloud approach and CSPM specifically within ASC tries to help customers to get into a single go-to location, which is Azure Security Center, and control a visibility on how secure your resources and applications are across your organization, regardless of where those applications and resources sit. So one of the advantages of Microsoft services is the interconnectivity that it provides between services.
This enables the customer to have wide amount of signals from both Microsoft services and third-party services. So what is the type of information that you're feeding into Azure Security Center? So in fact, what we are basically sending slash feeding into Azure Security Center from a SQL VA perspective. So we basically have two recommendations within the CSPM area, allowing customers to see all the misconfigurations and vulnerabilities are across their SQL.
So this is a question that I alluded to earlier in the podcast. So what kinds of things does SQL vulnerability assessment actually look for? I would say that we are of course focusing on security. So if you have misconfiguration and I can think about the most famous one, which is the SA, the default login that's being generated when you deploy a new SQL server.
This is something that is being well-known and used by malicious users and attackers, and I'm sure Michael doing the previous podcast spend times talking about it. This is what we see mainly on different attacks and patterns being used by attackers across SQL. Basically, the technique is super simple. Customers are basically deploying SQL server. By default, they have this SA user that is being enabled. Basically, they have to set up a password to this default user.
They are usually taking a weak passport, like passport with capital P, W, O, and capital D, some basic password like this. And malicious users are basically boot-forcing this SA. So this is the first misconfiguration of the vulnerability that we are looking for. We're also checking if XPEComancial is enabled. So for those who are not familiar with XPEComancial, is a capability within SQL, SQL server, allowing DBAs or users within the SQL engine with enough permission to run a DOS script.
So script on the underlying operating system. So you can think about how powerful this capability is if it falls into a malicious user. So you can connect and run a remote script from the internet. You can deploy CryptoMiner. You can deploy Run Somewhere on the underlying operating system. And this is something, and these are not theoretical examples. These are real examples we are seeing every day, unfortunately, with customers and not only small customers.
I think on the internet, you have news popping every day talking about cyber attacks on big organizations, worldwide organizations that are, their SQL, their storage account has been compromised and data has been extracted and sensitive data has been leaked and exposed to the dark web. So these are the famous one. We also have the ability to check for updates, for example.
If we see that there is some CU for cumulative updates on your SQL that been released and you didn't install them, then we have the ability to automatically highlight you all the SQL servers that you must install the latest update. And of course, SAX decommensual, we have the ability to highlight or to surf us all the misconfigured SQL in a single recommendation. I think that was your previous question what we actually feed into AC.
It's not only those misconfiguration, it's also the ability to aggregate the configuration of any SQL server you have or customers have within the organization and their environments. Again, regardless of where the SQL server run, we have the ability to aggregate all the misconfigurations into a single recommendation, giving the ability to security owners and security administrator to prioritize their SQL according to the criticality of the SQL.
If you have SQL that are in production that are a customer facing, you can very quickly search for that SQL into the recommendation and check what's the configuration or should I say, what are the misconfigurations on that SQL? If we found that there are too many users that have excessive privileges on the database, we can highlight to those users and ask you, hey, do you know those users?
And our customers can say, yes, all these users, we know them so they can set up what we call the baseline on these users allowing SQL V8 to say, okay, as long as this list doesn't change, for me, everything is going well.
When a new user with excessive privileges will be created within that database, I will automatically highlight that change into this ASC recommendation, allowing the security administrator to automatically understand that there is a change on a specific database and pay attention to that change and mitigate or at least say, okay, this is a valid user, just add this user to my existing baseline. So I think these are the things or this is how SQL V8 works and search for.
Important to mention that we are always adding new rules. We are always improving existing rules. We have different rules for different flavors of SQL. So of course, if you're running an Azure SQL database, we are not going to check if XPEC Commentshell is enabled because this is not supported in Azure SQL DB. If you're using a SQL server, we are going to check some rules that are not supported on the Azure SQL database.
If you're running a SQL managed instance, we have a set of rules that apply to each of these flavors of SQL. So it's a tool that is not generically built for SQL, but we tailor made it for every flavor of SQL to ensure that we are covering any potential misconfiguration on any flavor of SQL currently being supported by Microsoft. Actually, you beat me to the punch there. I was going to point out that XPEC Commentshell is not available on the Azure SQL DB.
You don't have access to the underlying operating system. And also even on-prem, XPEC Commentshell is disabled by default, but certainly customers do enable it. That's the case and I think people need to understand the risks. I mean, it's a great deal of functionality, but with that increased functionality comes a great deal of responsibility as well. Absolutely. I think it's important also to explain that, as you said, not all the misconfigurations are enabled by default.
Microsoft does not provide you SQL that is not well configured, but I think we are basically giving you this out of the box SQL server. While we know that security, and I think this is something that we are always saying for the last five years is that security, it's a shared responsibility between software provider or cloud provider in our case and the end user. A lot of organization that deployed Azure Defender for SQL came to us and say, hey, I deployed Azure Defender for SQL.
Why I'm still receiving alerts? They thought that deploying Azure Defender for SQL is this kind of, you know, antivirus or firewall that stops everything like Superman. And it's important to understand that at the end, Azure Defender for SQL is a powerful tool, but it's still a tool. It's not a real human.
It's going to change your configuration because at the end, only the organization are the only one who knows why exactly they need to change this because it's not going to hurt their application, their business, their processes. And we are here to highlight those misconfigurations, but probably we, I mean, we have organizations that enable the expect commensurate because their applications that run on top of SQL requires that capability.
So they basically came to SQL VA and apply the baseline on expect commensurate for some of their databases, saying, as long as expect commensurate is still enabled, hey, you know what, consider it as acceptable for my organization, but it's only on some specific databases, you will never see organizations that deploy or enable expect commensurate on all of their environments that are usually deploying or enabling expect commensurate on few databases within their organization.
And this is where SQL VA becomes super important because we have the ability to tell you, hey, you know what, we found all this expect commensurate. You tell me that on database number one, two, three, this is the expected behavior, but you know what, I found 100 databases that somebody deploy or enable the essay or the extra commensurate or did not install the latest here.
So you should pay attention to this potential misconfigurations of vulnerability before someone malicious user or attackers will use that vulnerability against you. This is an important point. I could have say a hundred SQL databases and I could just say, hey, that one database over there requires XP underscore command shell. It just does. So don't keep warning me about that one database. But if it pops up in any of the other 99 databases, I want to know.
So that's essentially what you just said. Is that a fair point? Yes, absolutely. So we have the ability within SQL and a bloody assessment to make what we call a baseline tool. So we allow customers to set the baseline, which means basically as long as this finding result does not change, consider it as a healthy finding, as a healthy configuration. Regardless of what you Microsoft think best practices should be, just don't bother me too much about it.
On this specific database, this specific finding is healthy. This is the expected configuration. Now, as you said, if something change, let's say that I don't know, I have five administrators on my database. For me, these are the right administrators that I must have on my databases.
Now, if there is a new administrator that's being add on my database, please let me know because I want to identify if this is a valid administrator, if this is a valid user, if this is not a malicious activity that somebody access or lateral movement of a malicious users that basically trying to extract the data from one of my database. Let's focus a little bit on separation of privilege. There's a lot of interesting data that are beneficial for different type of group.
What kind of data, what kind of access that those DBAs or other roles have? So that's a good question. I think separation of privileges or separation of duties depending on who you're talking with, but these are similar terms that are basically saying the same thing is how we ensure that we are not giving too much privileges or too much access to a single user within the organization.
It's something that we do consider within Azure Security Center and more specifically in SQL vulnerability assessment. So because we are an Azure product we'll build on top of Alba. So yes, so of course, if you are a DBA that has access only to the database, then you won't see the scan results within Azure Security Center because your AID user doesn't have enough permission on Azure Security Center.
On the other way, if you are a security administrator on Azure Security Center, but you don't have access to the database, then you will see the misconfiguration, but you won't be able to mitigate or to investigate those misconfiguration. And I think it falls again, the friction that we have between all these personas that are dealing with different tools and permissions and agenda and languages and platforms.
The DBA is used to work with SSMS while security administrator are mainly using Azure Security Center, where the SOC team that are dealing with the alerts coming from SQL, LTP are mainly dealing with SIEM application, SIEM platform like Azure Sentinel. It means a lot. It means that we have all these users that need to work together and to collaborate while working on different platforms with different permissions.
So what we did is giving the database security role or should I say, allowing the security database administrator in case you have this permission, this role on the database, then you can basically see the scan results. So if you have enough permission on the database itself, on the engine, and if you have enough permission on the Azure to see the scan results, then you will be able to do everything.
But if you're only a DBA, just to answer to your question, then we do not expect you to see the results within Azure Security Center. Actually, I'm gonna go one step further. It's not that we don't expect you to see the results. We don't want you to see the results at all. I think that's critically important. Every customer I work with, especially in regulated industries, are really interested in separation of duties.
In fact, going one step further, people who are doing, so for example, SQL Server supports Rural Level Security, but it also supports the ability to have security officers who can manipulate the Rural Level Security rules, because they're essentially a predicate function. It's a little bit like a store procedure. They can write that logic and set up the logic and set up the policies around it, but they have no access to the data.
They also have no access to, as your security center, scan results. They also have no access to Key Vault secrets used for, say, always encrypted or column encryption. So SQL Server actually has some really good capabilities. And the Azure platform in general has these fantastic privileges or abilities, I should say, to support separation of duties or separation of privilege. With that, let's start to bring this thing to an end.
David, one question we always ask all our guests is if you had one final thought to leave our listeners with, what would it be? I'm usually starting my conferences with a sentence that I really like that comes from John Chambers, that said something that I really like. He said, there are two types of companies. Those that have been hacked and those who don't know they have been hacked.
And I think SQL VAs, SQL VA and SQL ATP that are basically bundled into a product called Azure Defender for SQL, comes to solve that equation. Like if you have SQL Server, if you are using SQL within Azure, outside of Azure, within AWS on-premise, regardless of where you use it, try Azure Defender for SQL, scan your databases, allow us to help you to find misconfigurations, vulnerabilities, help to you to understand how to fix and remediate those misconfigurations and vulnerabilities.
And in case something happened on your database, we can also highlight you and send you alerts to let you know that there is a malicious user or malicious activities in your databases. David, thank you so much for joining us this week. Really appreciate you spending the time and know you're incredibly busy. I certainly learned a bunch as well. I've been spending a lot of years with SQL databases, but I always learn something. So again, thank you so much for turning up this week.
And for our listeners, thank you so much for listening. Stay safe out there and we'll see you next time. Thanks for listening to the Azure Security Podcast. You can find show notes and other resources at our website, azsecuritypodcast.net. If you have any questions, please find us on Twitter at Azure SecPod. Background music is from ccmixter.com and licensed under the Creative Commons license.