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 107.
This week is myself, Michael, with Sarah and Mark.
Our guests this week are Max and Emily to talk about Purview Blueprints.
But before we get to our guests, let's take a little lap around the news.
Sarah, why don't you kick things off?
Sure.
So just one piece of news.
The MVP Summit has been announced for March next year.
So if you are an MVP and if you're not, why are you not?
Then you should go to the MVP Global Summit.
It is on the 25th of March in Redmond.
So if you're an MVP, make sure you go sign up and go because it'll be pretty awesome.
And everybody I know who's gone has really enjoyed it.
So that's my one little bit of news this time.
Okay.
I only have one little piece of news and it's from my old stomping ground in SQL Server.
SQL Server Management Studio version 21.
There's been a new feature.
A new feature has been added for always encrypted.
And this allows you to essentially do an assessment on what you want to use.
Like, how do you want to use always encrypted?
And it'll look at your data, make suggestions, say if there may be some issues.
It's been one of the, I'm not going to say adoption blockers, but a thing that makes
always encrypted a little difficult is just knowing how to sort of use it upfront.
And so this always encrypted assessment really takes away a lot of that friction, makes things
a lot easier to know what data to encrypt and what sort of keys to use.
Okay, Mike, what do you got?
So again, my area, what I've got is a couple things that folks I found very valuable on
LinkedIn that I wanted to share some links with.
The first is for the Microsoft CISO workshop.
There's a sort of this hidden gem, as it were, of how to think about security metrics and
for the overall organization and know these aren't sort of how many times you're attacked
on the firewall or whatnot.
They're actually meant to overcome that and get you thinking strategically about how good
you are at preventing stuff versus responding stuff versus are you slowing down the business
organization you're supporting and are the continuous improvement projects moving forward
each month.
So we'll send a link out to those there.
And then there was also some mappings between the Microsoft capabilities and technologies
and the guidance and some of our workshops and how they help you sort of bring a zero
trust vision to life using the open group zero trust reference model standards.
So I'll go ahead and share some links to those in the show notes.
All right.
So let's turn our attention to our guests.
And as I mentioned at the beginning, we have two guests this week.
We have Max and Emily who are here to talk to us about Purview Blueprints.
So Max, welcome Max and Emily.
Welcome to the podcast.
Would you like to take a moment and introduce yourself to our listeners?
Yeah.
Hi everyone.
So I'm Emily Blundow.
I'm part of the CXE Cat team, which is our customer facing side of the product group.
I'm specifically working on our Purview for AI product features, which is all about expanding
Purview data security capabilities to AI applications.
Looking forward to today.
Thank you.
And my name is Max Bombadier.
I work in a similar team as Emily.
I am focused on data security and helping customer deploy.
All right.
So let's get stuck into this.
So whenever I see the word Blueprints, the first thing that comes to mind is Azure Blueprints
with a capital B. Is this them or is this some other kind of Blueprints?
I want to make sure that no one's confused here about whether this is part of the Azure
Blueprints or it's something different.
Thank you, Michael.
It's not.
It's no direct relation from a feature standpoint or product standpoint.
It is if we had to make a comparison, I would say it's closer to the WAF or the architecture
framework.
So it's more of a documentation approach on how customers can leverage best.
They're attempting to solve similar challenges, hence the term Blueprint, but it's there to
provide you a solid foundation on how to get started on whatever scenario the Blueprint
is addressing.
So to be sort of more specific, is that it's a lowercase b Blueprint as opposed to Azure
Blueprints.
Okay.
For the upper case b.
Okay.
Fantastic.
Thanks.
We're not productizing this, at least not yet.
Okay.
So what's the problem that you're trying to solve with these Blueprints for Purview?
What's kind of the point?
I think there were a few different reasons that came together as to why we started this.
The core challenge is Purview has multiple solutions.
Sometimes they work together, they integrate together, sometimes they overlap as well.
And we had a lot of questions about how to deploy.
I mean, at the base of this is how do we use the products available in Purview?
And then it got compounded with some of the other questions we would get is as we think
of solutions such as data loss prevention, information protection, insider risk management,
and so forth.
How do they start integrating and touching to each other into where a data loss prevention
or DLP admin may not consider some of their components of insider risk, for example, and
how really it works best together?
So at the base of this, it was truly about providing a good foundation for most organizations
to start their deployment journey.
And then it grew into what other scenarios can we try to solve?
So there's a lot we can expand from the tactical aspect and we'll dive into this in a little
bit.
But outside of that, the core is helping customers deploy at scale with the Purview solutions.
So if it is essentially best practices and documentation and what have you, so how actually
is this delivered and what are you actually delivering?
Yes, so we're delivering this on Microsoft Learn.
We have carved out a section on Microsoft Learn to have a voice of engineering.
Think of it as notes from engineering where we can provide best practices with proven
practices on deployments that we've done with customers.
It is backed by both the RCXE team, so Emily and I and the rest of our team, as well as
product marketing, product feature PMs as well, working with us to define what are the best
practices and then it's delivered on Microsoft Learn.
The small nuance compared to the existing docs that exists, I like to describe this
as the technical references that we have on Learn describes a lot about the features.
It's the what of the product, whereas the Blueprints is trying to solve the how do we
do it.
With the Blueprint, we have three different things that we're outputting with each of
the different Blueprints that come out.
Maxine touched on this a little bit.
The first one that we have is the Blueprint diagram.
That's really our why.
It's going to showcase what the scenario is, what the problem we're trying to solve is,
and then beyond that, we have our Blueprint slides.
So this is really showing the list of activities that need to be done to solve that scenario
that we're showing in the Blueprint diagram.
And then for even more detail, we go over to the Microsoft Learn documentation, and
that's going to show you how to accomplish each of the activities that are listed out
within the Blueprint.
With the method that we've taken to write this, it's been a fascinating process.
When we think of the Blueprint slide, the single slide has been a very powerful visual
because in one page, we know the list of activities taken to address that scenario.
But it's also been powerful for us as a team, or multiple teams in fact, to go through this
and how do we make this concise?
We've got some amazing products and features.
How do we make it simple?
It's something that can derive from a single slide.
And that turns out that this Blueprint is a great format for the table of content of
the detail guide after that.
So as we attach this, the narrative is for most people to be, whether that's technical
resources in the field, someone who wants to present to executives, someone trying to
as an admin to do the work, to just take on that presentation and know how to re-present
that to others.
I see the Blueprint slide as a takeaway.
We come out of that meeting, this is a list of actions we've got to move on to.
Can you explain some of the actual scenarios?
I mean, we've talked about what the delivery is, but we haven't really touched on yet what
the actual material covers.
What scenarios does it actually cover?
Yeah, I can touch on the first one and then I'll pass it off to Maxime.
So one of the Blueprints that we produced was an oversharing Blueprint.
How this started was throughout a number of customer conversations, I was continuously
hearing that customers were stopping their copilot deployments completely because of
oversharing concerns they were having.
At that time, we didn't really have the guidance that would fully cover how to address those
oversharing concerns that they had.
It needed documentation that was more scenario-based rather than documentation that was on features
or specific products, especially because with this scenario, it would require multiple Microsoft
products to accomplish the goal.
I knew Maxime had started the scenario guide, so I decided to give it a shot with the Blueprint
template that he built and it did really quickly become a hit with customers because as we've
touched on, it's really easy to digest.
It includes multiple products into just one story and it gives step-by-step guidance for
the best practices.
So yeah, that first scenario that I had tackled was about addressing oversharing concerns.
And oversharing being essentially taking something that could be sensitive and divulging that
through some kind of prompt.
Exactly.
Yeah, you got it.
The outcome is fantastic of the Blueprint that Emily worked on because this is making
you comfortable in leveraging M365 Copilot, ensuring that you prepare your environment
for it in a very quick and efficient manner.
What's also very interesting is this is not a SharePoint or an M365 or a Purview separate
initiative.
It's one that's joint across all the teams together.
So truly giving you one Microsoft list of things you can do to address in this context
the oversharing for Copilot.
And as we evolve the...
So the other scenarios that we've published back in September was it's called secure by
default with Microsoft Purview data security.
And the purpose of that one was twofold.
First of all, was to reframe the narrative.
The problem statement was that information labeling takes months, years, some time to
deploy.
And as we were preparing for Copilot and talking about more thinking through features that
we're going to have to help you, again, address the oversharing piece, we also need to ramp
up how quickly we label at scale in organizations.
And what secure by default does is flipping that narrative of, well, labeling is a sticker.
The label is a sticker itself about protection and what protection mechanism are attached.
Something like confidential all employees that is very intuitive for users to know.
And what the blueprint tackle was just, first of all, that reframe of positioning labeling
the correct way.
It's not necessarily just a peer classification method.
It's about protection.
And how can we provide you methods to label most documents that you have in SharePoint,
OneDrive, your emails, and on endpoints as well.
So how do we do that at scale with different approach to accelerate and moving in from
the old crawl, walk, run approach that would have taken you multiple months or sometimes
a few years and move that into how can I do this in less than a year?
How can I possibly do that even faster?
And similar to Emily's experience, we've had meetings where we had been blocked for multiple
months where progress was not progressing on deployment.
And you showcase this again with a blueprint as the takeaway with CISOs in a room and simply
in single meeting being able to unlock, move forward with a plan, a strong plan with the
list of activities that they know how to get to it.
They will adapt the timelines, of course, based on the organization size and their capacity
at what pace they can move.
But outside of that, it was an extremely powerful tool to help unblock and get to deployment.
And just maybe as an extension, so those are the two that are currently published as of
now.
We have a few other ones that are in the work.
So we're thinking through deploying DLP across any workloads that we support in Purview is
the bigger one that's going to be out there in the coming months.
So targeting Q1 in 2025.
We also have more tactical scenarios, something like reducing false positive with advanced
classification.
We're going to have deploying insider risk management policies.
We're going to get in even for insider risk or IRM policies, we're going to go into more
tactical something like just for Gen.AI, for example.
So key scenarios that we hear from customers that we should give them the quick steps on
how to address that.
So it's going to be a mix of Uber product or solution deployment down to I want to protect
source code type scenarios, like something much more tactical.
So you're absolutely speaking my language with sort of the customer outcome thing, because
that's like one of the things I'm always talking about is, you know, ultimately, technology
solves people's problems.
It's not technology for technology sake.
So I love that.
I was wondering if you could actually dig in a little bit deeper on kind of the secure
by default thing and kind of how you think about that and how y'all are approaching that.
What was interesting to see, everybody followed is a bit of a buzzword in one shot.
But at the same time, there's a methodology on how we can actively do it.
And now this can be broken down into products up to a point.
But in context of the first blueprint, what we've done is reshape the thinking of labeling
to what if the default label that's out there that's used for most information is protected
by some means.
And what I mean by this is I give options into at least at the minimum, you should have
DLP on it.
And you can have DLP on content is labeled versus DLP on content that is not labeled.
And what's your strategy with information that are both labeled or unlabeled to start
training user.
So that's the flip or second super important point here.
Training users to manage exceptions and sharing is an exception.
External collaboration is an exception.
Training them at that point for that action is a lot more easy for them to grasp what
is needed than trying to train users on when to secure.
So that whole notion of secure by default is sort of putting the efforts on where and
when do we train users and in this context of labeling, it is about what if every time
I create a document in SharePoint or OneDrive, that document is automatically labeled to
something like confidential all employees.
And I have DLP policies that says I'm not able to share this externally.
It is for confidential all employees.
And this could be, again, you can also have DLP on not labeled just to enforce or reinforce
to the users the need to label properly before sending it out.
And then you can keep the rest of the traditional DLP strategy on top of it.
But the key focus here is what if that information can be protected.
And I say DLP first, then the second part of the conversation would be or second option
could be do we encrypt it?
And the target should be to be able to encrypt this in the long term, understanding where
it has impact when you do encrypt or not.
So one of the example that we do have with customers addressing this is they're going
to start the journey of securing by default with labeling as soon as it goes in SharePoint
and it's encrypted so that users makes a decision when they need to share whether that encryption
needs to be removed.
So I actually think that's a very important point that you make because I've been spending
a lot of time on the secure future initiative these days.
And one of the pillars of SFI is secure by default, but it's very much an Azure specific
thing, rolling out products that are secure by default.
So for example, endpoints require TLS, for example, right?
You can't turn it off.
I mean, that's an example of secure by default.
Or perhaps using TLS 1.2 and above only.
That's another example of secure by default.
But your scenario here is essentially around data loss prevention and how to put policies
around information and data so that it's not lost and bring default configuration settings
in place that enforce that by default.
Is that what you're aiming at?
Did I get that right?
You are.
And that's where the magic of combining information protection, data loss prevention, and insider
risk management comes well together.
When you look at this from a single set of solution, rather than three silos in three
different teams, and most often in an organization, that's how we can address it best.
And I think that's why I'm layering also, if you can have a default that's encrypted
everywhere, that's great.
But I want to give you an ability to also work with sort of the slider between security
and collaboration is always sort of the tug here that we get.
How do I make sure I'm not breaking your regular or existing business process tomorrow?
So I want to make sure that I give you some possibilities to have adoption and options
to configure that.
So it's at the base layer, a lot of organizations have stronger requirements to secure more
in SharePoint and OneDrive, for example, than they have on Endpoint.
We can meet that.
And we can meet it with DLP, we can augment this with information protection, where if
you do provide a mean to...
Well, so it becomes encrypted, but it provides a mean that if it goes out, your protection,
your information is protected where it goes.
And then the third pillar of that with insider risk management is great because now I also
forced an action on the user when they need to share, they need to change the label.
They can do that at the file, they can do it at the site to manage scale of multiple
files, but it's also an audited action.
And then that's where insider risk management can become very interesting because now you're
looking into the behavior of the user.
If they're doing this at scale, they're now risky users and it can have further DLP policies
to block them more.
You know, it's funny, being a cryptographic nerd, I'm always a big fan of encryption or
cryptographic controls on data because if it is leaked, then it's encrypted.
You often hear people say security is only as strong as the weakest link.
It's actually not true at all.
If you have, for example, as you noted before, encrypted data and that data is compromised,
as long as it's encrypted, the attacker just gets ciphertext.
And that's why we often refer to these things as compensating controls, right?
It's there to compensate for weaknesses elsewhere in the system.
So I'm a big fan of things like encryption or just cryptographic controls in general
around data and having that be the default because that way if it is leaked, then I'm
not going to say it doesn't matter.
It does matter, but it doesn't matter as much as it being plain text that has all the product
plans for your next two years.
So yeah, that's good to see.
That's right.
That's perfectly the reason why we're doing it like this.
And the reason why I'm also giving you the options is I recognize that some organizations
have a lot of light of business applications.
It could be a system of record that does not yet support encrypted documents or does not
support MIP or information protection encrypted documents.
So giving you a little bit of that option, I would say that's why the min bar for this
is the default documents that you're creating should be prevented by DLP to go out without
content inspection.
And if you can get that in from a user training perspective, then we're forcing on a user
to make a choice when they need to exfil whether it's legitimate or non-legitimate ways of
exfiltrating the content.
So we're forcing the user to make an action first.
So on the information oversharing, so what were the drivers behind that?
Why do customers want that?
Yeah.
So with oversharing, as I mentioned a little bit earlier, we were having these customer
conversations where our customers were trying to deploy M365 Copilot and that deployment
was being stopped because there were these oversharing concerns that they needed to address.
And similar to what Max was touching on in terms of the secure by default blueprint,
we took a similar approach with the oversharing blueprint because a lot of those common causes
we were seeing of oversharing in Copilot deployments is all about setting the default sharing across
the entire organization through using links that share to the entire organization or sites
that were positioning or permissioning for sites, permissioning for all users within
an organization.
We took that same secure by default approach by setting the default instead to private
for sites.
We chose to limit entire org sharing links.
And then as with the secure by default blueprint, we're utilizing sensitivity labels to either
allow or disallow Copilot access to files.
So it's still that same approach of securing by default to address the oversharing concerns
in a Copilot deployment.
I have a cynical view of this.
No, no, no, no, no negative, just cynical.
Yeah.
So this is from personal experience.
I'm a huge fan of secure by default.
And there's a reason for it.
If you've overshared some data because you don't have a secure by default environment,
the cat's out the bag.
I mean, it's gone, right?
It's much better to have a default secure configuration that is secure out of the box.
And then if a customer needs to loosen the screws, they can do so understanding the risks
versus shipping something where we rely on the customer.
Hey, security of this is completely up to you.
I would much rather we go from our perspective, knowing the product very well and how it works
to have a secure configuration, which then if it doesn't meet the customer's needs and
they can loosen the screws.
But we do need to give them the ability to loosen those screws if they have to because
you can't block the business.
But at least it's better to have something secure out of the box that is not going to
just start leaking stuff all over the internet in the case of some kind of exfiltration.
So my hat's off to you for doing this because I think it's incredibly important.
Yeah, absolutely.
You're exactly correct that we want to make sure we're setting default security, but allowing
the option for efficiency as well.
So it's all about choosing the default being private or choosing specific users to have
permission, but then your end users will know when they can increase the permissions there
and have the options to send or share with more people.
I'll say one last thing and then I promise I'll hand it over to Sarah.
I would much rather have a support call from a customer who said, hey, how do I enable
this business scenario because I'm not having a lot of luck with it because of the default
configuration versus a support call that's, hey, I got whacked and all my data is all
over the internet.
Now what?
That first scenario you can control.
The second scenario, best of luck controlling that.
The damage is done.
That's just my opinion.
I'll hand it over to Sarah for her question.
Actually, I'd like to react to that.
Go for it, Max.
It's been key, so that statement, it resonates so well to why we've done security default,
but also the second statement that I said about training users to manage exception.
If you take the example that you had that you get a support call because a user tried
to expel something, they try to share something, it's not working, and you explain to them
how they can do this securely, they're going to remember this action.
They're not going to call support again.
So not only are you more secure by itself, but you're also training on when they should
do that operation.
It's a reminder too for them that these actions are an exception.
They're tracked, they're audited, and they're secured in the cell.
The key here is trying to train users, and we've seen this internally as well at Microsoft.
We've been teaching on when to label for years, yet we could have done a better job on labeling.
Auto labeling itself can only do so much.
In typical percentage, we see less than 3% of documents would be auto labeled.
This is for your highest sensitivity stuff.
Something like confidential all employees, and that's why we reframed that, is how can
we get that by default and move on?
We're doing the same thing for DLP.
So if I can share some of the thinking there on the blueprint for DLP is traditionally
it's open by default for most organization, and then they look for specific things they
want to block.
So you're essentially relying on your security for a few admins to think of all the scenarios
they should block something.
Well what if the strategy expands that a little bit on closing down some vectors completely,
thinking of a strategy on conditions that are contextual.
If you think of a...
So the label on label, it was one example.
It could be, what's the strategy for file types, file size, and just funneling down
the risk into what's left to do content inspection and then allow sharing.
So it's a fundamental shift into how we think and shape policies.
And just as a close off remark on this, what's great is the mix of simplification of your
policies.
It reduces the burden on incident management, but ironically it makes AI better on your policies
and what we see for a copilot for security, for example, to do an even better job on helping
you identify where there is a gap.
How can people actually use these blueprints?
Because well, we've already touched on why you made them, but what would be your advice
to someone who thinks, hey, I should probably look at these.
What do I do?
Where did they start?
For the oversharing blueprint, I would personally suggest starting by using the blueprint diagram
or guidance.
So the diagram itself really gives you an idea of what we're trying to solve for in
each of the different blueprint scenarios and how we're going to solve for it.
After you've seen that blueprint diagram and the overview, I would move to the detailed
slides that we have to learn what you're going to do in each of the stages of the guide.
For the oversharing blueprint itself, it's going to be broken into a guide for E3 customers
and then a guide for E5 customers.
So you can choose the one that's relevant to your organization.
For some customers, they may have already gone past the point of the pilot or the deploy
phase.
So I would try to get an understanding while you're looking at the diagram and the slides
of where your organization is in a copilot deployment to know where you need to start
within the blueprint.
Once they have that general understanding, you can then move to our detailed guidance,
learn documentation.
That's going to actually walk you through how to take each of the steps that are in
the guide.
Maxime, anything you'd add on to that or thoughts from your side with the secure by default
blueprint?
It's very similar.
I would say starting with consuming the content is the first go-to.
What we're also doing is we're ensuring that all the Microsoft teams, the scale teams,
so if I think of FastTrack or your cloud solution architect that may be assigned to your account,
are all trained with the same blueprints in mind.
What are the foundations that they should teach you about, for example, with the blueprints?
They will be able to nuance some of the writing into what does it mean for you and your organization.
We're also doing this with a number of partners that have taken the blueprints as their foundation
on how they help customer deploy.
I think there's a few options there available to you, but between consuming the content
and leveraging scale teams and partners is a great way to start.
Fantastic stuff.
Love the approach, love the way it helps people connect to the technology capabilities and
actually get value out of it.
Big fan.
Now, let's switch gears just a little bit as we get ready to wrap up.
Let's talk about y'all.
What's a day in the life of a Max or an Emily like?
Let me ask that of each of you specifically.
What's a day in the life look like, Max?
And then Emily, just to understand what y'all do.
I think what's interesting with the question is I think that almost every day is different.
But what is the commonality across each of them is the impact that we can have across
when we help customers.
But if I think of the core activities that we have is how do we help scale everyone at
Microsoft, everyone in the field, partners and customers to deploy.
But it's also to listen in on the common challenges or define the commonality in the challenges
that customers may find in deploying.
Identify with our product teams what would be the best way that we can address this.
It could be sometimes documentation.
It can be features.
It can be some quick updates that we throw out there.
And just really being able to help you move and get you more secure tomorrow.
I'm not aiming for perfection tomorrow.
Just making you more secure.
I'll be happy.
But that's the day in life.
It's going to be a mix of deployment and insights from customers.
Yeah.
So I am on the same team as Max.
So it's going to be pretty similar.
But I'll just add on to what he said.
So to get a little bit more specific, we're part of the product group, but we're part
of the CXE cat side, which is the customer facing side of the product group.
As he mentioned, we're really there to help customers quickly deploy the product that
we're specifically working on.
For myself, I'm working on our purview for AI capabilities.
And it's really all about how do we help to implement these capabilities, implement the
customer feedback that we're hearing, and enhance our product roadmap based off of that
feedback.
For day to day, he kind of talked about this too.
We have customer calls.
That's all about gathering feedback on our products, internal calls to plan out our roadmap,
discuss some upcoming features, talk about maybe potential bugs or timelines for features.
And then it's all about scaling.
So outside of the customer and internal calls, we really just work to scale our knowledge
from the product team to other internal or external customers.
And that could be through documentation writing, blog posts, webinars, or just answering some
questions in the tech communities and meeting new customers.
So Emily and Max, we always ask our guests before we wrap up, what's your final thought
that you want to leave our listeners with?
It can be security.
It can be something else.
But if there's just one thing at the end of this episode.
I have a couple of thoughts.
So as I'm on the Permu4AI team, I want to touch on AI.
As we're really embracing the power of AI and Co-Pilot, I just want to emphasize that
it's really crucial to think about your data security and your governance.
But my final thought for this would be to not stop there.
Data security is extremely important outside of AI too.
And the problem still exists without Co-Pilot or without AI.
So I would use the Blueprint initiative that we're working on to start thinking about your
oversharing and your data security outside of AI and be sure to secure your environment
by default.
And it would be hard for me not to mention secure by default.
It is definitely a foundation that we're trying to push forward.
But I would also recommend just taking a look, taking the opportunity when you think of a
cross purview, reframing how you're doing things.
So you might be moving in from an existing products, DLP for example, and just take the
opportunity to reframe sometimes years of policies that you've had, leverage the best
of what the platform offers you across multiple channels, take advantage of what the AI capabilities
gives you, but also break the silos.
I've seen too many times when if just taking the three products between MIP, DLP and IRM,
how siloed it is within our organization.
It's truly one solution together.
And really to break across those silos internally, I would, and I would, the final, final thought
is absolutely about securing better.
I understand that full security is a challenge to collaboration.
Its adoption may be difficult.
So bringing in waves of, you know, maybe you have some, like giving them a note.
So when I talked about changing label or DLP would override, for example, give them a way
that they can still collaborate, but it's more secure than yesterday and keep iterating
every week this way.
All right, so let's bring this episode to an end.
Max and Emily, thank you for joining us this week.
I know you guys are busy and I always learn something on these podcast episodes and certainly
learned a lot.
Although I heard the oversharing word again, which always brings me back to my daughter
on TikTok, but that's another story.
So with that, let's bring this episode to an end.
Again, thank you for joining us and to all our listeners out there.
We hope you found this episode of use.
Stay safe and we'll see you next time.
Thanks for listening to the Azure Security Podcast.
You can find show notes and other resources at our website, azsecuritypodcast.net.
If you have any questions, please find us on Twitter at Azure Setpod.
Background music is from ccmixtor.com and licensed under the Creative Commons license.