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.