Hello, and welcome back to Cloud with Chris! You're with me, Chris Reddington - and we'll be talking about all things Cloud!
In this episode, we get back to a requirements based topic, and an area that will significantly impact the design of our resulting solution architecture. That topic is security! It's one of the hot topics that organisations want to discuss when moving to the cloud. So I'm pleased to be joined in this episode by another colleague, Andrew Nathan, who has a wealth of knowledge in the cyber security space.
There's plenty to digest in this one, so let's waste no time and jump straight in. Here we go…
Chris: Hi everyone, welcome back to another episode of cloud with Chris. Now we're once again taking a slightly different route in this session and we're going to be focusing on Azure security. When you think about cloud, one of the common questions that comes up is “How do I secure that application? How do I secure that infrastructure? What are the tool and what are the things out there that I should really be thinking about? What are those patterns? What are those practices? How do I make sure that I'm not going to be on the front page of that newspaper because I've leaked a load of my customer information?, for example. So joining me today is another colleague of mine, Andrew Nathan, who hails all the way from Australia. So we've covered - I think - pretty much a good number of the world at this stage in terms of continents. Andrew's focus is all around cyber security and more recently within the FastTrack for Azure team on the Azure security side of things as well. So, I'm very happy to introduce Andrew.
Andrew: Hi Chris, thanks for having me.
Chris: No, thank you for joining. Thank you so much for joining. Maybe let's start at the very beginning and think about security all-up. I guess security is a broad idea or a broad area. When an organization starts talking to you about security, where do you start the discussion?
Andrew: I think for me, personally, I try and start at that high level architecture type level security architect and I try and talk to them about all the practices and procedures and things like that that they would have in place. Then try and garner a little bit of information about how they do things on-prem, or how they run things on-prem and try and build on that. There's obviously a lot of parallels, like in terms of the infrastructure, in the networking and those sorts of things. The same sort of bits and pieces, but obviously there's a few more threat vectors this time, as they go to the cloud and a little bit more exposure by virtue of being on the Internet. So it's more about talking to them about that and trying to build that bigger picture. And then, understand what their business priorities are as well, because that can help us build the picture from a security perspective of what it is that the high value asset, who the high value identities are and those sorts of things. So then, we can start building the appropriate alerting and whatever else that we need to do for them.
Chris: Man, there's so many things in there that I want to dive into from what you just said.
Andrew: Yeah, sure.
Chris: Let's maybe start with that idea, that we're moving from potentially on premises. It might even be another cloud. But, let's just think about the on premises scenario to cloud first, because I guess it's a whole new area, a whole new domain that people are really starting to go and deploy into and build onto. Like you said, you're building on the Internet and I think that's one of the key differences. So what do you see may be as common themes and trends, and maybe those initial thoughts that organizations go through and how they can start maybe strengthening their posture when they start that initial move, let's say. What could they use in the toolbox?
Andrew: For me, the first thing that I always recommend is turning on Security Center. I know we're probably diving into this earlier than we planned to, but I can't stress that enough for my customers. Particularly where we sit in how we're helping customers onboard. Generally, relatively quickly, Security Center gives them a little bit of oversight because I think we refer to it commonly as our cloud workload protection platform or our cloud security posture management platform. So it helps customers have that insight into things that they might not necessarily be aware of that they've left themselves potentially misconfigured and then available to those potential threat vectors. And I guess building on top of that, we then of have to explain to customers the different pillars of threats that they then - for lack of a better word - are exposed to now going to the cloud. Whether it's the tenant level stuff, or the - I guess depending who you talk to in the team… Whether it's the control plane or management plane, like having those global administrator credentials exposed. If they're not secured properly. Not using MFA (Multi Factor Authentication) those types of things. Through to the other subscription level things like external accounts being added or stale access. And that's probably one of the big things, and we'll probably touch on it a little bit later. As you know, identity is a huge part - or it should be a huge part - of everybody's focus with it being the new perimeter from a security perspective. But there's still so many stale credentials out there, or people that just haven't had their access revoked. So I generally try and start the conversation there. Turn Security Center at a minimum on. Get an insight into what you've deployed, what's potentially misconfigured? Then start planning for identity at the forefront… Like how are we going to secure this? What's our plan for the worst case scenario? Something that's compromised there at that control plane, how are we going to plan to get that control back? And a lot of it I suppose as well, from that identity perspective is understanding the difference between Azure AD and Azure RBAC (which a lot of customers don't understand unfortunately), and it's probably not implemented properly. So it's a lot of conversations, and I guess trying to dial them back from turning everything on and turning everything up to 11 (and let's just get everything up here) to try to have a strategic one. OK let's deploy these types of identities first, give them access to make sure it works. It does what we need it to do and build on top of it from there.
Chris: I think what it demonstrates is just that broad topic that we've got, right? I think we talked about a bit about security center, a bit about identity and then starting to think about really that initial journey and how you build up that environment, I guess.
Andrew: And I think from a security perspective - sorry to interrupt - but I think we find that a lot of customers like that - and it's always been… To use a military term a beachead establish. When they're doing some sort of project, there's some reason that they've gone to the cloud. It tends to be that part of the organization that's established, whatever their processes and practices are. Whether that's a developer going out there and spinning up an app in the cloud. Or, an infrastructure team building some IaaS machines and creating some sort of little environment. It's like we didn't understand what we're doing when we got up here and we turned the bare minimum things on to make what we needed to do work. And now we're at this place where everybody's following us. So, we need to regain that control. And that's when we tend to find… “OK, well we have to remediate a little bit and step back” - It's not really starting again, but it's like a course correct, and make sure that from now on everything that goes on is a little bit more secure and auditable, and all those sorts of things.
Chris: I'm going to start waving my DevOps flag at this point, because this is really that nature of being able to iterate over things. You know, we've got our minimum viable product… We've got it working, awesome! But now actually like you say, we need to take it to that next level. We need to be able to start securing against some of those potential threat. I think that's one of the things coming from my previous experience as well, that I think is a really worthwhile activity is thinking about threat modelling and thinking about… “What are we actually trying to protect against?". I've worked with some organisations where they come along and say, “We need to secure our application”. OK, what does that mean to you though - Is that first question, isn't it? And it's all about those requirements and trying to just pick apart what exactly that means.
Andrew: Yeah, I think I tend to go a little bit too deep when those kinds of questions get asked because I start going down… “OK, well the industry that you're in, these are the advanced persistent threats that we see typically in this region that are trying to access these sorts of things. So are you aware of that?” And then I think sometimes I've forced customers to pull hand brakes on this, because they've realised they're not really prepared.
Chris: Gotcha, but that's some of that cybersecurity background coming in, I guess there so valid experience, I think - valid experience! So if we maybe put ourselves in the shoes of a customer and put ourselves through that journey. We're at that stage where maybe they've got that minimum viable product. They need to start fleshing out some of those security requirements, let's say. How do you typically see them starting off? What are some of the things that they should start putting in their minds when they're new to this cloud world? I guess we've talked about identity is one of those things. So are there may be other common pitfalls or tips and tricks that you see on those initial stages, for example?
Andrew: I'll probably keep bringing it up because I think it's the easiest win for our customers is Security Center, really. I'm sure you were there when we had that talk from the red team (our cyber security offensive capability) in Redmond last year. That was a fantastic conversation, but he highlighted to us that still the top two threat vectors really are still - number one - identity (whether it's your admins, your Devs or your ops staff) because it can be compromised, it's still insider threats, it's stale credentials and all those sorts of things. That's always a big focus. And understanding - talking to customers about what their strategy is for their identity and how they're onboarding customers, how they're onboarding partners - because that's another big thing. And another potential vector that we've got for them there. Because as we've gone to the cloud now, there's so many more customers who are trusting a partner to do it for them. But then the rest of it is generally, like the next thing down for a threat vector is misconfiguration. And that's where obviously, Security Center really helps the customers, because it calls it out for you and says “You know this port's available? You're accepting traffic here or not. You don't have encryption between your storage account” and those sorts of things. So it highlights those things that they might not have missed. And you know the application is working. Everything is doing everything that it needs to do. Or the VMs are talking to eachother or whatever the case may be. But there are still these things in there that if they don't harden that sort of stuff up, they’re going to miss out, or potentially be compromised. I guess as we go talk to the customers about it - like you were saying with your DevOps background - starting to talk to customers… Then, OK - if you've got an application - what's your data lifecycle then? If you're creating your data, then you're storing it and you're using it, and you're sharing it… that's great. But where is it being stored? How are you auditing it? Who's got permission to it? Where are you doing all those sorts of things? So if we get back to my original point, a lot of my conversations are really around the strategy and high level conversations because if the customers don't understand what their strategy is. If they don't understand how the component talk to each other and all those sorts of things when you go into the cloud, then they can't adequately protect it. So it's really just… turn Security Center on, see what we're picking up that you've potentially misconfigured. Use that as your quick wins. Assign some KPRs for the bigger ones and send that to your Change Control Board if you need to. But, then start taking off some of the quicker wins. We've got a quick fix button. Go and click a couple of those and turn on your secure communications. Turn on your just in time VM access and those sorts of things and get those quick wins, and harden up those little bits. Then we can build on the bigger stuff from there and help you. Whether it's developing a DevSecOps sort of platform and iterating on that sort of stuff and hardening up and using the right SDK's or understanding the OWASP Top10 or the treacherous 12, or whatever it might be that you need to protect against in your environment. But start to put the right things in place, talking to the right people in your organization. Because, I guess back to that point about it being like a beachhead or one initial team that deals with it. You get the relevant stakeholders, everybody that's going to have a say in what you need to do on what you need to harden up. And let's get the bigger picture for your organization, because if you're going to the cloud now, hopefully you're going to be staying here, so this is going to become your new normal. So let's set the parameters, and the guidelines, and the framework and really harden it all up for you.
Chris: So I'm going to put a phrase in that we've used in previous episodes, which is this idea of failing to plan, planning to fail. So much about you said there is about having that right context, isn't it? Being able to understand who are those potential threat actors or malicious actors? What are the vectors they're going to potentially use? To your point, there might be people internally, for example, who come in and try and just sabotage what we're doing there. Maybe even accidental things, like misconfiguration or potentially intentional as well. You don't know the motive, you don't know the intent and there could be any number of reasons. Ultimately what you need to start thinking about is what are those Crown jewels? What are the things that you really want to protect, among other things that are not so valuable, let's say. Because, there's always a trade-off with applying some of these. Some of these procedures, and some of these policies, right and. There's a potential management overhead. There's potential trade-offs that you might have from an application perspective, for example as well. Like, going really deep and the specific for a sec. If you think about Kubernetes and some of the things you can do to lock down the underlying kernel and what can be done there, for example. Sure, you can do that. But if you're compromising what the application has to do, obviously that's a trade-off based on the requirements. So, how often do you see customers thinking with that requirements-first driven mindset?
Andrew: I suppose to be honest, generally it depends on the industry. I find that the finance industry tend to be - in my customers, definitely down here in the Asia Pacific region - They're very focused on “we have these requirements that we need to meet first”. So, we can't really go forward with anything else until we can figure out how to tick these boxes. So we have lots of conversations with them about setting things up so they can justify that they've met those particular requirements. And obviously then, the next become state and federal governments. They're - I would say depending on the organization - They're either very regulation focused or, we've had a couple of organizations that are like - “Well if it's just going to be too hard well then we'll just accept the risk and will work around it”, which is concerning in some aspects. And then the rest, i really depends on where they're going to be operating. We've found more recently, particularly in the client that we're currently in with people working from home, and those sorts of things - I've found that I'm having a lot more GDPR conversations around those types of regulations. Because, there's now remote workforces and whatnot accessing stuff in the European region. So we need to start talking to customers about those sorts of things. I think that's been a little bit of an eye opener for those customers were like, “Yeah, Alright. Well we need to start reporting against this stuff” and then when you start talking to them about what that actually means, and having the right people in the right positions for reporting purposes. Data owners and maintainers and all those sorts of things. They start thinking well, we're woefully under prepared for what we need to do and how we need to report and who's going to be on the hook for this sort of stuff. Because it's not a particular GDPR, it's not a trivial thing that they have to be exposed to it. You know, if they have that breach
Chris: Yeah, I'm trying to digest everything that we've talked about those past few sentence is back and forth. I think there's initially that piece to understand around who your threat actors are being able to model that and understand what your vectors are. Translating that into requirements and that wider strategy also taking into account what are those wider compliance pieces that you might need to go and adhere to. And from there, being able to start converting that then into some kind of plan. Taking that DevOps and DevSecOps kind of mindset. It's not necessarily you need to boil the ocean all at once, but you start iterating over and start pulling those different services in, and baking some of those requirements into your planning cycle and into your development cycle and building out the infrastructure then as well. That's kind of the model that I'm hearing unfold there.
Andrew: Yeah, and I guess like - I don't know - I'm assuming your customers are similar to mine. That you're predominantly dealing with customers that don't really even have a dedicated security team? So yeah, cool, what can we do and how can we turn things on now to just secure stuff? I guess there's that mindset of the misconception that just go into the cloud. Because parts, or the majority of Azure is at protected level for example for Australian customers. And then we've got the Fed Gov Cloud for the US guys, and those sorts of things. There's - I guess - somewhat of an assumption that we're secure by default. Then you've got to have that conversation about that shared responsibility model, and the fact that they are still always going to own their own data. They're always going to own their own identities, and those particular parts of it. So it's understanding those bits. But then, like you were saying, it then becomes iterating. Like I said to these customers, you can't just turn everything on and be secure. This is going to be a journey, so let's start you on the journey and get you some awareness to what's happening in your environment. But then, this is going to be a maturing capability for you. And as you grow, and as your experience with the potential threats or misconfigurations or whatever the case may be - whatever exposes you. You grow that experience. Then obviously the goal of most security people is to get it to a point where the responses to those things are automated responses. So a little bit of “If this, then that” type of logic. We've got playbooks and Logic Apps and those sorts of things that customers can create to take those programmatic actions. And then it's about iterating. Eventually down the track, it's that whole maturity model of - You're ingesting threat intelligence feeds that based on those threats that are out there, and those threats that are interested in you. Because - fundamentally from a security perspective - if they were interested in you, then you should be interested in them. You should understand what - the military term or the cyber security term that we use is Tactics, Techniques and procedures (TTPs) - what they are. Because, most of them, they're similar to our organizations - the upstanding ones - that they have a typical way that they try to go and do things. They'll do a DDOS until they get through, or brute force until they get a credential and then it's lateral movement. From there, what is it ? What do they want to do? Are they exfiltrating your data? Or is it just a persistent presence because? The three most active ones that we have down here in Southeast Asia. The most common thing that they want to do, is they just want to persist in your environment. There's no evidence that they are actually exfiltrating the data or anything like that. So it's having the awareness that that's what those behaviours are. That's the type of thing that we need to be detecting against. It's not something that you're going to turn on and be aware of from day one. You have to build that experience. And like I said, it's a journey.
Chris: Absolutely, and I've been sat here just listening and thinking of some of my own customers, where I've almost… One of our colleagues, Cam quite a while ago, we were talking about this whole DevOps mindset as if you're rocking up to your favourite fast food restaurant and saying “I'm going to have a DevOps with that please”. And that concept with DevOps, and it's the same idea with security isn't it
Chris: Can I have security on top of that as well, please?
Andrew: One security please.
Andrew: I'll have two Security Centers and a Sentinel, thanks.
Chris: Exactly. And, it's really understanding the workload and what your place is within the industry and what potentially people are going to try and attack you for. Microsoft for example, or Google or Amazon or any of those big cloud vendors are obviously quite big targets, given the nature of the industries they span across. The fact that they have, these sizeable cloud deployments for example. They're going to be attack vectors for a number of different reasons. That's going to be very different to a financial customer, to your point, earlier or manufacturing or whatever it may be. So understanding that, is it a foreign intelligence, and another government or something like that? Or is it going to be a potential competitor? Or just the script kids who is in their basements coding away, just to get rid of some whilst they are in COVID-19 mode for example. There's a number of different potential threats there could be. So, yeah, super super interesting discussion. I think we've definitely highlighted that fact that it's not just about turning everything on and hoping for the best. You really need to understand the domain that you're working in there.
Andrew: Yeah, exactly.
Chris: So then, I guess we've skirted around it a couple of times. Maybe let's jump into it a little bit more. I guess, we've mentioned Azure Security Center a few times. I think Azure Security Center has evolved a lot over the past few years. When I think about what it was maybe a couple of years ago to where it is now, it had so much investments in it.
Andrew: It really has, yeah.
Chris: Maybe talk us through what you see as the common trends and themes that you find you're talking about with Security Center these days. What excites you with customers going on that journey?
Andrew: Yeah, It is exciting to see how it's changed. I started working with it probably two and a half to three years ago now, and it's certainly very different now to what it was then. I guess a lot of that virtue of us bringing Sentinel in ,and having that as our Security Information and Event Management (SIEM) tool and a lot of the data ingestion. But, to be perfectly honest, Security Center is one of my favourite products in the cloud. Purely because of the insight that it gives our customers. The secure score and the recommendations, it's really just taking that guesswork out of it. It's super beneficial for those companies and those organizations that are small that don't have that dedicated security team, because they can deploy those things and whatever else they need to do however, they are comfortable with doing. Then the tool is going to run under the hood. For them and going “Hey, here are these recommendations, here are the things that you need to harden up”. So, they don't need to necessarily be aware from day one what they need to harden up. But they really need to be aware from that, what they can do to then remediate the things that they have deployed to fix them up and harden them up. I think - seeing customers go on that journey - you're on a video call with them or whatever the case may be, and you can see them sort of clicking along as I'm doing the demo. You can see their face light up on the call, like “Well, we didn't even know this was here!". And then, if the customers have got like the standard tier turned on, then they can play around with, the advanced, the application controls, the app whitelisting and those sorts of bits. I don't know if you've spent any time trying to create whitelisting policies, but it's time consuming. For the machine learning part of it to give it to them just by grouping them together by like-application and those sorts of things and go “Hey, here's your path and your publisher rules. Off you go”. It takes two to three weeks for it to run in the background. Then all of a sudden, they've got that policy there, that they can just hit go and just start auditing the environment and seeing who's using what, where and building that picture which - obviously a lot of companies or organizations aren't really doing that sort of stuff. So for them to have that insight. And then the other part of that that I really like aside - the just in time stuff is cool too - but the change control, like the file integrity monitoring part, that's fantastic as well. Because, again, a lot of those defaults that we've got in there for the whole credential theft thing, right? So, if those things are changed or potentially modified, then it's going to indicate that there's potential credential theft or lateral movement occurring within your environment. So you're going to get those alerts which the average customer doesn't have that insight. I think - I haven't looked at the figures in a while - but it used to take between 24 to 48 hours from initial compromise (your domain admin credentials being taken), and then the average… When I used to deliver the workshop, it was like 240 days that the attackers were live in your environment before you detected them. So to have a tool that's sort of doing it for you in the background, just by virtue of paying sort of $15 or whatever it is a month is. You can't really put a price on it. Rather keep your paying a couple $100 a month to have that level of oversight in your environment, as opposed to paying hundreds of thousands to millions of dollars to tidy it back up after an event.
Chris: Indeed, indeed.
Andrew: Just those little things - All the customers have to do is turn the service on by installing agent and it starts doing that for them. Do you know what I mean?
Chris: Yeah, yeah.
Andrew: Like, I've been part of compromise recovery efforts and those sorts of things. They’re exhausting. Trying to correlate all that data and pull it together. At the last one I did, there was a team of like 30 odd people that had spent 108 hours trying to go through an event by the time I got called in. Then we did another 40 plus hours on top of that. They had no idea that it was a malicious insider, some credential stuff had happened. If they had a tool like this, that was like “Hey this has been changed, that's bad”. Yeah, OK, great.
Chris: It could have quite easily accelerated that.
Andrew: Yeah, instead of instead of spending two and a half weeks’ worth of effort trying to get it back on track and figure out who actually did it.
Chris: Yeah, wow.
Andrew: So those are the bits that excite me. Just the fact that again, those recommendations, like that secure score gives you a way to track it. I don't know, if you were a Premier Field Engineer or a Consultant before FastTrack?
Chris: I was an ADM (Application Development Manager), so a bit of a hybrid.
Andrew: Sure, so I was a security, PFE (Premier Field Engineer). We used to get paid to go in - or customers would pay for us to go in and we run these security assessments for them. At the end of the week, we would give him this 85 page Word document. Here's your list of criticals and highs, and would go spend an hour going through what we thought were the most critical and the most high in a PowerPoint presentation. Then we'd leave them with it. We'd go back 12 months later to run the same assessment and they're like “Yeah, we haven't done anything because we couldn't figure out what was the most critical or what was the most high. We couldn't prioritize for it”. And now Security Center gives them the weighted scores. It's changed a little bit now, but it's like “Here, if you fix these things it's going to add 11% to your score”. Looks great. Cool that, gets me at about 50%. That's happy days. If it's the next thing that gives me another 8, 10, 11%, whatever it is that gets me above 70 or above 60. And, you can iterate it and you can see what things are being completed and what remediation steps you're taking. So it's not an invisible thing that's just happening in the background anymore. It's this tool that actually helps you get that insight into what did we have that was misconfigured, and what have we fixed and where we going. You can actually see it improve, which I think for a lot of business is going to be, or should be a game changer, really. To have that level of insight they've never had before.
Chris: Yeah, yeah. I think the theme that I'm hearing here, when I think about the things that you just talked about with Azure Security Center with like machine learning baked in. Those capabilities of being able to stitch together the fact that – Brute force attempt failed, brute force attempt failed, brute force attempt - get in. Suddenly there's some movement happening, some things start happening and you can start piecing on that together. This idea of secure score. The idea of like a red team and a blue team. Really, what this is all hinting to me from outside is thinking about this evolution of the role of security. I think always it was this, to one of your points a bit earlier, this kind of tick box or checkbox exercise. Yes, we've gone ahead and we have secured the network boundaries. Also rotated our certificates and our passwords every so often. Awesome. But that's now the bare minimum to expect, right? Because - to your point earlier in the discussion here, the network boundary is not really the boundary these days that people really care about.
Andrew: Not at all.
Chris: It's the identity boundary.
Chris: And if I were a bad actor, that is the first thing I would go after. I would go after someone's account because I'd rely on the fact - to your point earlier - they would be someone who's probably an admin and shouldn't be an admin, doesn't have multi factor authentication and I've suddenly got the keys to the Kingdom. It's that indirect route isn't it? I think all of these tools that you mentioned, these kind of components and this idea of ML being able to come in and help address that are absolutely super. But one of the things I really love is just that Red Team Blue team concept. I don't see enough organizations doing that kind of activity, those wargaming kind of scenarios
Andrew: Ah, absolutely not. I think that's really where I try to sort of build my customers towards. I think back to what we were talking about before in terms of threat modelling and testing your application and understanding who's trying to get in to get to your stuff. I said to my customers, this is the start. Blue team is generally where it starts, right? We want to Harden things, we want to protect stuff and we want to patch and we want to do all those good things. Great. Once you've got that and you're understanding everything , you're comfortable. The next iteration of that, really, is let's do those penetration testing and that red team type stuff and make sure that our environment is secure and that we have hardened up the right things and they were aware of the things that we haven't secured. Is our source code public? Are we using trusted libraries for applications? What you were saying before, like the single factor authentication - do we have multi factor turned on? Are we using the same account for our dev workers in our dev environment as our normal environment? Is there a large group of people that have all these permissions and those sorts of things like, let's test it. Let's make sure that all the things that controls that we've put in place we have hardened that, and obviously there's no panacea. There's no perfect thing that's going to stop everything. But, do we have the right mitigations in place? Do we have enough depth that if that one thing is compromised, their protections in place to stop it at the next level? And are we alerting that it's happened? So we can have a little bit of a purple team, I guess Like a blue team that's then offensively trying to turn things off like put machines into network security groups that are isolated, so there's no inbound or outbound traffic anymore. Taking those types of steps. You can probably tell, look how animated I've got over the last 15 minutes or so. That's really is my passion and why love coming to work every day, because I get to have these kinds of conversations and help these customers just open their eyes. And they're like yeah, well we can do this now. Security is not this big, mysterious beasts that we're not aware of and everyone goes into a dark room and just has secret handshakes and does all this stuff. I see my job is like breaking that barrier and helping customers understand that the typical IT operations type stuff that they do every day is part of that blue team stuff, like your patching and all that sort of thing. So let's build on that.
Chris: Yeah, there's definitely this team of modernizing security isn't there? I've been doing a bit of work and ramping and learning in the IoT space as well. Definitely won't cover that in any depth in this session because I'm sure that's one we could talk on in a ton of depth.
Chris: One of the things from something I was reading recently and really struck me. It's kind of obvious when you think about it, but it was just reading it, written down there that “Your security is only as good as what you know about today”. The next vulnerability that comes out tomorrow, or the next big security evolution, big kind of threat vector or attack mechanism, or however you want to call it comes out tomorrow. You haven't planned for that because you didn't know about that. And that's not a failing necessary on anyone. It's just the nature of this evolving technical world that we live in. I think it really comes back to that point of what worked a while ago with certificate rotations and that network boundary. You're living in a different world, and we need to bring that agile kind of mindset and be willing to keep evolving our security practices is really what I'm learning from the discussion here at least.
Andrew: Yeah absolutely. It's funny. An analogy that I used to use, but I got in trouble for using it was that… Being a security professional and trying to protect your network is a lot like being the father of daughters. Like that old saying, if you've got a son you've gotta worry about one son. But if you got a daughter, you've gotta worry about all of them. And I liken that to being insecurity, right? Like the threat actors, they know what the target is. If it's your business, then they can be single minded in attacking your business. But like I was saying before… In Southeast Asia, there's three main advanced persistent threat groups or APTs that we have in the environment. So you've gotta worry about all of them. You can't just worry about one of them, because they might use your organization as a pivot to something else. So you have to protect against all of them and understand. Look, we were well before - where do you sit in the food chain and what you've got out there, and the skin that you have in the game, and making sure that you are taking the necessary steps. It can be daunting, but at the same time I don't know for me that whole… It's like a challenge. I think to your point, it's going to be evolving as we add new services to the platform and consumers want to take things and want to use things in certain ways. We have to adapt and change and give it to them like that. We just going to keep opening ourselves to potential threats, so IoT is obviously a huge one. It's just a matter of getting to – We're always going to be chasing our tail. You're never going to be 100% secure, but it's about understanding where you are. And what your potential risks are. That awareness piece is huge. Really, if you know what risks you've got and then you can be calculated about it. You can make your risk assessments and you can mitigate what you can. And then there's always going to be some residual risk. I think that's the most confronting conversation that we always have to have is that you're never going to have zero risk. Understanding that, and planning for it, and knowing where the hole is. Being able to watch for it to make sure it's not leaking, or if it is leaking that doesn't become a river is the part of the challenge. Everyone just has to be aware that in particular now being on the Internet and going into the cloud, but it's always going to be changing.
Chris: Got it. So if I start wrapping us up… One question before I go to my final question. I guess we talked about Azure Security Center, but there's also this other service that you briefly touched upon. It might just be worth giving a quick summary of what it is, just in case anyone doesn't know. I guess it's a fairly new service in the context of Azure. I know there's things coming out all the time. This ones fairly newish I'll say, and that's Azure Sentinel. So, how does Azure Sentinel fit into everything that we spoke about there I guess?
Andrew: Yeah, so I guess the people playing at home that might not necessarily be aware. It's a SIEM (Security Information and Event Management) tool. It's a place for you to ingest all your security logs from multiple sources, whether it's your Cisco ASA's or your Fortinets or whatever the case may be. We've got connectors to everything. I always laugh that the first connector that shows up in the portal is AWS, just because it's alphabetical, nothing else, nothing there. So it's purely for you to ingest your data from a security perspective, for you to be able to build your visualization, and I guess the points that we were making earlier in the conversation is around just being aware of your data and where it's going and all those sorts of things. That's the whole point of it. There's some amazing visualizations in what we call workbooks built into it, which for me - I don't know if you've played around with any in the past, but I've played with some of them and that whole getting to a point where you can actually visualize your data is the biggest effort for all of that stuff. Like all of them are great at ingesting data. Look ours is fantastic, you link it to your log analytics workspace. Happy days. We take whatever data you can send us. It's those visualizations that the product group and in consultation with our red teams and our blue teams, have built the visualizations for customers to be able to go OK, cool. Here's your information, and here's what we think is relevant and important for you to look at. Whether it's your Azure activity or your Azure AD and all those sorts of things you know, O365. Here's some common things that we think you should be looking at. Then from there, you can build your alerting out and have your alerts built around, whatever is important to you as a business. Whether it's specific servers, IP addresses, mailboxes and identities. That's probably something that I haven't really touched on much, but it's a conversation that are particularly have with my customers that want to use Sentinels. It's around who are your VIP identities? Not just your admins, but your VIPs, like the people who, by virtue of their role, is going to be allowed to access whatever they want like C-Level executives. Let's create some visualizations around what they're doing. When are they logging on? And all those sorts of things. Let's get an idea of what normal looks like for them. So if they start doing things outside of that, logging in at 3 o'clock on a Saturday morning or something like that, we're alerted to it. You can build those visualizations in Sentinel and then from there build your alerts, so you'll be notified if that happens, and then you can take it. It's also got a SOAR capability, so Security, Orchestration and Automated Response built into it. So thinking about there's logic apps that we were talking about before. You can create or log a ticket in service now or whatever sort of other ITSM platform that you might have. Or, like I said before, we take that programmatic action and put it into a network security group or whatever the case may be and really build it out from there. It's a fantastic product. It's maturing, like there's so much change that has occurred with it over the last 12 months. They're adding so much more stuff to it, like the ability to potentially sandbox and all those sorts of things. It's phenomenal, and for the fact that it's baked into the platform, it's amazing. I love playing around with it, I love demonstrating it, but we probably don't have enough time for me to keep deep diving into my fanboy status.
Chris: We can definitely pull another episode together to talk about that.
Andrew: Yeah, Sure.
Chris: Because yeah, I agree. I think it's everything we've talked about, right? Really, that theme of observability. Being able to understand what is actually going on is so so important. Not just from security, but in general monitoring. I think that Sentinel is a key player in that. So just to wrap this up here, maybe if we think about everything that we've talked about (which has been quite a lot, we've been on quite a journey, I think in this episode!). What would you say maybe are those couple of key points that you want people to really take away? If they wanted to do a bit more digging after they've listened to the episode, where would you focus their efforts?
Andrew: So I think, quick win (and I said it several times and we've talked about it) is Security Center. If you haven't been using it already, go there. Even if you don't turn it onto the standard tier, have a look at the recommendations that are there now. Because, you're going to get a whole heap of them for free anyway. So go there, start using that. That's going to give you a whole load of Insight that probably never had before, and that's really the quickest win you can get. The next thing, I can't probably stress enough. From that security perspective, have a look at what your identity structure is and what your identity strategy is for the cloud. Your on-prem stuff probably doesn't really map, it's way more dynamic in the cloud and we've talked about the fact that you're exposed and on the Internet now. So make sure that whole awareness and monitoring, like that you know whose identity is being used and when and where and how. I guess the other thing that we'd tell customers number one is turn MFA on for as many people as you can. Ideally everybody, but predominantly the quickest wins would be privileged account. So your admins and then you VIP identities. I know no one wants to go and tell the CEO that he needs to start two factor authentication. But really those accounts, like I said before, by virtue of his role where he can have access to his or her role, they can have access to whatever information they want really. So that really needs to be monitored and secured and hardened up. Then the rest of it is just like we were saying. OK, let's iterate on this. If we're deploying with infrastructure as code, how can we make it better next time? What can we turn on to harden things up? And they're really the key points and how I would leave customers. From there, then the bigger broader Conversations then start becoming about, you know, using policy to control your environment and management groups and all those sorts of things. But we could go for days talking about all this stuff.
Chris: Excellent and I think that sounded like we need to do another episode. So until that time, Andrew, thank you so much for joining. I think it's been a super insightful session. It's been a lot of fun to talk about security. I know sometimes people might not think that, it's a bit of an anti-pattern there saying security is fun. But I've really enjoyed it. I think there's a lot that people are going to learn there as well through this session. So Andrew, thank you for joining
Andrew: Thanks, Chris. Thanks for having me.
Well, we had quite the journey there - didn't we? We've learned that like other aspects of building our solution, requirements are vital when designing security into your approach. That idea of failing to plan is planning to fail.
Once we've begun threat modelling and have an idea of who and what our threats are, that's when we can begin working on security measures to reduce or mitigate that threat. There are Azure Services that can help us have visibility into what is actually happening in our system. Azure Security Center has a wealth of features, including secure score, that can help us baseline and measure our progress. There's also Azure Sentinel, where we can ingest a number of data sources to help us see and stop threats before they cause harm.
Finally, like most requirements, we learned, that our security requirements will continue to adjust over time. Evolving your security operations into a War Gaming style of working, where you have a Red Team which is trying to attack the system, and a blue team which is trying to detect or prevent attacks is a modern extension of your security practice.
Don't forget to subscribe to and follow Cloud with Chris on your podcast streaming platform of choice, YouTube and any social media channels that you use. We've left you with plenty to digest, so thank you once again for joining. Until next time… Goodbye!
Andrew is a Senior FastTrack Engineer in the FastTrack for Azure Team based out of Australia, and has been for the last 15 months. Prior to that Andrew was a Cyber Security Premier Field Engineer for the Microsoft Services team, where he leveraged his broad security knowledge gained from 8+ years as an Information Systems Technician in the Australian Army. Andrew’s focus is around governance and security architecture but his passion is around OSINT which he intends to use to vet potential suitors of his four daughters.