ERP053 - Building and Securing Cloud Infrastructure

Welcome to Evolve Radio where we explore the evolution of business and technology. Today on the podcast, I'm speaking with Michael Argast, founder of Cobalt. Cobalt is a security consulting partner that specializes in helping small to medium businesses secure their technical operations with an enterprise approach. Michael and I explore what teams should consider when they're building cloud infrastructure. And what are some of the common mistakes is on prem more secure than the cloud? Also, since everyone's dealing with the COVID-19 pandemic, we also explore some hot button issues for maintaining security as your self and your clients are working from home. If you enjoy the show, be sure to subscribe on iTunes, Stitcher, or wherever you get your podcast from. Also, be sure to check out the web page evolvedmt.com/podcast for show notes, links to my guests, and to check out previous episodes. Now, let's get started. Joining me on the podcast today is Michael Argast, founder of Cobalt. Welcome, Michael. Thanks for having me, Todd. So, we're going to be chatting about uh cloud security, probably security overall. Uh this is always been a perennial topic on the podcast because uh it certainly garners a ton of attention, a ton of interest, and it's a it's pretty integral to the IT security space and the IT and technology space as a whole. Thanks for having me, Todd. So, we're going to be chatting about uh cloud security, probably security overall. Uh this is always been a perennial topic on the podcast because uh it certainly garners a ton of attention, a ton of interest and it's a it's pretty integral to the IT security space and the IT and technology space as a whole. Uh just a ton more awareness around this. And um I think we'll dip in a bit to the work from home strategies a little bit, but uh the focus of the conversation that I was interested in having with you was uh how to secure cloud infrastructure. And uh this is definitely a big push, a lot of people um have been looking at developing cloud infrastructure and moving from the on prem. Uh so I thought that this would be a really great topic just to help people understand what they may not know about securing cloud technology. So, maybe to lead off, if you could uh suggest, uh what are some of the the do's and don'ts or some of the the transgressions that you see when you audit people that have uh set up cloud security? So, there's a wide variety of kind of do's and don'ts. I would say the most common mistakes that I see organizations make, um starting off is just not understanding the concept of the shared responsibility model. And so, uh in a cloud world, typically you have, if you're talking about infrastructure in the cloud, you have uh you're loading technology into AWS. And AWS has uh areas of responsibility around the physical security, the hypervisor, uh on up. And most organizations or that I talk to that are relatively new to cloud will go, hey, I'm in AWS, I'm I'm secure, right? So they they think that the in the same way that um you would put, you know, your servers in a data center, they think the data center's taken care of my security, they think the same as it relates to cloud providers. Um and the reality is it's actually the same for both, um the data center provider, the cloud provider is responsible up to a certain level of the stack. But then when you start getting into the application level, um it is still primarily the service provider's uh the uh the vendor's responsibility, the organization that's moving into the cloud. Yeah, so and that's something that is sort of my concern, what I tend to see when people are doing these these moves to the cloud models. Is that they they tend to think that the security application and the configuration is basically identical to on prem. And that's pretty far from the truth, isn't it? No, I mean, so there's there's a lot of different ways of adopting the cloud, there's kind of the lift and shift model. Where you take your existing infrastructure and you just kind of move it like a virtual machine from one from your data center to the cloud. Um but when you look at like a purely cloud native cloud dev kind of environment, it is a totally different world, right? And so, you can't simply apply the same principles that you would have applied in your data center in the cloud. A classic example of that is uh organizations that go, no, put a firewall in front of it and I'm secure, right? And while that may have done you a lot of good in the data center, it's really just the start of a discussion in the cloud. A lot of mistakes are made around things like identity and access management, credentials, permissions, um that are, you know, just a totally different set of kind of thoughts and concepts in the cloud than they are in the uh on premise. So, would you say the the distinction maybe is the perimeter security versus sort of the the stack security within, like what's held behind, is that maybe a good delineation of of how the approach is different? So, uh a properly cloud native design is much more uh microservices architecture rather than kind of monolithic architecture. So in a traditional data center environment, you would secure your perimeter and you would probably do some internal segmentation as well. But for the most part, it's a perimeter inside kind of model. Um when you're building for the cloud, you are building individual microservices typically. That connect to each other um and are secured from each other as well. And so the point of security is not necessarily the perimeter, but for example, your APIs and your code stack as well. Um so it's much more aligned with um a zero trust model, which is kind of a very popular trend in the security industry right now. And it's much easier to adapt those kind of models. And the other thing about cloud is there's not like one cloud adoption methodology, right? I talked about lift and shift versus cloud native earlier. But, you know, if you're doing I as where you're taking and you're buying compute and storage and all that kind of stuff and building your own infrastructure, that's one scenario. But another scenario is something like pads where you're using a Heroku and all you're responsible for is your uh your your your application layer. And Heroku takes care of your lamp stack and everything above and below. And so, you know, there's no one size fits all model in the cloud, um but it is really important to understand that, you know, where exactly do you have code and how is it segmented and protected from, you know, different um levels of access. And so, perimeter is really kind of a a non-sequitur in the cloud. Okay. Do you think that there's a difference in sort of the necessity of understanding between the traditional kind of infrastructure, the MSPs, the IT service organizations of the world versus the more traditional programming, the dev side of the world, like the the DevOps people, they're they're uh their exposure to sort of the integrated stack is probably higher than the traditional infrastructure people would be. Just understanding the bits and bobs, really kind of like what the the applications talk to, the necessity for how they actually communicate with other parts of the the the the infrastructure. So they maybe have a more advanced understanding of how things are interconnected within the fabric of the infrastructure than say a traditional IT architecture person may just based on necessity. Would you do you think that that's maybe accurate in some description? Yeah, absolutely. Where I where I I tend to draw the line is kind of the traditional security professional, for example, would have been um a network-based um person, right? So my my own background is networking, you know, TCPIP, you know, layer 0 through 7 kind of thing, 1 through 7. Um and so, you know, we think about things in terms of ports and protocols and, you know, application layer level traffic and stuff like that. And in the cloud, you know, really what we're talking about is appsec, right? So it's, you know, how am I securing my application against attacks? Um and to the point where, you know, when we talk about things like infrastructure as code, so, you know, my servers aren't really, they're not iron anymore, they're aren't even really virtual machines, they're a series of configuration statements inside of my Kubernetes uh configuration. And so, I have to think about, you know, the code on my APIs, the code that's running behind the scenes, I have to think about the code in my orchestration platform. And so, increasingly when I'm talking to young security professionals these days, I'm saying, you know, you want to learn about security. You have to learn about code because fundamentally infrastructure today and everything else is built up on code elements and you can't know how to secure it properly if you don't understand how code works. Right, and that to me is uh sort of the model of software defined everything once you get into the web, like you like you said, like you have infrastructure components that have configurations in a traditional architecture. But once you get to the cloud, it's simply defined by as you said, those those configuration, the software configuration of what the definition of what it can see, what it can touch and what it has access to. Which is far different than this piece of equipment is allowed to talk to that piece of equipment, right? Right. Yeah. That's much more traffic light, green, yellow, red, kind of easy, um whereas when you're talking about code, it becomes a lot more complex and troubleshooting to be a little bit more tricky as well. One of the things that I see very commonly is QA organizations will do QA on the front-end web app and the back-end server stack and they'll forget about the orchestration stack altogether, right? Um and so, you know, somebody might introduce an error in their orchestration stack that opens up a vulnerability to, you know, all of their servers. And for uh sense of definition, the orchestration stack being like the management tool set. Yeah, so that would be your your Docker, your Kubernetes, the things that are deploying uh your systems, right? Okay, right. Yeah. Yeah, and that's uh that's one of the other beauties and I suppose one of the risks of the cloud defined uh infrastructure is just being able to script deployment. Um the the ease of deployment in in a software defined world is pretty beautiful. Especially with extensible cloud where it you you can consume as much as you require. There's no real definition of your set resources, it's just the the spend that you apply in that. Um that's a piece that I I feel is sort of the better, maybe a good place for people to start in in understanding is that orchestration component. Uh because I think there's a lot of um there's a lot of efficiency that can be gained in that that most of sort of the traditional IT organizations that are moving to the cloud. Don't necessarily have a good grasp on. They're not necessarily coming from a programming background, they are tend to be more of that traditional IT approach. And the the efficiency and the capability that can be built on having that type of scripting is massive. Plus, I sort of see it like um the reasons why I spent a lot of time playing with Linux. early on in my career is that if you can build something from from the kernel up. You get a really good understanding of how the whole thing fits together. Where same idea, if you understand how you have to deploy and integrate the entire stack from basically compute all the way up, uh then you have a much better sense of how these things are integrated and how to to to to uh toy with them and configure them. Yeah. In some ways it's easier, in some ways it's harder, right? Because, you know, I can take a Docker container and deploy a system in seconds, right? Whereas like if I wanted to build that from scratch on bare iron, it could take me hours or days. Yeah. Right. And so, my ability to assemble building blocks is um, you know, incredibly powerful. And it enables an organization to focus where they are truly adding value. Which is, you know, fantastic from a just efficiency of development and and engineering resources perspective. Um the challenge of course is, you know, you may or may not have deep knowledge in what you're deploying and you can, you know, pick stuff off of the shelf that's insecure. Has vulnerable libraries, you know, all this kind of stuff. And if you aren't managing that carefully, um you can be introducing risk that you're just not aware of. And so, you know, there's just all sorts of horror stories of, you know, somebody went out and configured a script without really thinking through the consequences and end up racking up a $40,000 AWS bill, for example. Yeah. Um and so, yeah, there's there's a lot of interesting stuff there. On the efficiency side, one of my favorite personal stories is, um one of my favorite services under AWS is a service called Spot, um which allows you to configure your orchestration to use um available resources with an AWS based on variable pricing. And so, AWS has a a pool of resources. And they have resources that have fluctuating prices based on the overall load in the data center, right? So, you know, they enable that and they expose that via an API. And you if you have batch processing which can be quickly fired up and killed without, you know, running any risk of dying. You can run those batch processes at extremely low price points. You know, based on kind of predefined configurations. And that's just the sort of thing that you just could never even think about doing in a traditional data center. Right? Is that that opportunity to optimize, but of course, it can absolutely go the wrong way as well, right? Is, you know, I'm not really paying attention to what I'm doing. And I've just fired up two, you know, major instances and they're racking up $10,000 a day in in spend, right? So. Yeah. Yeah, that's uh definitely one of the risks that I see. And I think a lot of one of the the major pushbacks that I I I see from organizations that are initially moving to the cloud model. Is that there's so much concern around the unpredictability of pricing. Especially like you you can kind of use some tools to get an idea of of what is the workload look like. And how much is that expected to cost me on a month by month basis? But then like you said, you get uh some spikes that happen or all of a sudden there's a ton of egress traffic that leave the cloud and go somewhere else and and it just like peaks the bill at a bad time, right? So, any advice for people on on that that configuration and managing and having predictability around costs? Yeah, so in a traditional environment, you may um have some predictability around cost, but you may have unpredictable impacts in terms of performance, right? So, that same spike would have just caused your servers to crash, right? And so, as a result, you wouldn't be able to necessarily ensure availability. And so, I think the key is actually just basically instrumentation and understanding of your environment. So that, you know, if you go into the cloud not really knowing what you're running in house, you're likely to end up having a bunch of bill shock. Because you're just not aware of how your system's performing and what the spikes in traffic look like. If on the other hand, when you when you're moving from in house to the cloud, you go, yeah, so every second Thursday, we run a big billing uh system and it's going to do this with traffic. And it's going to spike through the roof. Then, you know, you're going to be able to expect and manage that when you go into the cloud, right? And so, that kind of instrumentation visibility is really, really important. It's one of the things that like from a security operations perspective, we focus on with our clients is, it's not just watching out for security incidents. But also just giving people increased visibility to what's going on inside their environment so that they can be, you know, applying judgment and making the right decisions along the way. What was the term that you used for that, the kind of the operational visibility? Instrumentation. Instrumentation visibility? Yeah, I I use the term instrumentation, it's not necessarily widely used. But it's just the idea that, you know, your systems are are giving you little bits of data when things are happening, right? So if you think about uh a log file telling you your disk is full or a CPU is at a certain level. Those things are instrumentation of what's going on inside of your environment. And so gathering all that into some sort of monitoring environment allows you to actually understand what's going on. And and Amazon and Azure and stuff actually provide you pretty good out of the box instrumentation and there's third-party service providers on top of that. Where they tend to be pretty weak on instrumentation actually is billing, right? So they they actually probably to some extent intentionally hide the obviousness of what's going on from a billing perspective. Um and there are of course third-party tools that make that much more transparent as well. Right. Yeah, I'm I'm a big fan of uh data and dashboards and monitoring metrics from an operational standpoint. And I think in this instance for all the reasons that we described, it's even more important, right? Yeah, if you're if you're a data-centric business, if you operate off a data, cloud is a great environment to work in. Right. Um what about some of the cloud environments? Um uh they obviously sort of my perspective on this is, I've tried to configure AWS in the past and like you you kind of have to be a DevOps person to really understand what the hell you're deploying. It's it's very opaque, they don't make it easy from a partnership model unless you really, really know what you're doing is how I find things. Where I tend to see like Azure and the Microsoft model a bit more templated, like you can say give me this type of computer with this amount of RAM. Whereas like the that type of of strict definition of what you're deploying, I just found a lot muddier in AWS. I get that it's more configurable, like it's the customization comes with complexity. Whereas the simplification comes with some ease of deployment, but maybe not the same sort of configurability. I don't know, what's the trade-off do you see like the there being advantages between one type of cloud provider depending on what you're looking for or is it just sort of a different approach from different companies? I think it depends a lot on your dev shop. And so, if your dev shop is traditionally a Windows stack dev shop, then Azure is a very, very attractive environment. Um most of the early adoption with AWS in my experience are like it's it's kind of a Unix versus Windows world all over again, right? So a lot of the AWS people are kind of old lamp stack Unix people. Um with a dev background and understand that kind of, you know, deep kernel level kind of uh degree of uh technical control. Um and Microsoft I think to their credit has done a really good job of um making the cloud much more accessible. Which is why, you know, they're seeing a huge growth in that traffic. I'm seeing a lot more hybrid shops, um especially inside the larger end of our mid-sized customers where they've got maybe AWS for their uh customer infrastructure stacks. So the the app that they're actually serving their customers. But then they're going to be running a lot of traditional workloads and um, you know, traditional infrastructure. So they're Azure AD, they're exchange, all those kind of stuff for all 365 on on Microsoft stack. And so, you know, I think the world ends up looking a lot more multi-cloud, um than strictly AWS versus, you know, Azure. You got to pick one or the other. Um and, you know, the thing about AWS that I find is it gives you a lot of sharp knives. Uh very similar to the Unix world, right? Like, you know, if if you're ever at the home directory, you do the RMRF star, you know, you're dead, right? And the same kind of thing with uh AWS where, you know, they're doing a better job recently with things like S3 buckets. And making sure that like, are you sure you want to do that? But the original premise was much more like, you're the admin, you know what you want to do. We're going to let you shoot yourself in the foot. And that's why we saw so many things like, you know, public S3 buckets with huge data leak. Is somebody would do an initial deployment and they'd have trouble making it work and they'd do the Unix equivalent of the Chamod 777 and make that bucket public with the idea that they were going to go back and tighten it later on. And never did. And then six months later it goes from test data to production data to leak, right? And that's just, you know, that's kind of a classic sharp knives problem, which is, you know, we give you all the tools to do these really cool things. But if you're not careful, if you're not kind of tall enough to ride this ride, you're going to shoot yourself in the foot. Yeah. So, another thing I wanted to ask you on, which is a good segue is uh the certification paths. If people come from a traditional IT infrastructure background, they have a good sense of cloud as a whole. But are a bit leery around sort of maybe have a a good sense of caution around what they don't know from a security standpoint. And want to experiment a bit more around the the Azure deployment and maybe get into the AWS world. Uh should they start with just the standard vendor certification or is there an approach that you would kind of prescribe for people to follow to get to more cloud-centric and have a have a stronger footing to be confidently deploying workloads there? Yeah, I actually think that the um vendor certifications are pretty good for both um AWS and for Microsoft. And um they're a really good foundation for understanding the infrastructure component of the security stack. And what I mean by that is, you know, how to take advantage of cloud trail and cloud watch and, you know, do your IAM properly and all these sorts of different things. Um they're not going to get up into your app app stack, right? And so they're only going to take you so far. And I think that's one of the things that people have to realize is no two cloud deployments look exactly the same, um, you know, people use different components and different plugins and different APIs and third-party service providers. Um and so, you have to actually build out a fairly robust understanding of all those different components. One of the challenges I think long term for cloud is actually sustainability. Um on the production infrastructure side. I think on the, you know, workload side where you're you're running a a file server or an AD server, stuff like that, that's going to be pretty straightforward. But when you look at the way DevOps teams build their production infrastructures, you know, it is very much a, you know, build it yourself. You know, combine a bunch of different components that have all these sorts of different interconnections and dependencies and the knowledge of that tends to live inside the DevOps head, right? And so, I think there's a lot of long-term risk of um, you know, people building these very complex, interesting infrastructures. Um that are very unique and then somebody else having to come in and learn that infrastructure, um and very similar to, you know, organizations of the past that maybe have built their own internal app stack rather than using off-the-shelf software. And then running into supportability issues 6, 12, 24 months down the road. Yeah, definitely. And, the other part I was uh curious about is I think I kind of know the answer to this, maybe it's a dummy question, but um, do you find the the the native security of on prem versus cloud is similar? Or is it just is one better than the other from a security standpoint? Um or is it just simply the the sharp knives problem uh with with the the cloud infrastructure? So, I would answer that question differently depending on what we're talking about. And so I think on the infrastructure side, there's definitely a sharp knives problem, especially in AWS. Um and so, I think while it's possible to implement AWS securely and a lot of people do that, and there's a lot of tools to actually make it better, right? Um that there are still a lot of sharp knives out there and a lot of risks. And I expect to continue to see organizations uh suffer significant cloud breaches as a result of that. I think on the app side, you can actually get a lot of benefit if you choose a good app provider in the cloud, right? So if you think about using O365 rather than running your own exchange server, right? If you're running your own exchange server, you got to keep it patched and updated and then, you know, one of the things that we're seeing recently. As people start working from home more is like, they start using their Outlook web access and it was never updated so it doesn't support two-factor authentication and so they've got all these security issues. And it's just because, you know, they're not good at maintaining internal infrastructure. Whereas a good SAS provider is actually constantly updating and patching their stuff all the time. And so you're always on latest and, you know, your infrastructure, your workloads are more secure as a result. And so I think it is absolutely possible to have more secure infrastructure in the cloud, that's just dependent on how you use it. Um and I think and in net, it's actually a a big security advantage over time. Right. No, that makes sense. So you mentioned the the work from home. Um obviously with the uh coronavirus issue right now, most almost everyone's working from home. Certainly if you work traditionally worked in an office, you are now working from home. Um I think it'd be uh good just to touch on some of the again those do's and don'ts of what are the things that you should be protecting against, maybe split between both a provider, an IT provider, whether it's in-house or a managed service provider. And then a little bit for the the users as well. The some of the do's and don'ts and things that they should be careful of uh while you're working from home. Yeah, I like to say uh I I was reading somebody tweeted the other day. This is not normal working from home, this is working from home with your kids in the middle of a pandemic. So it's it's not the same kind of environment at all. Sure. Um so do's and don'ts. So the obvious one is um leverage your corporate VPN whenever you can. Um and make sure that that is secured with multi-factor authentication. That's a big one for the IT MSPs. I've seen a lot of IT MSPs turn on VPNs in the last uh 30 days. And not do the extra stuff to make sure it's secure. And those things are just getting owned all over the place. And so that's a big risk. But using the VPN securely allows you to make sure that you're actually taking advantage of all the in-office protections that you don't normally have at home. So this is your your firewall and your web filtering and stuff like that and it gives your IT group an opportunity to see early what's going on. Uh another one for IT MSPs or IT admins in general is making sure that your users are being supported with awareness training right now. Um there are a ton of fishing attacks going on. There's a lot of uh the the criminals seem to have seem to be totally heartless as it relates to dealing with this particular outbreak. And they're they're ramping up their attacks massively. And so educating your users on fishing attacks and other forms of security is really, really important. Um another one is I'm seeing a lot of organizations. In the past they may have may not have supported work from home at all. And so they're having to deal with the fact that people are working from home on personal devices for the first time. Because they don't provide work devices for people to take home or if they do, they don't really typically have all the same security controls and stuff like that. So making sure that both the personal devices that people are using are secure. So, um a lot of uh antivirus providers and stuff like that are rolling out free um malware protection for use on your home computers right now and stuff like that. Um so making sure that they're properly protected against, you know, those kinds of infections and stuff. Um but also that their networks are secure. Um and so one of the things that I I warn about are things like, you know, making sure that your kids aren't bringing malware into your network. Because that can be a point of compromise for your uh for your personal devices, your work devices as well. Um couple other ones. Just really quickly, um making sure that they have an option for secure transfer of information that isn't email. Right. Right. Um email accounts are constantly getting compromised. And people do unfortunately continue to exchange sensitive data over email and that's going to increase because of people just being remote. Um so they can't like bring the document over for signing and stuff like this. And so, um, you know, making sure from an IT MSP or IT admin perspective that your users know how to securely exchange information not by email is a big one for me. And then lastly, um, just using MFA wherever you can, right? Like, um but most specifically on critical accounts. Um your email account is actually probably the most important account you have. And after that, things like your VPN access, your banking, your um your AWS infrastructure and stuff like that. Anywhere else where um where people might um have a really severe area of risk. So, those are those are kind of the top ones for sure. Yeah, great. And uh just a bit about Cobalt before we we break and give people some info on where to reach out to you. The maybe uh can tell people a bit about the work that you guys are doing. Yeah, so Cobalt. We're a security services provider, we focus on small and mid-sized companies. We work a lot with technology companies, Fintech, Healthtech, um as well as e-commerce, those sorts of organizations. A lot of uh organizations that do do a lot of work in the cloud. Um we've been at it for about 18 months. And we do security monitoring as a service, gap assessments, pen tests, the whole nine yards. And really focused on serving the needs and being consumable for small and mid-sized businesses. Um you can reach us uh info@cobalt.io. Cobalt spelled KOBALT.io. Um and also on Twitter, uh cobalt.io and LinkedIn and all the kind of usual social channels. Okay. Yeah, and I'll I'll link to uh to all of those those links as well in the show notes. So. This has been great. Uh appreciate you coming on and sharing some knowledge on cloud security and work from home security, Michael. Yeah, thanks for having me, Todd. Stay uh healthy and stay secure. You too.