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 23. We have a full house this week. We also have a special guest, Anthony Roman, who is here to talk to us about Azure Network Security. Before we get to Anthony, let's take a quick run around the news. Mark, I believe you have a public service announcement for us. Yes, indeed. Very simple.
Please patch your Exchange servers. This is the on-prem Exchange servers. Exchange Online does not require this. But for those of you that are still running Exchange servers, whether it's in hybrid mode or still dedicated on-premise Exchange instance, please apply the latest update. A couple of key points about this. Impact is very high. If an attacker is able to compromise it, we have seen active exploits in the wild.
The permissions that someone could get from this are right around that domain admin level in most configurations of Exchange. There's some different optional configurations you can do, but for the most part, Exchange typically has roughly domain admin equivalent. So very, very important to patch this. All the supported Exchange releases, the patch is available and released, including one out-of-support version Exchange 2010, is also has a patch available for that.
So a defense in-depth assistance there. One other quick note is that the cumulative updates for Exchange do have to be kept, do have to be at the current rev. So if you're a cumulative update behind or two, you will have to apply that before the patch. But again, please patch this as fast as possible. Start with the Internet-facing ones that have Outlook Web Access and the other internet exposed elements.
Start with that first and get all on-prem Exchange servers that you have patched as soon as you can. That concludes a public service announcement. Okay. So my news this week. Big surprise, I'm talking about Sentinel. But this time, I wanted to talk about UEBA or user and entity behavior analytics insights in the entity page. So we've had the entity pages for a little while now, but we're having more insights there.
So what we're having is general UEBA insights, which is summarizing anomalous user activities across geographic locations, devices, the frequency horizon. So what I mean by that is basically, compared to the user's previous history, does it match up? And it also will compare with the peer's behavior and the organization's behavior. We also can do insight based on security group membership. So we can see your SOC analyst is able to see what other users have similar position, permission, sorry.
And there's the threat indicators related to the user. This one I think is pretty cool because it shows any threat indicator matches. So if you're not familiar with threat indicators, they can be IP addresses, they can be URLs, they could be file hashes. And if any of those indicators are related to this user account, so for example, we see this user logging in from what is known to be a known malicious IP address, that's gonna turn up too. So personal UEBA is very cool.
You do need to go and turn it on in Sentinel, so and you need to give it about four days before it will actually be able to give you some insights, the engine, but go check it out. And then one of our colleagues over in the developer advocate operations team has written a really cool blog about, and that's Sonya Cuff, has written a really cool blog about what's the difference between security center, defender and Sentinel?
Cause I don't know about the rest of you folks, I get asked this question a lot. And it's a really nice article that explains what Azure Defender is used for, what security center is used for, and what Sentinel is used for. Because to the uninitiated, they can be pretty similar. Yeah, so I got a bunch of things that really took my interest this week. One of the first ones, we now have an SDK, an encryption SDK available.
I was kind of joking at the beginning of the podcast when we're discussing this, that I could probably take up the entire podcast just talking about this subject. So for those of you who are familiar, there's a technology in SQL server called Always Encrypted. And it allows you to do queries over Ciphertext, some kinds of queries over Ciphertext. I'm not gonna go into all the nuances of it. Well, that technology and the crypto that's used is now available in preview in an SDK.
We'll have the links in the show notes that explain how you can use it and some sample applications that you can sort of experiment with. But this is really, really cool because, in theory anyway, and probably in practice, you could take some data, you could pass it through this SDK and crypto store that information in say Cosmos DB, and then you could take the data out of Cosmos DB and you could put it into SQL server and do queries over it. So this is a really cool technology.
I've used a pre-production version of this with some customers and they like it as fast, it's well designed and it's well worth, you know, sort of experimenting with if you're interested in cryptography. Another thing that took my interest this week was TypeScript notebooks are now available. Now you may be thinking, well, hang on a minute, you know, what's TypeScript that got to do with security? Nothing whatsoever.
The reason why I want to add it is because I just want more and more people using TypeScript over JavaScript because JavaScript just helps you write, you know, insecure and incorrect code. I just don't like JavaScript. I made that obvious last week. So anyway, TypeScript for Jupyter notebooks are now available and there'll be a link to that as well. So you can install it, say in Visual Studio Code and experiment with it as you want.
And the last thing I want to bring up, this is really cool too, is there is now support for customer managed encryption keys for Azure storage tables and queues. Historically, you could use customer managed keys but only for say blob storage, not for tables and queues. So that's available in preview today. It is only available in a small number of regions, East US, South Central US and West US too.
But obviously like everything else, and as we will eventually, you know, open that up to more regions. Hi everyone. Last podcast, I mentioned that Microsoft had released Azure Synapse, which is an integration of SQL data warehouse with these lots of cool machine learning and cognitive services. And it's used to provide analytical and predictive capability. It works with CosmoDB, SQL, MySQL.
I got to play with it and it was so easy to bring data sources and then using either Python, Scala, Sparse SQL, actually even CCHAR to query the different data sources and then have basic visualizations in the tool set or if you wanted something more advanced, use Power BI for more powerful insights. Well, this week I want to talk about another analytical solution named Azure Databricks, which is an Apache Spark Big Data Analytics, an AI platform. It can be used with Synapse as well.
So this solution just received a provisional authorization for the ODE Impact Level 5. With these, federal agencies and contractors can use Azure Databricks to process the most sensitive and classified mission critical and national security data in cloud computing environments. In addition to playing with analytical and predictive capabilities, another thing that I spent some time the last few weeks is reviewing identity related content.
Lately I've been reviewing YouTube videos, Stewart Kwan recorded these videos, awesome videos in December 2019. You could search for them, they call authentication fundamentals and he has like six or seven videos. One is about the basics, another one is about native client application. I think that one has two parts. They have one for federation, one for web application, single sign-on. So they're awesome, so I recommend it.
But I also been researching these other blogs, the one that I thought it was awesome is this means fine security principle and managed identities. And basically it's because I've been reading all these SolarWinds documentation and I have realized that if you don't understand the basics, sometimes you cannot realize whether the information provided is the correct, right?
You know that certain people that are writing these articles are not familiar with the subject, so sometimes they use incorrect wording which leads to wrong assumptions. So I've been reading a lot so I can inform myself better. And of course, like everyone else, I have been watching some of the information from Ignite including Sentinel, Microsoft, Mesh. Anyway, those are the news for me. Alright, thanks for the news everyone. I'll switch to text now and let's introduce our guest.
Our guest this week is Anthony Roman who's going to talk to us about Azure Network Security. Anthony, first of all, welcome to the podcast and we'd like to spend a couple moments and introduce yourself, what you do at Microsoft. Thanks very much for having me. I am admittedly a listener to the podcast, so this is cool.
So I came to Microsoft, I think about two years ago now, and I originally came here to work on Sentinel and Azure Security Center, but once the team that I was part of decided that we were going to take on some more products, namely the network security stack, I jumped over onto that bandwagon and now I lead a team that focuses all on Azure network security.
Primarily we look after Azure Firewall, Firewall Manager, WAF and DDoS protection, but as we're talking to customers, of course the broader concepts of network security in Azure come up and so we're well familiar with all of that. So we're pretty cognizant that network security in Azure isn't just a set of products, it's a mindset, a methodology, a set of disciplines that represent network security.
Yeah, it's interesting you should bring up a topic of networking general and the disciplines that come with networking security there's a comment that I made some years ago and it's something I stand behind 100%.
I would like to know if you agree or disagree or have some more finesse around the comment and the comment is in a cloud-first world, you can't escape networking, it doesn't matter if you're a developer, it doesn't matter what you are, you really can't escape some of the fundamentals of networking. At least I'm not saying you should be an expert in them but you should at least understand some of the basics and I really want to stress this, cloud environments are quite different.
If you're a developer you really need to understand basic networking and if you're in sort of ops slash networking you really need to understand how to use some of these developer tools Visual Studio Code, Editor of Choice, GitHub, Version Control, Pipelines, these are all things that developers have been using for many years if not decades and historically those tools have not been really used by networking folks.
In my opinion, if you're networking you've got to understand basic development, at least development tools and if you're in development you really have to understand basic networking and certainly the implications of network security. Is that a fair comment? Yeah, I agree completely. I think there's two important things that you touched on there. We can look at it from both directions.
One, developers and just everybody that touches an Azure environment needs to know at least the basics of networking. At least as it applies to their discipline. But we're seeing as companies adopt more kind of cloud native mentalities and the roles blur between disciplines and you have democratized ownership of different larger areas of the environment then you do see people needing to have multiple skill sets.
You need to be at least proficient in networking and in application design and architecture and then you can write your code. It's not as rigidly segmented as it once was. And on the other side of things, if you are primarily a cloud administrator or network security architect something like that then with cloud computing as you're specifically you really have to start understanding those principles of code because now that's your infrastructure.
Now you can manage your entire environment with a single arm template or a collection of them. It definitely goes both ways and it kind of brings in a good point of the blurring of the line between even network security and let's say application security because when I introduced the products that I tend to focus on some of those can be thought of as application security tools over network security tools.
And thinking about that kind of blending together of disciplines within security and within just cloud operations and development in general you think about what is it that you're building on Azure? Most of the time you're building some sort of app. It's an application delivery mechanism whether that's an internal line of business app or whether that's something that is internet facing, public facing.
You have to write application code that gets delivered somewhere and it's delivered over the network. And so you kind of have those two disciplines, app sec and net sec coming together. What would you say the building blocks of secure networks then? As you said Anthony, you cannot get away from, no one gets away from networking. So where would you say people need to start to secure their network? That's a good way to start. I'll bring in a buzzword into the conversation.
People talk a lot about zero trust lately and zero trust in the conversations tend to involve identity primarily and I guess rightfully so. Identity is huge. It's probably the primary component of the zero trust model depending on how you formulate that model. But if you look at some of the pillars of zero trust, at least as I guess Microsoft has written about it, some of the components that you find within that are just old fashioned, tried and true, good security practices.
Things like defense in depth, assume breach, lease privilege. You can translate all of those things into networking concepts and we'll kind of go into how to achieve those. So if you wanted to adapt the principle of lease privilege, let's say, which is primarily that's an identity concept, but you can translate something very similar, which kind of goes hand in hand with assume breach into networking, which is the concept of micro segmentation.
It's basically lease privilege access when it comes to what on the network can talk to what else on the network. And so to achieve that end, there's a bunch of different building blocks and there's learning modules out there on Microsoft Docs and everything that you can go through these basic concepts. But some of the things that to keep in mind would be thinking about a virtual network as its own isolation barrier.
So when you create a virtual network or a VNet, you give it an IP address space unless you explicitly do something extra, like peer it to another one or connect it to a VPN or something like that, that VNet is its own boundary. It is one barrier of isolation and segmentation. Then you can go steps further. Once you have that VNet isolation, you can choose whether to expand that to other VNets. So you can, there's the concept of VNet peering. So one network attached to the next network.
And then you can within that peering arrangement, you can say whether the traffic is allowed to go one way, both ways, etc. And then within each VNet, you have the concept of you can segment it further because by default, if you're in the same VNet, you can talk, you know, if one VNet or one VM lives on the same VNet as the other, it's going to be able to talk. And so you can get a little bit more segmented by using network security groups or NSGs that will further lock down that communication.
So if you don't want a particular subnet to talk to another subnet, you can make that arrangement or you can go even more granular and say I don't want this machine to talk to that machine even within the same subnet. So it's, there's a lot of different layers. And so those are, those are kind of the basics. Once you start getting a little bit more advanced, because we're talking about, like, I guess we can frame the conversation in, I'm a developer, I have an application that I've written.
Let's say the application code is running on a VM. And it could be a PaaS service as well, because a lot of our PaaS services, like, let's say, a web app, can be given a private link. And so you can only access it on a private network, which you could integrate into your VM. So it could be either a virtual machine running on the network, or it could be a web application running on the network. But how do you get that piece of your network available to where it needs to go?
You know, whether it's the public internet, whether it's some other spot on your network, maybe you have a hybrid network where your on-premise network is connected to Azure and you need to access that application from your on-premise workloads. The way that you can start doing that and putting all these pieces together is by, what we normally recommend, what we see the most often in the wild, is using a hub and spoke topology.
So that's, it's fairly common now, I think, and if you're not familiar with it, the concept is you have one virtual network that access your hub. It could be just any virtual network that you designate as the hub, or it could be, we have a service called Virtual WAN, and Virtual WAN could basically automate some of the components of connecting your networks together in a secure manner. We'll keep it simple and we'll talk about it in the virtual network context.
And so in a hub and spoke topology, you'll have one virtual network that is acting as your hub, and via peering relationships to other spoke networks, you connect multiple spokes to that hub. And so each of those spokes could represent different workloads. A lot of times we see customers that have, you know, I talked about kind of the democratization of control over pieces of Azure.
Sometimes one application team, the development team, will have complete ownership over their own subscription that has their own virtual network in it, and they just peer that to the hub, and it makes it so that that area of control they have now can talk to the central place. And your spokes could be all kinds of different things. You could have a Windows Virtual Desktop environment as one of your spokes.
You could have an on-premise network segment connected by either ExpressRoute or VPN as one of your spokes, and that would turn you into a hybrid topology. And what do you put in that hub to control the traffic, because that hub becomes your center of control, and most times we see security teams have a lot of visibility into the hub and control over what happens there. And this is the place where kind of everything comes together, so it's really important.
The hub can usually either contain a network virtual appliance, what we usually abbreviate as an NVA. And this is the familiar appliances that people might be used to running on-prem. So it could be a Palo Alto, a checkpoint, something like that, that sits in the hub and it controls the traffic. We also have, I mentioned that my team works a lot with Azure Firewall, Azure Firewall is the cloud native way to achieve traffic filtering and direction in a hub network.
And so you can have different things performing different functions in that hub, but what it amounts to is it's the central control point of the micro segmentation of all those other networks. So it's kind of a harmony between network security groups controlling local traffic, peering relationships, allowing traffic to go from hub to spoke, and not from spoke to other spoke without going through the hub.
You have user defined routes which control how traffic is allowed to move, whether it's forcing traffic to that hub from the spokes or forcing traffic even from the hub to some other filtering destination. Sometimes customers have an on-premise inspection pipeline or something like that, that they need to force all traffic from Azure back to. That tends to be kind of a legacy arrangement, but it's possible.
So there's a lot of moving pieces, but if you can understand the general pattern of hub and spoke, of segmenting different workloads from other workloads, you're going to achieve those basic security principles that we know are a good idea. You're assuming breach by performing inspection on all the traffic, forcing it through that central location, not letting traffic get to where it doesn't absolutely need to go.
You're doing, again, least privilege translated into the network level by creating allow rules rather than deny rules. What that means is kind of we start with Azure Firewall specifically. It's a default deny. And so unless once you route traffic to it, nothing passes unless you say it can. And as long as you're making very deliberate choices on what to allow through, then you're going to achieve those good security principles.
You're going to have a segmented network that only what needs to talk can talk. So that was a really long-winded explanation of the building blocks. And I think it really only scratched the surface anyway, but hopefully that's instructive. Yeah, that makes sense. But yeah, you're right. There's a lot of things to talk about, right? That's just how it is. So, Anthony, my question for you is really around traffic inspection and monitoring.
And what is it that we can do with the traffic that goes through and over Azure Firewall? With Azure Firewall standard, I'll start with standard and then I'll go into premium shortly after. But with standard, there's always been the capability of matching traffic that passes through Azure Firewall, whether it's internal traffic or inbound, outbound, whatever, against our internal threat Intel feed.
And so there's always been that capability and that remains in premium and will remain a piece of firewall standard. But that can be set into alert or alert and in I mode. So if there's a known malicious FQDN, let's say that one of your VMs is trying to communicate with, we can knock that traffic down. Same with if there is inbound traffic coming from an IP address that is known malicious, that will also be knocked down.
Threat Intel is kind of the most basic piece, but with Firewall premium, we start getting into some more advanced capabilities. And you can even argue whether this first one is advanced or not, but it's something that's new to us and required by a lot of customers. And so the first one is IDS IPS inspection. So intrusion detection and prevention. What this is basically just a signature based IDS system that you can, that will match traffic against known malicious patterns.
And it's using a subscription based feed that we manage for the customer, which makes it so that you don't really have to go in and fine tune the engine. We give you all the tools to fine tune the IDS engine, but you don't really have to. We offer a curated set of rules so you can just kind of turn it on in that either detect or detect and prevent mode and have that extra layer of security.
Beyond that, and I guess complimenting that as well, we now have the ability to terminate TLS connections at Firewall, which gives us a better ability to see the entire packet to apply those IDS IPS signatures to. This is done for both outbound traffic and also east west traffic traffic that's going, let's say from one V net in your network crossing the hub where the firewall is in into the next V net.
If it's going to a web application in that, which hopefully is is all encrypted with HTTPS, we can have that connection terminate at Firewall so that we can look at the decrypted payload, which really adds to our ability to inspect that traffic. When we've done all this inspection, you know, IDS we've looked at the IDS is how to look at things we've broken up the TLS etc. Then what should we be doing with that data? Where should it go?
If you guessed Sentinel, you'd be correct. And I'm guessing that you guessed that. Maybe I did just a little bit, but I suppose to be fair to have to for a well rounded conversation, you know, it could go to another seam if you're using something else, but ideally Sentinel would be good.
Yeah, and that's that's a good point is that all of the tools that that encompass kind of the network security stack they all work on. They're all Azure services and so they all use the concept of Azure diagnostic logs. And this is kind of just a general point to make. I'm sure that you guys have talked about this before, but the difference between Azure activity log and Azure diagnostic log mean activity log records all the control plane stuff, but the data plane.
What happens inside your resources? You have to take an extra step to enable the diagnostic logs and put it somewhere. And these resources are no different. So Azure firewall. In WAF and DDoS protection all work on diagnostic logs and you can send those logs to storage for archiving. A lot of times we recommend that for things like NSG flow logs.
And in fact, that's currently the only place that you can put them. You can put your your log data in log analytics and that's how you would you would pull it into Sentinel and then event hub which like you mentioned you can pull that into an external sim. Anthony, I mean a lot of these tools people are familiar with on prem.
Even though we are talking about the cloud versions. Can you give the listeners a sort of an overview of kind of comparing and contrasting the on prem mindset of these tools versus the cloud mindset for using these tools. Yeah, I think that some of these things can translate directly. And I mentioned before that one of one easy way to keep your cloud environment looking a lot like your on prem environment is to just use the virtual version of whatever appliance you're used to using on prem.
And that does work. That's a it's a perfectly valid way to look at things, but then we have customers that do want to embrace the cloud concepts like infrastructure as code and things like that. And then you can manage their infrastructure as part of pipeline and so that's one thing that you know people tend to like about the services like Azure firewall, you know, at Gateway and WAF and all these things.
And that's part of the rest of your in your Azure environment and so doing something like creating a firewall rule, or updating some setting on your WAF config. Those things can be done in the same system in the same template even as you updating, you know, the number of
devices that are in your scale set, you know, all the things that that go into your Azure environment can be done all in the same pipeline and so that's that's an advantage to a lot of customers it doesn't work for everybody, but it is, it is an advantage. Another big difference in the thinking of on prem versus cloud is kind of the centralization of a bunch of capabilities into one thing into one box. That's kind of the appliance mindset which again it works.
But when you have the cloud native tools, it enables you to think a little bit differently about that, you know, so the example that that I can give is, maybe you're on premise firewall you're used to being the central point for everything everything everything that happens on your network so
it's it's where you terminate all your VPN connections, it's where you allow all your web application traffic in, it's the where you inspect all the traffic going out. It's where all the east west traffic goes in between.
And that's fine, and that that does work in Azure too. But when you're using the cloud native components you can pick and choose which service does what it's a bit more of a modular approach. So you can have Azure firewall doing the outbound inspection, you can have as your WAF on application gateway or
door doing the inbound inspection, you can have different services altogether like VPN gateway doing your VPN termination. It's it's more of a kind of you check the boxes that you need and not the ones that you don't. So it's not like you have to put in one monolithic appliance do all the things you provision just the resources that you need and not those that you don't.
So we've sort of touched on various technologies that we have in the stack, one of which is front door. Some of our listeners may not know what as your front door is. Could you just spend a brief moment explain kind of what front door is how it works how it sort of fits in the overall scheme of things when we're talking about network security and also, while I've got you know what sort of new coming down the pike.
So starting with front door, I guess that's that's more of a conversation on the application security or secure application delivery side of things and so front door is one of the two services that you can currently attach an Azure WAF to so
inspecting inbound traffic with the web application firewall to detect and prevent known malicious web application traffic. So the things like SQL injection and cross site scripting and remote code execution and things like that that you tend to read about in headlines.
So front door is in front door and application gateway are the two attachment points for WAF those. They are both layer seven load balancers which they they do application delivery specifically on the application layer and so how that differentiates from let's say Azure load balancer or traffic manager is that load balancer and traffic manager just work on you know the network layer.
And so they do pretty basic load balancing DNS based send send traffic arbitrarily to two different back end notes. That's that's a fine way to do things if that's your use case. But if you have more advanced requirements like routing the same application traffic. Let's say traffic to the same application but two different paths to different back ends that correspond to those different paths which is path based routing.
You can use front door application gateway. The big thing that makes these that sets these things apart and the reason that we attach WAF to them is that they terminate TLS inbound. So they always there's always a. TLS termination that happens on them which enables us to see the entire packet and make either routing decisions based on that or do security inspection. And so that's why they're very relevant to us and so differentiating front door and application gateway.
App gateway is the regional service and front door is the global service and so at gateway lives in inside your V net. It owns a subnet that's that's inside your V net. So back to our secure app design it would it would live in one of those peer networks. Maybe one of your spoke networks or maybe in the hub itself.
There's different designs possible but app gateway sits inside your network and so it's it's kind of closer to home and it works very well for publishing internal only applications and it can also serve applications that are that are. Internet accessible. But keeping in mind that it is it is served from a specific region.
Front door being a global service is pretty much we say it's global it's it's not attached to any specific region. But what is probably more accurate is that it is attached to all the regions. When you host a web application on front door. It's simultaneously available and at every one of our data centers throughout the world. And so. It has an application acceleration. As your WAF on either of these services to do your your web application security inspection.
And again WAF firewall all these things. You know feed the security data that everybody. Everybody loves you also asked what's new so there's new things that that came out very recently a couple of weeks ago. Both you know we touched on Azure firewall premium so that's the that's kind of the big new thing in the in firewall land which again gives you TLS inspection.
And then IDS IPS web categories were another piece of that that got released and then Azure front door also has a couple of new SKUs that enhance the security of the application delivery it is capable of. Which. One of those things I mean there's going to be some some great improvements on what we're doing with WAF.
The for the time being the biggest thing I think that's notable is that front door can now handle private link and so you can you can you can have basically a private connection from front door to your back ends it used to be that you had. Would have to have a public facing endpoint that would sit behind front door, which is not insecure there's ways that you can lock that down.
But putting it on a private link and having nothing on the on the public Internet is something that a lot of customers have been have been wanting so some good stuff that has been released and definitely. Keep an eye out for future releases because now that we're we're in the realm of of being able to decrypt traffic on firewall I think you'll see.
Some more and more capabilities piled on we've got customers that that have other requirements that we're looking into developing nothing I can get into specifically now, but it's definitely a space to keep an eye on. We always ask all our guests this Anthony at the end of the podcast but if you wanted to leave our listeners with a final thought or something they should do. What would it be?
I would say just don't forget about the network. It's kind of it's funny that the the the network layers tend to be the. The easily forgotten about ones the ones that people want to move beyond and say this is this is an identity first security world and things like that. But don't forget about the fundamentals and network network security is one of those fundamentals and so I would just say say that don't don't forget about those fundamental building blocks to security.
You need to have defense in depth and so even if you even if you are doing all the right things on you know the the higher levels and verifying identity every step of the way and doing. You know, behavioral analytics and all the fun newer and I guess more modern security inspections. There are there's a lot to be said about continuing to do the right thing on the fundamentals. It's the comparison I make is.
You know I DS is you know maybe thought of as something that's it's been out there for a long time. It's not the most advanced security detection mechanism, but it is something that is that's useful as one component in the stack. It's not the end all be all.
But just because you're doing in the comparison is just because you're doing, let's say really fancy things in EDR on your endpoints, you shouldn't turn off your signature based malware. It still has a role to play and so network security and kind of the fundamental concepts. They still have a role to play even in you know an identity first zero trust world.
Anthony, thank you so much for joining us this week. I really appreciate you taking the time and know you're busy. I know I learned a few things as well along the way. And to our listeners. Thank you 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 sec pod background music is from CC mixture.com and licensed under the Creative Commons license.