Understanding What Cloud Security Means

Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Thanks for tuning back in. Today, we’re going to dig into cloud security and kind of unravel what it really means with Teri Radichel who is the CEO of 2nd Sight Lab, who deal with sort of cloud security really as a consultancy. Teri, thanks for coming onto the show.

Teri Radichel: Thanks for inviting me.

Guy: Teri, before we would dig into that sort of cloud security, tell us a little bit about yourself. What does 2nd Sight Labs do? What do you do? Kind of interestingly, what was your journey into this world of security?

Teri: At 2nd Sight Lab, we do three different things. We do cloud security pen tests, and assessments, and also cloud security training. We’re all kind of about cloud security and helping people be secure in the cloud, and that also involves – Of course, in the cloud, everything is surrounding web application and security as well, so that’s all part of it.

How I got into security is a very long story, which I have written on my blog if someone wants the full story but the very short version is I was running a prior company where I did web application development and hosting, and I got frustrated with spam, first of all. Secondly, I had a breach on one of my systems, and there was no one around to help me, and I had to figure out how to fix it myself. I had moved to a managed hosting company from kind of a colocation facility, thinking they would help me. In the end, I had still to figure everything out myself.

It was just a really eye-opening learning experience, and I got a little bit annoyed that my own money got stolen. No one else was affected. Just me and so I kind of became obsessed with security and how did this happen. I wrote a WAF before WAFs were even a word or a thing and just kind of figured this all out. I eventually went on to get a bunch of certifications and things. That breach is what really kind of drove me into want to figure this out a little bit better than I had known before.

Guy: That’s a fascinating if painful way to get into security. Do you see it now as like a little bit of serendipity, like it sort of at least had got you on a career path that you now enjoy?

Teri: Yeah. I mean, it’s really actually a career that suits me because I think I have this thing where I don’t want people to get hurt. I want to help them with their security, so I want to help with that. It kind of fits my personality. I’m also – I can say needles in haystacks. I used to do database development and e-commerce, things like that and security. You’re always looking for that needle in the haystack. You’re trying to figure out how that person is going to get in, so it kind of fits my personality I guess.

Guy: Yeah. Well, at least something good came out of it. Hopefully, you’ve since kind of recovered some of those losses. You do a lot in security like both with your business and your public speaking and the likes. But I know you’ve recently written a book called Cybersecurity for Executives in the Age of Cloud. I think you talk about cloud security a lot in different events. What I would love to do as I kind of mentioned at the beginning of the show is dig a little bit into what is cloud security, and maybe we start it a little bit more indeed at that business level and maybe take that route down into kind of technology and into the world of developers. Does that sound good?

Teri: Sounds great.

Guy: Let’s start at the top. How do you define cloud security? What does it mean to do security in this surrounding of the cloud?

Teri: I think understanding cloud security starts with understanding cloud architecture, and there are different things that people label as cloud. Some people say it’s just someone else’s computer, but I always say it’s more than that because when I was at a managed hosting facility, that was someone else’s metal computer, right? A physical server that I was renting. The cloud is a little bit different. It’s all virtualized in one way or another, and there are different considerations. You’re kind of counting on the third party to handle some of your security.

When we’re talking about cloud security, we need to understand what parts we are responsible for as customers of the cloud provider and what parts they’re responsible for. Just because they’re doing it, it doesn’t mean it’s not our problem anymore. We have to understand how to assess cloud providers and ensure they’re meeting our security standards, whatever they are. Then we need to understand these new platforms and technologies and how to secure them. There are many of them and they’re different, depending on what type of cloud you’re working in. It’s just a matter of getting in and understanding all those correct configurations.

Like I present in the book, the security fundamentals don’t change. You still have to worry about things like networking, identity management, and all these things. But we have to look at it in a different way and look at new technologies, new configurations, and figure out how to secure them sometimes in a different mechanism or manner that we did in the past.

Guy: What are some of these sort of key changes like some core principles that remain and they’re still a concern? What are like two or three examples where you said well you used to think X and now you really should be looking at this Y or X tag?

Teri: For example, we saw a rush of S3 bucket breaches, and the issue there is that it’s a different type of configuration. It’s not something that maybe IT or even security departments are aware of, understanding how to configure that or how to even do it. Then you have developers going onto the cloud who are not as familiar with – the attackers will find anything you put out there. Just because you didn’t tell them about it, it doesn’t mean, they’re not going to find it. They’re going to be standing there and then finding it. That’s an example where we have something new coming out that has a new type of configuration that people need to learn, and it doesn’t work in like traditional configurations you’re used to in your IT department and in your office or in your data center. That’s one example.

Another thing that changes in the cloud is you don’t have a single sort of fence around everything. You have this distributed network where you’re connecting to all different kinds of systems in the cloud and I like to say the perimeter is not gone, it’s just distributed, so you have to understand what you’re allowing to access your data, and hopefully those cloud providers have appropriate control, so you can let that down.

Another thing that is – in a traditional environment, you have people who are managing the network, and they are – As a developer, I never had the capability to put a database directly on the Internet. It was just not possible. I did not have the permission. I did not have any way to do that. Now, developers are getting into the cloud sometimes before the security team, and they have all these responsibilities and capabilities that they’re not aware of necessarily the risk involved and how to configure those correctly, so we have to bring up the knowledge of the people who are getting these responsibilities if we’re going to give them to them or we have to kind of think about how we’re structuring these teams to put people in charge of the network who do understand kind of traditional networking ways to manage those networks.

Guy: Yeah. All of those are ones that I relate to. I know there’s kind of new technologies and their risks. There is the change in the perimeter and the network. There is the role of developers or rather maybe the ability to the independence of developers with the goodness but also the risk that that entails. How would – When you think about – You call it sort of the cybersecurity for executives or talking about it for people at a high level – at what level of the org do things need to change? Are these just – Because there are a lot of other threats and a lot of other types of considerations that people have to embody that didn’t quite bubble up to the exec level before because, “I’ll just like secure my systems.” At which level of the security organization or of the business do you need to adapt or change your view of security?

Teri: I think there are different issues at all levels. I think in the past, the top executives thought, “Well, that’s the CISO’s job,” or, “That’s the security team’s job. If something goes wrong, it’s their fault.” But at least in the U.S., we know that things are changing because these CEOs and executives have to sit in front of Congress and explain why [inaudible 00:10:06]. “Why did you have a breach? What went wrong?” They need to be able to answer these questions.

This book is to help facilitate them answering the questions. At the highest level, I feel that there are ways we can leverage especially cloud platforms which are all automated to get better metrics in security. I worked on some very complex financial systems like tax laws in the US and things like that. I think if an executive can understand these really complex financial systems, they can understand a basic cybersecurity report that tells them you have so many open ports. You have so many systems that don’t have proper NSA and just really basic statistics.

Then you move down a layer to the executives and the business owner who are trying to get their initiatives and their projects out the door. At this level, someone might come and tell them there’s security risk and someone else wants to get the project done, and they don’t understand it, and they say, “Ah, I don’t think it’s a risk,” and they let it go because they don’t really understand how that particular item can be a problem and lead to a data breach. At that level, these – I always say anyone who’s making a security-related decision should understand basic cyber. Otherwise, they shouldn’t be the one making that decision, right?

Then you move down to the developer level, and they are the ones hands-on implementing and trying to do the right thing, and they just need more education and visibility into what is the right thing to do, what they should be doing, and also be given tools like Snyk or whatever to try to help them find security problems in their environment. I think it’s just at all levels, there’s just different aspects of security where we need more awareness or tooling or whatever – Metrics, whatever will help.

Guy: Yeah. Makes a lot of sense, and I guess it goes beyond cloud, and it’s just the importance of digital as well, right? Just this sort of the growth of the importance of that tier and the legislation changes that went with that. We ourselves as well kind of go a level lower. Maybe we’ll talk a little bit about the good and the bad. If you think about this transition to cloud or you think about cloud security, what are the top three concerns that people should have? What are the top three areas that they need to sort of change or pay more attention to or maybe new threats that they might have? You’ve already slightly alluded to some before, but what would be your top priorities?

Teri: I just saw a report and this was my – I do pen testing and I always include a web application pen test in that because I say the web application is the gateway into the cloud environment. I don’t find a lot of open S3 buckets in my pen test. The probably know I’m coming and they’re like [inaudible 00:12:46]. But I find a lot of web application flaws. Then once you get into that application, you might find a way to go beyond that and pivot and get into other things. I just saw a report that says most of the companies out there are having web application security breaches, and that’s what the problem is in the cloud.

I’ve also seen a lot with identity and stolen credentials left out there in GitHub or in some place where it shouldn’t be where an attacker can get access to or maybe a phishing attack. I really think those are two of the top areas besides just basic misconfigurations. We’re still seeing [inaudible 00:13:27] in Mongo databases. I just saw another S3 bucket exposed, so these misconfigurations are also big problems. Those will be my top three, making sure those things are locked down. Some of that last part about the misconfigurations, some of it has to do with training.

But also people make mistakes, so you have to think about your overall governance, so then your organization as well and how you’re going to set it up, so people can’t make those mistakes, right? How will you structure your teams and how you sort of manage how things roll out to the cloud. Your deployment system is really important.

Guy: Yeah. That makes sense. You’re kind of echoing this back a little bit. You’re saying some aspect of – or maybe your top concerns really revolve around – A lot of it is that change of perimeter that you talked about before, kind of that distributed perimeter that now has all these different applications that can be vulnerable and we need to be worried about them alongside the specific concern around the security credentials and to tackle it – Some aspect of it is people and training those people and some with the tech. What would be your – How would you approach it? What would be the guidelines on which problems you should tackle with training and which problems you should tackle with a technology?

Teri: I like to think about people having to go to the airport and they have to get their bags scanned and they have to do all this stuff. It’s kind of annoying. You have to sit there in a long line, and they check all your things. But why do we put up with that? We put up with that because we have seen instances, we understand that we need this for our security and our safety. With training, I think we need the guardrails. I think we need the things out there to help prevent the breaches with governance. But I think there’s a lot of sort of fighting against this because people don’t understand why it’s there. I think the training and understanding how attackers can get in and what can happen and everything that can go wrong will help facilitate people being more willing to use these guardrails.

Also, it will be great if the security teams and the developers get together to kind of discuss how to make those work, because there’s a lot of assumptions on both sides – Having worked on both sides for many, many years, there’s assumptions that security is just trying to stop us and there’s assumptions that developers just want to make everything insecure, and neither one of those things is true. It has a lot to do with communication and understanding and training, so I think getting those people together or working together is very helpful.

Guy: Yeah. I love the approach or the perspective here. It’s not training for the sake of knowing that you need to put in this or that filter. That’s the guardrail. They should be there. You should [inaudible 00:16:14] validation. But rather it’s almost training for empathy, for an appreciation of the risk, and so that you know that you should care. How do you walk the line between wanting to make people aware of the concern and fear mongering? How do you not become – Because that’s also like – Sometimes, it’s like, “Hey, you’re just a doomsayer,” or, “You’re just talking about all these problems,” and they shut out. How do you walk that line?

Teri: Some people can say that, but I kind of push back up against that. Last year, we had the worst year in record for data breaches. This year, it slowed down. I’m not sure how much of that is due to the things going on in the world, but last year definitely was a bad year, and so people can say that’s fear mongering but it’s fact. At some point, you’re just telling people facts, and it’s not like you want to try to go in and scare people into doing things, but you also want them to be aware like, “Yes, this can happen. This will happen.” We don’t want to be on the front page of the news. We don’t want to have these billions of dollars that we owe due to law suits or whatever.

People who say it’s fear mongering, I guess that’s not my audience. I want to help the people who understand that it really is a problem, and we need to do something about it. If those people want help, that’s what I’m here for.

Guy: Yeah. I mean, it’s a tough one. I must admit that was a bit of an unfair question in the sense that it’s two sides of the same coin. I do love one practice that was echoed here on the show from the Segment team, I believe, is that they use in their Know the Attacker training, they use vulnerabilities that have actually been previously disclosed in Segment, so things that have been reported from Bug Bounty because they found that creates more empathy that people are more inclined to act on it, because it’s vulnerabilities and features they know. They can see how that happened, and so it becomes a bit more real for them.

Maybe taking us slightly, taking the positive stance, still sort of understanding those risks, do you think the transition to cloud also helps aspects of security? Are there other areas? Are there sort of top two, top three areas where you think security is better off because we’ve moved to this cloud surrounding?

Teri: I’m 100% a fan of cloud security when it’s done correctly. I think we’re not doing it correctly in so many areas in so many companies right now. But when I saw cloud, coming from a software background, having to previously manage systems, implement load balancers, build physical systems, which I don’t like to do, I immediately saw that this automation can help us. Also, this segregation of duties that you can implement in the cloud if it’s done correctly which seems to be very lacking but that can be done in the cloud and it can be very powerful.

You have logs going into cloud systems that people and malware can’t change if it’s configured correctly, so you have the ability for unlimited logs and you have the ability to monitor those logs in automated ways and automatically respond to events. You can create governance and guardrails and automation so that – it has to be flexible, so the developers can get their jobs done. But you can also prevent some of these sort of things that are easy to prevent like S3 buckets. You can put guardrails in your account. This makes that impossible to do.

If people are using the tools the cloud offers, we can definitely improve security. We also have things like the machine learning and AI which – Anyone who says they’re doing machine learning on some small data set, that’s not working. It doesn’t work that way. You have to have a very massive amount of data. These cloud providers have a massive amount of data, so they’re looking up this data for their customers and they’re finding flaws and they’re finding things to alert on. I think some of the cloud native security tools are very powerful for that reason and helping you find threats in your environment.

I think there’s a lot of benefits that can come from cloud. At the same time, I understand people who are concerned because they’re losing control of certain things they used to do. I understand that. It’s a tradeoff, and I think the tradeoff for cloud for a lot of companies that I’ve worked in and I’ve seen what they do, especially on deployment night, I think there’s a lot of benefit there if it’s used correctly.

Guy: Yeah. Well, I guess there’s – No substantial change ever comes without pain. There’s definitely a period in between that there’s all that sort of promise at the end of that tunnel. I love the comment on the big data and that amount. We forget how when we moved to web-based emails and Gmails the dent that has made in terms of spam reduction and such because suddenly there was a volume of data to learn from and prevent just one of many examples where – But this type of large data set kind of helped us prevent or sort of fix a problem.

Teri: Definitely.

Guy: Oftentimes you see cloud security teams and application security teams. This is in a cloud surrounding, in an organization that is doing development in a cloud surrounding. You see cloud security teams and you see application security teams separate. Do you think that’s a natural thing? Is it a temper? Is it a part of that evolution that we’re going through that in the meantime we’re putting it in a dedicated team? Or do you think cloud security is indeed quite separate to application security and would remain separate?

Teri: I’ve worked in different companies where we have very limited resources and then a bank with 10,000, 11,000 developers, right? At a financial institution, they’re very concerned obviously with security and stolen money and things like that, and so there are many, many different teams. I didn’t know how many teams there were. I worked in a line of business building back bucket systems and then I moved to the cloud team at Capital One, and I didn’t realize there were just so many security teams focused on different things. I don’t know if that will necessarily change because you have people who specialize in different areas and you also kind of have the segregation of duties. You have people who are kind of inspecting. They’re not necessarily building. I do think your builders and your auditors should be separate. Sometimes, security teams are like auditing teams.

But on another team where I went or another place I went to help them move to the cloud, we only had a team of 30 people, so I made my DevOps team the security team and I said, “I’m going to teach you security now.” It really depends on the environment. But typically, at a large company, like at Capital One, when I moved to the security team, I didn’t get to change anything in the cloud. All my rights were taken away. I was just there to look, observe, audit, and help make decisions. I wasn’t actually doing the implementation anymore, so I think that is typically a good way to go. You have someone who’s watching and someone who’s building.

Guy: Yeah. You can kind of merge the supervisor and the supervisee or whatever. I don’t know if that’s a word. The entity being supervised if you want that to be healthy. On the other side and if we kind of go to that later, we talked about like the security teams adapting and developers, that awareness, but what would you say developers – If you are a developer and you’ve kind of grown up in the pre-cloud era, you’ve sort of built your software engineering skills in that surrounding and now you’re in cloud – how should you think differently about security now that we’re moving to the cloud? What should you be doing differently?

Teri: At the application layer, the application layer itself is not too different. You still need to know the last top 10 top application flaws and things like that. I know there’s different kind of developers. I learned this when I worked for the second company where I helped them move to the cloud. I thought everyone would want to build infrastructure and do that cool stuff like me. There are some developers who just want to build their UI and their JavaScript, and they’re going to be focused on those web application security flaws. But if you are a developer who’s now being asked to build networking or to configure S3 buckets or load balancers or CDNs, you really need to get in there and look at what are the best practices.

There’s something called the CIS Benchmarks out there that will tell you best practices for all three top cloud providers, get in there and understand those. Another big one is anyone involved in networking really needs – I have a full day of networking in my class because I think it’s really important to understand how all these connections create a risk and how they can help you both protect systems and help you spot security flaws. I think that’s really important if you’re on the infrastructure side of things.

Then also, security best practices like turning on MFA everywhere, so you don’t have one of these scenarios where a cryptominer or someone gets in and gets your credentials and starts installing cryptominers in your environment. Set it up so someone can’t steal your credentials and do something with them by using MFA. Just really getting in there and learning those security best practices.

Guy: Yeah. I think it’s a very fair critique to say that it depends on what are you developing, right? I definitely have been guilty often of saying the word developer, and it means different things to different people or it’s just not one entity, so good to sort of separate that app sec, that application developer story from somebody who’s more of a systems developer or sort of deals with the infrastructure as well.

I think we’ve kind of gone through this journey, right? We talked about cloud security at the executive level. What do you need to change there? Kind of have gone down a little bit on the security risks, the security team structure, and some developer activity. Fundamentally, do you think the size of the security teams or the amount of work that remains in the realm of the security team in this cloud surrounding would shrink because – We talked about sort of developer responsibility and needing to take more. Do you expect over time the security team to shrink to have it? Do you think it would grow, there’s more to do? How do you see the future of the security responsibility split between the builders and the observers if you will?

Teri: I think that there is a huge function of security which is not involved hands on keyboard. It’s not about application security and making sure you don’t have a cross-site scripting flaw in your code. Security is about risk. It’s about risk management, about understanding what in your environment could lead to a breach. There’s a whole part of security, which is very important and not involving sort of hands-on keyboard implementation, and that’s not going to go away. The other thing that I think will be separate from the developers or the people building, you have people dedicated to incident response, and they need to be monitoring and watching, doing things like threat hunting. Do you have a web shell in your environment? That’s something I teach in my class. Do you have other sorts of packet manipulation things going on?

There are people who understand these things at a very deep level, and they’re focused on finding and dealing with these threats, whereas the development teams are focused on building things, and it’s a very different mindset. They want to build things and get it out there and make it work. You have these two different mindsets doing two completely different things, and the context switching there to try to do both is just not very realistic. If someone’s focused on building something, they’re not going to be looking at logs at that moment.

You still need those people who are going to look at the logs and be focused on finding those threats in the environment and what do you do. There’s a whole incident response with the things you need to do there to check an event. Is it really an incident? What do you do with it? Do you need to take it to court, chain of custody for your evidence? There’s a whole bunch of things that probably developers don’t even want to think about. Those are still going to be there.

I do think that the security teams right now, they always say there’s not enough security people. We don’t have enough security people to deal with all these things. One of the things that will help is the automation. All these – If you have an event that’s happening repeatedly and it’s caused the problem, some of them may be can be automated to the point where you don’t have to get in the middle of the night and fix it. Then the security team can then focus on more important things like in-depth threat hunting to find things that they don’t know existed in their environment.

Yeah, I don’t see the security team going away ever. I think that there are different functions that occur. I think their jobs could get easier if everyone leverages automation and maybe developers can help with that because the developers can build some of these things, can help prevent the risks that are out there.

Guy: Yeah, I love that. That’s a great – Everything that we can do in collaboration is a little bit complicated but also awesome when accomplished. This has been a fascinating kind of the path down the cloud security journey. I’d love it if you don’t mind to finish off with a couple of learnings or maybe bits of advice from you. The first one is you’ve had this journey, this great career going from I guess building to getting breached to sort of getting into security and now helping a lot of other companies prevent that from happening to them. What are sort of two or three key personal learnings that you’ve learned through this stretch that you can share to sort of help the rest of us improve?

Teri: I would just say that keep leaning. You can learn on your own. You don’t’ need to go to a class. I’ve taken many classes and I have many certifications that I had to get as part of a second master’s program. But you don’t have to go to school. You can learn things on your own, and I’ve been doing that. I learned to program when I was 12 out of a book. It was in the days when people didn’t have computers. Some people – No one knew what I was doing. I didn’t know what I was doing. I didn’t know people did it for a living, but you can learn anything. Just keep learning all the time. That has really helped me in my career.

Another thing is don’t – I don’t try to worry about what people say too much. I just go out there and try to keep – Do my thing and learning and getting better all the time and helping people and just moving forward, so I guess that’s how I approach things. Constantly learning, constantly moving forward, and then trying to share that knowledge with other people.

Guy: That’s excellent. Those are two great pieces of advice, and I guess I’ll ask you. I’ll finish off with a bit of advice that I ask every guest that comes on the show. If there’s a team that’s looking to level up their sort of security competency, their security foo, what’s kind of one bit of advice that you would have to them to kind of help them achieve that or maybe a pet peeve of something they should stop doing?

Teri: Well, of course, you can take my class. I think that security teams and developers have to find a way to work together. I think that’s kind of a theme or – But I come from both sides and I see both sides. I think raising awareness and finding a way to understand each other and work together means we can do amazing things. As I kind of talked about in my book too, I think there’s more reasons to do automation and metrics and that really involves someone who understands security who understands the threats. But it also involves the developers who can develop the systems to help us get those better metrics. I think really if we could get people to collaborate on these solutions and understand each other, I think that would really help security.

Guy: Excellent. That’s great advice. Teri, this has been great. By the way, we’ll put a link to the book on the show notes to ensure people can go check it out, as well as some of the classes that you’re offering there. But thanks for coming on here and sharing some of your knowledge and perspective here.

Teri: No problem.

Guy: Thanks everyone for tuning, and I hope you join us for the next one.