Greetings, the following is a transcription of the SANS ICS Hot Takes video on Cloud Security. In this video, the SANS ICS team was joined by Brandon Evans. Brandon leads the internal application security training program for Zoom video communications. He is also a certified SANS instructor, developing and teaching several of the SANS cloud classes.
Don C. Weber:
In this video, we talk with Brandon about the challenges organizations face when integrating cloud services into the control network. We cover security requirements, data collection, service management and other issues relating to selecting a cloud service provider or integrating a cloud service. If you enjoy the SANS ICS Hot Take series, please like and subscribe to this channel. If you have ideas for future content, please leave a comment below or reach out to us on the SANS ICS forum. Thank you everybody for joining us for another SANS ICS Hot Takes.
I'm Don C. Weber of Cutaway Security, I teach the SANS ICS410 ICS / SCADA Security Essentials class. Jeff, can you introduce yourself?
Jeff Shearer:
Yes, my name is Jeff Shearer. I am a SANS coauthor and instructor of SANS ICS612: ICS Cybersecurity In-Depth. And I also do other cybersecurity work for SANS.
Don C. Weber:
Excellent, Jason?
Jason Dely:
Jason Dely, also a SANS instructor for SANS ICS515: ICS Active Defense and Incident Response and course author and instructor for ICS612. I also do a lot of work within the curriculum for SANS as well as for my business, Northern Strong Security out of Canada.
Don C. Weber:
Excellent. And today, we wanted to talk about cloud security and some of the challenges around that and we've asked Brandon to join us. Brandon, why don't you let everybody know a little bit about yourself?
Brandon Evans:
Thank you so much. Hi, everyone, my name is Brandon Evans. I am a certified instructor for the SANS Institute and the author, one of the two authors for SEC510: Public Cloud Security: AWS, Azure, and GCP. And in my day job, I work as a senior application security engineer at Zoom.
Be sure to properly configure your Zoom application and account settings. Zoom provides information to help you on their Security at Zoom page.
Don C. Weber:
Oh, excellent, excellent. And thanks... Once again, Brandon, thanks for joining us. The reason why I wanted to talk about this is because implementing cloud is such a challenge in and of itself. But when we're talking about control networks, when we're talking about industrial environments, we're talking about a technology that people aren't familiar with. And yet we're having vendors ask us to connect our control networks to the cloud, we're having integrators that are doing this, people are purchasing equipment such as battery systems that have the requirement for cloud connectivity. And when organizations don't understand the technology, they don't know the requirements they should be putting on those. So Brandon, let's start it off. If you can, let us know where people can be turning to, to kind of help them understand some of the requirements they should be asking of these people that are telling them that, "Hey, you need to connect to the cloud."
Brandon Evans:
Certainly. So in the vast majority of cases, cloud services can be secured as long as you have the appropriate configuration. We're not finding a whole lot of zero-days in S3 at this point, we're really finding misconfiguration of various cloud services. So the Center for Internet Security or CIS, has provided a series of benchmarks for all three of the major cloud providers: AWS, Azure and GCP. And they show how oftentimes people commonly misconfigure these services or the configurations are oftentimes insecure by default. And that would make sense, right? These cloud providers want to make it easy for you to get started.
Check out the CIS Control Cloud Companion Guide to understand how the CIS Controls apply to cloud services and providers.
Brandon Evans:
So they'll oftentimes do things like put administrative ports on the public internet ports 22 and the RDP ports. They'll oftentimes give you a lot of permissions to get started with so you can interoperate with other services in the cloud. And that's really good for someone wanting to experiment but terrible for an enterprise. So it's important to look at those benchmarks and see how we can taper down those permissions. And the CIS benchmarks cover a lot of great topics including identity and access management, networking, encryption, virtual machine, storage services and much, much more. So I think that's a great place to get started.
Don C. Weber:
Now, I've heard about the Cloud Security Alliance or cloud security consortium, is that another place? Are you familiar with that?
Brandon Evans:
I'm familiar with that. I'm not super familiar with the white papers or research that they've done but there's a lot of work in this space. The cloud is very new and security as you know is oftentimes way behind the industry. So it's great that a lot of different groups are getting involved with cloud security research, absolutely.
Don C. Weber:
Jeff, I know you had a lot of questions about some of the things that you've seen implemented within the control networks, you want to start it off?
Jeff Shearer:
Sure, absolutely. At the end of the day, an industrial facility is there to make a product. And industrial security is all about making sure all the machinery and all the processes work as intended. What I've seen is some appliances that are actually being placed down into the industrial side and customers are wondering, "How do I actually get for instance, license file so that I have purchased this device? I've gotten my personality file, I've got my license file and so now it needs to continue to report analytics or whatever."
Jeff Shearer:
Some of the challenges that we face is we have some customers that say, "You can't hop one Purdue model." You can't hop two Purdue models, excuse me, you can't have more than one Purdue model. For instance, you can't go from Level 1 to Level 3 or 4 and so the challenges that we have is how do we actually meet those kinds of requirements in an environment where they won't let us do that? So, questions to Brandon is, have you seen any customer-specific requirements? And then how do you advise someone in that space?
Check out the SANS ICS Poster “Control Systems are a Target” for more about the Purdue Model and network architecture of control networks
Brandon Evans:
Well, for a little bit of context, I don't do a whole lot of contract work in my line of work. I've worked for a handful of companies, I did work for one company that was an IoT surveillance company and we worked to integrate software onto cameras and network video recorders to ensure corporate security, corporate physical security. But that was definitely to a different level than what you're describing, I don't think I would trust my code for oil fields, for example.
Brandon Evans:
So I am not certain what requirements certain pieces of software would have, I would certainly say that it has to adapt to that environment. You don't want to have the ability to access administrative consoles remotely for oil fields, it's just not something that is going to work. So in some cases, you may have to work with a vendor to change those requirements because you simply can't enforce the same requirements as you'd have for like a web service. It's just a completely different environment.
Jeff Shearer:
So the takeaway here for me listening to you as a cloud security expert is that, I need to have someone on my team that understands that connectivity. And then secondly, I also need to understand that that appliance that wants to connect to the cloud can't reach beyond its little scope. So for instance, if it's doing analytics and it's reading from ICS devices, we want to make sure that that doesn't creep out into reading and writing those devices. And so we need to work together to actually understand those requirements and you would bring something to the table that I would never think about, while I would keep in my little scope of trying to say, "What is this device supposed to do?"
Brandon Evans:
Oh, one way you can test this very easily is lock down your network according to your requirements and then see what breaks. That's potentially acceptable, potentially unacceptable depending on the criticality of the device and how its configured. I would certainly want to make sure that the device isn't going to collapse a nuclear facility if it's not getting network connection. Hopefully, there are fail safes anyway because we know that networks go down all the time. But that's one way you can certainly do it, is just meet your requirements through network configuration and then see what capabilities work, what capabilities don't work. And if the answer is they don't work, then talk to the vendor and see if there's any ways around that.
Don C. Weber:
So and to kind of get to Jeff's point, kind of reminded me of some of the concerns people are going to have. And a part of that concern is that, when you think about the cloud, a lot of people associate that with a public network and people are going to be concerned about coming down from those cloud resources into the control network and being able to get persistence and propagate on the control network. So have you seen this or have you heard about this within the corporate network, people being able to compromise those cloud assets and gain access to companies?
Brandon Evans:
Well, certainly, but that's a misconfiguration, right? We can isolate network resources in the cloud, that's one of the fundamental building blocks for the different cloud providers. You have virtual private clouds in AWS and GCP, they call them virtual networks in Azure. And you can isolate those resources logically from all the other resources in the cloud and then determine what access if any public access should be granted to those pieces of infrastructure. You may say, "These virtual machines exists on a private subnet, one that does not have an internet gateway and there's no way to access it from outside of that private subnet." You may want to configure your VPN to bridge into that private subnet so that you can do some kind of administration. Or you may just say, "This service is not accessible from the public internet, it's interacted with through a service that is in the public internet that proxies to that private service."
Brandon Evans:
So you have the same controls that you have on-premises, you're just trusting that the cloud providers have implemented those strategies or those mechanisms properly. And as I said in the beginning, we haven't seen a lot of zero-days with these cloud providers. So yes, we're making a leap of faith but it's one that is warranted through so much experimentation across the industry. If another company was compromised through a zero-day in AWS VPC, you probably hear about it before it affects you. So that may be something that people are uncomfortable with at a philosophical level, but it's one that I would trust over relying on on-premises configuration because humans on-premises make mistakes, too. It's not just the third party cloud provider, it's also your internal team. And as more people are going in the cloud, there's less people who have that skill set anyway. So I'd rather rely on the expertise of the people managing these services at such a tremendous scale than try to reinvent the wheel myself.
Jason Dely:
So you bring up a lot of stuff in that. And I think that we're talking about a trust and the thing is, is that if we're looking at an organization that's trying to adopt cloud for... Now, cloud fits into multiple roles for an ICS, right? It could be for data collection analytics, it could be they're using a cloud-based DRP, it could be that they're using as a small municipality and using it for some other scalar function. It could be they're relying on a vendor to provide some kind of service actually or even just using Zoom to try to help them troubleshoot kind of thing. So the thing is that, there's a level of trust that needs to be built up. And Jeff kind of brought up an interesting point which is, how do we bring... It's like in that conversation when you're trying to evaluate the risks, the pros, the cons, there's in general this natural idea that because it's cloud, it's not trusted. And you're kind of standing against that because for the reasons given and that's an important piece that when you're going down these projects, is to pull in people that are aware.
Jason Dely:
The one thing that helps with that or definitely throws in the face to build that trust is, when you're doing it, there's multiple layers of people or companies involved with a cloud solution, right? And you talk about misconfiguration and that's one of the areas where people get kind of uncertain or unaware of or just ignorance, which I say with respect. You've got the cloud provider and they're providing a level of care. You have the application or the solution sitting on top of that and it provides a level and then you have the integration between those two and some level of protected tunnel in order to move that data or that connection. And the thing is, it's like, how does an organization go about unwinding each of those to validate that everybody is doing what they're supposed to do before they make the final decision?
Jason Dely:
And I would paraphrase all of that with, fundamentally, there needs to be an understanding of the organization that there's a use case that definitely makes cloud and an attractive piece not just because of cost for maintaining servers but all the other stuff around it. Anyways, by unraveling that, those different layers of people or interaction of companies, that's a hard part to describe because when we look at AWS and say, "It's AWS." I mean, if they have a problem, their level of respect is going to drop because it's so many people. But XY company that's producing such and such analytic engine that pulls data from the oil fields, for an example, how do we know that they've done it right? How do they know they twisted and dialed all the different things inside the AWS to make their applications secure? How do we walk through that?
Brandon Evans:
Certainly. So to get back to one of the things you mentioned earlier about... There's really two things that we care about when it comes to the cloud; we care about what the cloud providers are doing and what we're doing within the cloud. And there's actually a term for this in AWS, they call it the shared responsibility model. So at a very high level, AWS is responsible for the security of the cloud. We are responsible for the security that happens in the cloud, we are responsible for the security of the data in the cloud as well as the applications in the cloud. And that's more or less where the division of labor happens here.
Brandon Evans:
Now, in terms of the security of the cloud, yes, there's always going to be that leap of faith. We all know as security experts, that the only secure machine is one that is unplugged, probably destroyed and we have to make a compromise between functionality and security. We know there's no such thing as 100% security but we also don't want to take these cloud providers for their word. We want to evaluate them through the vendor selection process, we want to look at their white papers, we want to study their infrastructure and we can read a lot of the research that's been done from offensive security folks interacting with different cloud services.
Brandon Evans:
There have been many examples of individuals hacking cloud services in a way that was not only allowed but encouraged by the cloud providers. For example, there was an issue that was found in the Google Cloud Shell that was found by a security researcher, it got reported to the bug bounty program and I think they paid out about $200,000 for that vulnerability. Now, that's good, we're learning things that are going wrong in these different cloud providers. I would say that AWS and Azure have a substantially higher level of maturity than Google Cloud does at this point simply because more eyes have been on it.
Brandon Evans:
I'll give one example, the Capital One breach that happened in July of 2019. That breach happened through a confluence of different factors but one of the things that AWS did wrong was having an insecure instance metadata service. And if you want to learn what that's about, you can look at some of the talks that I've given for SEC510, there's a lot of details there. But the important thing to take away from that is that AWS had an issue that Google Cloud literally had, the exact same issue. They had an insecure instance metadata service but we only noticed it for AWS because Capital One was using AWS versus GCP. So if you're going to use a cloud that is not one of the, I would say two most mature ones, AWS and Azure, you definitely want to give it a higher level of scrutiny and do additional research.
Brandon Evans:
But odds are, you're going to use a combination of cloud providers anyway. And there's a variety of reasons why people do that and it's one of the foundations of the course I've written. One thing I want to say before I forget though is, I'm not letting AWS off the hook here. AWS has vulnerabilities too, they're not quite as serious as a zero-day in S3 where authorization is just completely busted. That would be really, really obvious to the entire world if that had happened. But I actually found an issue with the AWS Console a couple months ago that took quite some time to repair. And it was a fairly basic issue, it was more of a secure default issue where if you launched a virtual machine and you skipped a particular step, it would say in the summary that no ports were open, but if you created the virtual machine, it would actually open up those administrative ports which would be not great.
Brandon Evans:
It's not maybe the end of the world but the customer was misled about what ports were open. And after, I think about seven months, they finally fixed the summary to say, "Oh no, if you skip the section by default, we're going to turn on the administrative ports for your operating system because again, we want to make things easier." But these cloud providers make mistakes to even the largest one. I've personally found an issue that I believe is a security issue. They didn't think it was that big a deal clearly but it is a security issue and they eventually remediated it but people may have misconfigured things in the interim. So you have to be skeptical but also just don't be more skeptical of the cloud providers than you are these other software providers. I don't see any reason why XYZ vendor is going to be more trustworthy. I would say they're less just because they have less eyes on them.
Jason Dely:
I was just going to ask extension on that because that was great for the provider. How does an organization then, when they're evaluating... Because especially in the ICS space, they're not talking to AWS, they're talking to a vendor that's utilizing AWS to run their application. How do you extrapolate from that particular company that they are doing... Well, unless all you're saying is it's a trust and verify but that requires the app developer to literally audit, did this machine spin up the way I expected it to? But how does the end user evaluate whether somebody...
Jason Dely:
And you may not have direct answer to this but it's a problem because that tenant of that, that's providing that solution to the end user, how do you evaluate that application developer to ensure that they're doing what they can and not... Because a lot of times, it just seem like it's mystical magic and it just I run this application in AWS and cloud is secure. Okay, but there's lots of layers as you described, but how does somebody... Is there a guide? Is there an audit checklist? Is there some kind of method to evaluate the application company?
Brandon Evans:
So I don't have, as I mentioned before, a whole lot of experience in ICS but I have a lot of experience in application developer. I've been a developer for longer than I've been in security, that's kind of how I got started in the technology spaces. I've been programming for a really long time and through programming applications, I learned that there's a huge domain of securing these application and that it's a valuable asset, so I've taken some SANS classes that got me into that space. So I would say that I'm actually more familiar with the development space in meeting the requirements of the customer. And I think the customer just needs to ask a lot of those same questions: What checks are you making in your cloud environment? Are you talking to the cloud vendor and doing the same analysis that we would expect if we were appropriating these cloud services ourselves? And also, what kind of continuous scanning are you doing in your cloud environment?
Brandon Evans:
There's a lot of tools that you can use to look for misconfigurations; Cloud Mapper, Cloud Custodian and then several native tools to the cloud provider like AWS Security Hub and Azure has a security center, GCP has a analogous tool. Looking at your cloud environment consistently and looking for issues and maybe have your vendors send you the results of those reports and have your folks analyze them. There's a lot of data that they can generate for you that is objective so long as they don't tamper with it. And if you find that, that's instant termination potential legal situation that comes about but you can get a lot of information about the cloud. But of course, you also have to do just application security. And maybe you're not doing it firsthand, but you have to make sure that that company is doing application security, that they're actually analyzing their code for issues, maybe using static analysis, dynamic analysis, code review, training, all the things that are involved in the secure development lifecycle.
Brandon Evans:
So it's not just about the cloud, it's also about the application itself. And as someone who works for a vendor that is very popular today and used in a lot of different environments, we approach it in that exact way, we try to add security to all the parts of the secure development lifecycle. I personally am responsible for the application security training at Zoom and all of our developers are taking the training that I helped put together and curate to make sure that as people are developing code for Zoom, they're thinking about security. And if you're not asking those same questions of these folks that you're relying on for your oil fields and electrical grids, it's time to start asking those questions.
Jeff Shearer:
So when I listen to Jason and his questions and I listen to Brandon, his statements and questions, it is not only a layered software model but it's also a layered personnel model. So the folks who are running what we keep saying oil fields, but let's say we're running toothpaste or we're running the grid or running anything, is there's folks who understand the process and they understand what can make that unstable or unsecure. And so those people have to work with folks like Brandon or someone that can say, "Hey, let's make sure that not only the application in the tunnel to the cloud is secure but let's make sure that that isn't going to affect the process. Because after all, we're trying to make a product at the end of the day." So it's really baking into my mind that I can't walk this walk alone, we all need to move forward with our own specialties and work together as kind of a team.
Don C. Weber:
So when you mention Zoom, but I also think about the Verkada incident. And the reason why that comes into mind is because we're talking about environments that, we're talking about vendors that might have multi-tenant environments. And meaning that the data from their clients are all together, the access to that administration for that are all together. And I don't know if you're familiar with the Verkada incident but basically, credentials were compromised for one of their super administrators that provided access into their environment and then that individuals credentials were able to access all of their Verkada's clients and interact with their cameras both on plant floors as well as at a number of locations. So does having a multi-tenant environment for your cloud infrastructure, should people be looking for their data and their services to be individual to themselves? Or should they be concerned about those multi-tenant services?
Be sure to check out the SANS ICS Hot Take: Coors and Verkada Events video with Don, Jeff, Jason, and Tom Liston.
Brandon Evans:
Well, I think there's a more foundational problem for that breach that you're mentioning here which is, why is there anybody on this planet who can access all of these different cameras using a single set of credentials? That's really the issue there. I don't think any specific cloud control would have mitigated that because that's really just a poor usage of credentials. Now, in the cloud environment, we rely on identity access management and network controls in order to deal with the multi-tenancy of these different cloud providers. And that's the vast majority of services. The vast majority of services in the cloud are in fact multi-tentative but they are logically separated using these controls. So you are basically assuming that those network identity and access management controls that are provided by the cloud providers are working properly.
Brandon Evans:
And again, if they didn't work properly, you would have probably seen this by now because there's a huge incentive not just for ethical hackers but also nation states and other advanced persistent threats to find vulnerabilities that are that foundational. So with this assumption, if you use these controls properly, it doesn't matter that these services are multi-tenant because logically, you would not be able to access other tenants data. That being said, this may be scary from an ICS perspective. I would push back a little bit on that because again, in the case of Verkada, they had a single set of credentials that allow them to access all of these different tenants and that's not something that I've ever heard of at the cloud provider level.
Brandon Evans:
But that also means that not everything belongs in the cloud. If you're scared of this multi-tenancy and it doesn't work out for compliance purposes, you have some options; you can put those things on-premises or you can look at dedicated infrastructure for some of those types of services and data. For example, AWS and Azure both support dedicated hardware security modules or HSMs for their cryptographic keys. By default, you are going to be using a multi-tenant infrastructure if you're using AWS Key Management System (KMS) or Azure Key Vault. But if you need a dedicated HSM, they do provide that.
Brandon Evans:
It's really expensive, you really don't want to do it unless you have to, but for some organizations and compliance regimes, it's worth it. So that's another option that you have in your tool belt. But some organizations are not going to accept having some infrastructure in the cloud at all. And at that point, you can say, "Okay, we don't have to put everything in the cloud, we can put some things in the cloud or we can put some things in the cloud that interact with things on-premises in a very controlled way that we can audit." So there's a lot of options that the cloud providers provide to you.
Jason Dely:
Yeah, I think that poses one of the early questions that needs to come up when a company is looking at adopting a new solution to do whatever is, even just the question of if they need data from the plant floor. The age old question that I have is, how fast you really need that data because will that essentially tell you how far down-reaching does that cloud service need to extract the information. And there's other organizations, their customers, clients or whatever, they move the data out and so they're just placing... They move the data closer to the cloud or to their customers than having them reach in and grab it for obvious reasons and I think-
Brandon Evans:
Yeah, and on to that, in general, I would recommend pushing data as opposed to allowing for data to be pulled because if you allow data to be pulled by opening up ports, who knows what pivot points that can introduce? If there's a vulnerability on the device, now potentially, you could have remote code execution and pivot throughout the network. So I would certainly hope that most vendors are publishing data as opposed to exposing it on a public endpoint.
Jason Dely:
See, I think... And this is where... So Jeff brought up the fact that the decision makers are the people that are integrating this in the plant. To them, IT, cloud, they're all mystical people. So a vendor is coming in and they're providing a solution. The issue is that sometimes the vendor has pre-developed the solution which is what you would expect and pre-impose the methods on which these things need to connect in order to operate. And so the issue you run into is like, you could have somebody who's internally really promoting this thing but when you start doing an analysis, you identify this really is kind of a little over the top to what it needs to be and maybe adding more risks than we really need if we were to develop ground up.
Jason Dely:
So there's a kind of a chicken and egg because somebody came, identified that there's a gap in the market, they're going to build an application and they're going to sell the application and they have their preconceived notion as to how it's going to work, how it's going to architect and how it will plug into the facility. And that kind of leaves end users in a position where it's like, well, if I really want to take advantage of that solution because it will drive down my operating costs, it'll increase my productivity and all that. They're kind of like, "Well, if I don't do it, I might lose." And so I mean, it's not really a question specifically for you, it's a question then for us, how is the cloud industry and everybody, how are they trained to... Is there any movement to try to consider when they're architecting these solutions to try to encourage experts, I don't know, some level of flexibility or whatever, to make it more sizeable or chewable for end users?
Brandon Evans:
I mean, I think that we live in a world where there's competition and there's a lot of people that are trying to win that company's business. It seems to me like security is a very foundational feature set, it's something that really matters to the customer. And if you find that a vendor is not doing those things, other vendors exist. And this could be a great motivator to say, "Hey, you're going to lose our business unless you implement this using reasonable security standards." I think that there's some leverage that can be placed on these vendors. And if the company is saying, "Well, I want to use this anyway. I don't really care what the result of this audit is, I just want to use the software." Well, then they're probably wasting a lot of your time and that's not a great thing for them to do, either.
Brandon Evans:
If they're going to hire you to do analysis of these vendors and how they could be integrated to the plant, they have to accept the possibility that the answer will be, "No, we cannot have this in our environment and we have to evaluate other solutions or build our own solution." So I think that this is largely not a technological problem, I think it's largely a business and negotiation problem. Like if you're using some random vendor that doesn't do basic security things, like for example, it requires a port to be open on the public internet in order to support analytics, there's got to be other vendors you can evaluate. That just doesn't seem acceptable to me and I would never accept that.
Jason Dely:
I agree. I think the way you've brought up is, the other item is education. Because by the time it gets to the point where somebody is configuring the network to make that happen, the solution is already sold internal. So the education is that, from our end, from the ICS community is, plant managers, automation engineers, people that are actually in charge operations understand what questions to ask and how to have that conversation because I think a lot of them don't. I find the industry in general, there's a lot of positive motivation to do good things and believing that people are there to help them but they're a little passive in really asking hard questions that might take the energy out of the room so-
Brandon Evans:
So why even ask the questions when they could hire you all to ask the question? Now again, you all get involved or if you want. It seems like... I'm almost kind of incredulous that they're not doing this. Involve you all early on in the process, shift left.
Jeff Shearer:
Yeah, to me, when you actually go boil a factory down, and I don't care what it is, there's receiving of raw goods, you put something together, you package it and you send it in most cases, when you look at this, the smallest amount of work like the indivisible cell, that's the thing you can't interrupt. Whether you're making parts for an automobile or you're making food, eventually, you get down to a point where there's autonomous control that's occurring and then there's everything else that's trying to provide visualization of what's going on in that process and data records of what happened. So what am I doing and what happened?
Jeff Shearer:
And then at some point, you can break that down and you can say, "I can insert a service here and go send or receive data from somewhere, whether it's office or whether it's one Purdue model higher or if it's a cloud." And so somebody needs the architect, that architecture is very important. And when you say, "Hey, the cloud could either interrupt this process by not being available to make my data, like print a label or something." That's how you kind of architect this whole system. You say, "I can't afford for a long hop or a hop to not be there in order to run a printout or to slap a label to ship a thing." And so that's kind of how factories divide this out and then eventually, there's a logical insertion point of where cloud can actually enter this. And so that's kind of how I think about it.
Don C. Weber:
So I mean, when I think about what you just said, I think about a mentality that it's commonplace within industrial which is that they set it and forget it. Meaning that you get something in place, you set it up, you make it work and now it's working, don't touch it. And I'm kind of afraid that people are going to take that approach with the cloud where this is information that is going across an enforcement boundary. We are sending information to the cloud, to network infrastructure, to equipment that other people are responsible for, whether it's a service or whether it's that cloud provider. And that you can't forget it, you have to periodically come back and evaluate the configuration because things change over time. Especially if your organization isn't managing it, you need to understand what decisions people are making and that requires a periodical analysis review and assessment of that connectivity considering that it's information access across an enforcement boundary.
Jason Dely:
I think that means is that there's another tier to managing this. So if the plant identifies a benefit for a solution, there may be a model where they just go ahead and they sign it and sign up and then they pay for it and everything else, but what you're bringing up is an important element that I think would be a service that the IT organization or department may be able to support and that is the ongoing auditing to make sure that all the chess pieces are where they're supposed to be and moving in the right direction.
Jason Dely:
Because I think to your point, automation folks, and this isn't a slam to them is, they'll put a visualization system in, it's working, great. They wait for it and then they move to more of a break/fix mentality. They're not really... In some ways, yeah, they'll do some preventative maintenance and so forth but they're not really set up to audit and scrutinize and maintain that relationship between the cloud organization and themselves. So I just want to put that in there, there's another element that needs to be brought to the table when these decisions are made.
Brandon Evans:
Absolutely. And I can definitely say you do not want to set it and forget it, you absolutely want to maintain it, continuously audit it. There's so many things that can change over time or things that don't change that are now considered to be vulnerable through the discovery of zero-day dependencies or dependencies with zero-days, I should say. I used to think as a developer growing up, I used to think that code was kind of like art, you develop it once and then you can hang it on the wall and it just works. But now as I learn more about security especially about component analysis, I think of code as a vehicle. Vehicles break down with use, over time things become obsolete. You'll find that a component that is in that vehicle is now on a recall and you need to replace it.
Brandon Evans:
And I mean, there's entire area of study and security about component and analysis, not just cloud components but also software components. And if you're using all of these cloud services and your vendor is not doing that kind of analysis, looking at the components that your application is built out of, using static analysis to look for actual issues in the code, doing proper code reviews to find business logic issues these tools can't find, doing dynamic analysis in order to find issues at a higher level, SQL injection, cross-site scripting, missing headers, looking at the cloud configuration in which all of this exists.
Brandon Evans:
And that has like 70 different subtopics when it comes to networking, identity, access management, key management, containerization versus virtual machines. Serverless is a new thing, multi-cloud integration, I mean, the list goes on. You can't just set it and forget it, you need to have someone even if it's a third party consistently auditing this and then giving you the reports that you can then use to take action. And if you're not doing that, then don't be surprised when your car breaks down.
Jeff Shearer:
Good points.
Don C. Weber:
Well, I think that we've covered a lot of great information and Brandon, I really appreciate you joining us to do this. What I'd like to do is kind of go around and get some last minute thoughts. So Jason, anything you want to bring up before we...
Jason Dely:
Kind of recapping it, we covered a lot but the thing is that, I don't want to say I'm neither for nor against cloud uses in ICS, from a standpoint of ICS organizations have to stay competitive. They have to look at ways of reducing cost. But the thing is, is that it's not something I've done in a blind manner. And as just in those last conversations brought up, you may be offloading the management of the infrastructure but you are onboarding a lot more process and procedure from an organization and is heavily overlooked in the ICS space when they start going around a conference and they're seeing all these fancy fandangled things that they could utilize. And that amongst with evaluating the risks, they need to truly understand is that something that's worth organization.
Don C. Weber:
Jeff?
Jeff Shearer:
Yeah. For me, cloud is not evil but it has to be inserted at the right spot. And I'm a big, how-do-I-keep-my-factory-working kinda guy. And at the end of the day, companies are in business to make a product and a profit. Analytics and different insertion from cloud technologies will help us but it has to be at the right level so...
Don C. Weber:
In my experience in the last two years have been that, while some people are accepting this, there's still a lot of organizations that are saying, "No cloud whatsoever, we can't have a touch control network." And me personally, I think that's putting your head in the sand. Even if you're not going to allow it, you need to have a plan for it, you need to understand that, that some vendors are going to start requiring that. So start thinking about it now, start understanding it now, getting your teams to wrap your head around it and so you're prepared for those vendors that are going to say, "Hey, now these things need to connect up here." So Brandon, once again, anything that you'd like to leave the audience with, sir?
Brandon Evans:
Absolutely. To continue on Jason's point, it seems really interesting to me that in a traditional software organization that is not working with all of these on-premises pieces of infrastructure, usually the move from on-premises to the cloud is more about giving up responsibility. People are uncomfortable outsourcing all this configuration, all of this management to the cloud. It seems like in the ICS space, going to the cloud is introducing more responsibilities that the plant managers are not necessarily even thinking about. And I think this is really potentially exposing a problem that existed outside of just the cloud, the reliance on vendors and taking vendors at their word in terms of how their software works because you're using network controls in order to compensate for potentially catastrophic issues with the software itself.
Brandon Evans:
But there's a lot of damage that can be done even on a private network, popping from one device that is not connected on the internet to potentially one that is. And there's a lot of things that can go wrong if you're not doing proper software security. So it seems to me like the cloud is exposing issues that the ICS community needs to reckon with sooner or later regardless of whether or not they put their data on the cloud. But I think that when you can rely on a vendor like the different cloud providers that we have here that are operating in such a unbelievably tremendous scale, you can actually reduce a lot of the work, reduce a lot of the things that you have to think about. You can take for granted that identity and access management is going to work if you configure it properly. You can take for granted that network controls are going to be working properly if you configure it correctly, etc.
Brandon Evans:
But you have to be familiar with how these mechanisms work and especially how these mechanisms differ from the different cloud providers. So SANS has a Cloud Security Curriculum now that you can learn more about at sans.org/cloud-security. And it'll talk to you about all of the free resources we have, as well as all of the courses that we provide. My course, SEC510: Public Cloud Security: AWS, Azure, and GCP is really focused on teaching you the differences between these three cloud providers because there's a lot of differences in the methodology and the implementation of these different clouds.
Brandon Evans:
It's not like they invented the cloud with a standard in mind, no, they're all doing things very, very differently. And if you learn one cloud provider, you can't necessarily take that skill set and export it to another one. So by taking this course, you can understand not only all of those controls that I mentioned to you today and more, but also how those controls differ from the different cloud providers. So I really hope that you'll check out the SANS Cloud Security Curriculum, there's a lot of great resources out there that can help you get started.
Don C. Weber:
Awesome. Well, I appreciate everybody's time today. Thank you for joining us to talk about the cloud and ICS. Have a great day.
Jason Dely:
Thank you.
Brandon Evans:
Thanks for having me.
Don C. Weber:
Thank you for tuning in to this ICS Hot Take with the SANS ICS team. If you'd like to join the SANS ICS community, please check the show notes for links to the community and other resources provided by the SANS ICS team. If you have comments about this topic, please add them to the comments below or reach out to the SANS ICS community. If you'd like to see more content like this, please like and subscribe to the SANS ICS channel. Thank you and have a great day.
Speakers:
Resources:
- Zoom
- Center for Internet Security
- Cloud Security Alliance
- SANS ICS Community Forum
- Cloud Mapper
- Cloud Custodian
- AWS Security Hub
- Azure Security Center
- Google Cloud Provider Security
.jpg "ICS - Blog - ICS OT Cybersecurity & AI Considerations for now & the future - Part 1_340 x 340(1).jpg")
