DevSec For Scale Podcast Ep 5: Cloud Security for Startups

Startups have a different makeup than large organizations. Their DNA is just different as they are more lean and agile. This offers startup developers the ability to shift their security as far left as possible and make the right moves from the beginning to secure their infrastructure and applications.

However, not all startups have a security team to ensure this happens. Thankfully, we have quite a few exhaustive resources that can help developers at startups cover the most important issues from the early stages. These include resources like the OWASP Top 10 project and the Cloud Security Alliance publication titled “Cloud Security for Startups.”

In this episode, Moshe Ferber, Chairman and member of the board of the Israel Chapter of CSA discusses the application security aspects of these comprehensive guidelines and how to better secure your SDLC and CI/CD pipelines with a shift-left mindset.

TRANSCRIPT

Jeremy Hess: Welcome to the DevSec for Scale podcast, the show that makes security a first-class citizen for growing companies. My name is Jeremy Hess, Head of Developer Relations at Akeyless, the secrets management SaaS platform. This interview podcast brings security experts and practitioners together, to offer practical and actionable ways for small and growing companies to implement security best practices using shift left principles, without interrupting developer life cycles.

Alright everybody welcome back. We’re really excited to have Moshe Ferber on the line with us today for this episode. He’s the chairman of the Cloud Security Alliance here in Israel, the local chapter. And before we get into detail Moshe about you and your background, can you please give us a bit of information? How does CSA work for startups, and how does the Israel chapter contribute globally to what CSA is doing?

Moshe Ferber: Okay, so first thank you very much for having me here, Jeremy, it’s a pleasure to be with you on this episode. As you said, currently I manage the local chapter for the Israeli Cloud Security Alliance. And because we are Israeli and we have such a vibrant startup scene, there’s two things that we contribute to CSA Global on this aspect. The first thing is that every year we have a conference that is called the CSA Innovation Conference. It is part of the Israeli Cyber Week, one of the largest cyber conferences in the world. And over there, we present new startups, new technologies. I’m not sure if you’re aware of this, but the first time that we hosted this conference a couple of years ago, Oded (Hareven), the founder of Akeyless, was one of the people on board that joined us.

Jeremy Hess: I watched the videos.

Moshe Ferber: Yeah, it was corona time actually so it was a virtual event. Yeah, now I remember that. Yeah so we know Akeyless for a very long time. The second thing that we do is we publish Cloud Security for Startups, which is a CSA official guide for startups that are building themselves on top of cloud computing, which I think today is 100% of startups or maybe 99% of all startups, because it makes a lot of sense. Now I want to say a couple of words about this document. Let me share my screen for a second if this is okay.

Currently, you’re looking at version one. We are working on version two of this document. But the first question I always get is, what is the difference between cloud security for startups and/or any other organization that is boarding the cloud? This is a good question because there are many cloud security checklists, guidelines, and best practices out there. But how is a startup different? Well, I’m drilling down all the way to this graph. What we basically did in this document is we divided the different phases that organizations need to do, and we built it according to the different funding rounds of startups.

For startups, there’s always the seed round where you still need to build your product, and then there’s the second round when you start to acquire customers. Usually those are customers who are familiar with you, and it’s easier to bypass their screening process. And later on there are the more advanced rounds where you grow your money, where you grow up and you are basically building your maturity. You’re maturing with your services, so we adapted the guidelines based on how much money you have, and which phase you are in in the life cycle of a startup.

So, this is what’s unique, and it basically gives you, if you’re security or the founder of a startup, it gives you the landscape of how you need to mature yourself based on the different phases and the amount of money that you have, and the acquisition of your customers. These are the major things that we contribute for the Cloud Security Alliance, and this document is available for download for free from the Cloud Security Alliance website. I urge you all if you’re a founder at a startup, definitely if you’re a founder at a startup that maintains and stores customer data. If you’re provisioning SaaS applications, for instance software as a service, then security is mandatory, and customers will ask you questions. I think this document can help every one of you in the process of planning and implementing security.

Jeremy Hess: Absolutely yeah, it’s a lot of information there too that’s really important. GDPR is just the beginning of storing data and then you have all other security compliances in stock too and everything else. So, before we get into a little bit more detail about the startup world and how CSA is contributing there as well, can you Moshe give us a little bit of background about you – where you come from and what you’ve done so far?

Moshe Ferber: Okay, so my background is information security for the last 20 years, or actually 22 years, coming from a very technical background. My first 10 years were working for large enterprises, building anything from identity management, patch management, and security formation management. And building those products by hand or being the product manager for those types of deployments. After 10 years, like many of the people in Israel I switched to the entrepreneurship scene. I’ve been part of many startups, some of them more successful, some of them less successful. But there is one common thing between all startups – about 10 years ago, we started developing on top of cloud services.

Before that we used to borrow our hardware from the family and everything we could put our hands on. We built them together and we used to imagine that we had a resilient infrastructure, and that we could be enterprise scale. But when AWS came in, and later Microsoft and Google, this whole thing changed. An entire scene changer for startups, and this was the first time that we were able to build something really resilient, really enterprise grade from day one.

So, this really changed the way that we work. I was looking for the thought leaders who could help me understand the market and the different players in the market. Who could help me understand the best practices. And this is where I came across a small organization at the time. 10, 12 years ago, it was a small organization, and I’m referring to the Cloud Security Alliance. And ever since then this is my contribution to the community. I was involved in creating the certification for the Cloud Security Alliance. Later, for other organizations that the Cloud Security Alliance works with. I helped ISC² build their own cloud certification, and ISACA with their own cloud auditing certification.

Basically, I talk to many organizations from startups to governments on how to build their cloud security program. And this is why I’m sitting here with you.

Jeremy Hess: Yeah, that’s great. Wonderful. Okay so now that we have much more of your background and we see why we’re here today. So, diving a little bit deeper in that table that you showed us from CSA. It talked about application security in the middle layer over there, and when we talk about application security, a lot of times we’re also talking about the CI/CD pipeline. So, what have you seen generally speaking in startups is an average looking CI/CD pipeline at the beginning? Like what does that look like, and then we from there well let’s start with that, and then we could talk a little more about the security side of them. What does just an average CI/CD pipeline these days look like? I mean because startups, a lot of them will just use AWS for example, or just GCP or just Azure. They don’t really go multi or hybrid cloud right away. So, are you mostly seeing that it’s just one cloud and that’s it? And then what are the applications? What are they using in their pipelines?

Moshe Ferber: Okay, so a lot of questions, let’s try to answer them in an orderly manner. First of all, I’m going back to the document just to work on the different pillars that we have. So, we have the platform security. This is basically the actual cloud platform itself and the security measures that we need to implement in the cloud platform itself. Now, if you make too many mistakes here, it’s easy to repair. Again why? Because it’s the cloud. You can drop everything and build everything from scratch. So, this is a challenge, but not your biggest challenge.

When we talk about security management it’s basically how you manage the entire security frame: the different compliance that you need to adhere to, how you do risk management. when is the right time to bring the CISO, the Chief Information Security Officer to the organization, and when is the right time to mature different things that are not technical, like policies and stuff like that? So, this is the security management. And we have another pillar, and this is the pillar that you, Jeremy, mentioned. This is the pillar that we’re going to focus on, and this is the application security pillar.

In application security, this is where you can make the most, this is where startups make the most mistakes. And why are these mistakes worse than the platform security mistakes? Because it’s harder to fix them on time. As I said, when you’re working on the cloud, you can very easily drop everything you’re doing and build your infrastructure from scratch. In application security, if you build your application in the wrong way, I mean not according to best practices, you have to go back and start from scratch. This is why application security can cause most of the delays and create most of the troubles for the founders. So, this is about application security.

Now, again the trying to shrink the discussion. When we talk about application security, when people talk about application security, they usually think about SDLC (Software Development Life Cycle) or SSDLC (Security Software Development Life Cycle). This is usually, when information security professionals hear the word application security, this is what they think about. But actually, SSDLC, which is an important methodology, doesn’t cover the entire framework of application security or all the aspects of application security. SDLC by nature talks about the design and development phase of the application. But when we talk about application security, we also talk about the design phase, the deployment and testing phase, and the ongoing operations. And all of these have aspects of application security inside of them.

So, first, the first mistake startups make is saying, okay, I have mature SDLC methodology. This is not enough; you also need the ongoing operations and the deployment phase to be matured. So, SSDLC tells you only part of the story, I’m putting it aside. Let’s talk about the deployment and testing phase, which basically leads us to CI/CD. Application security, SSDLC hasn’t changed too much in the cloud, right? Different architecture, different job roles, we talk about developers who access the production more, micro services, different architectures. But we’re still developing the same frameworks. We’re still getting vulnerabilities by the OWASP Top 10. So, nothing has really changed.

What really changed in the cloud or in the new technologies that we see is the deployment testing, and why is that? Because the pace is changing. In the past we used to have security testing every couple of months. The deployment cycles were very long. We used to develop in Waterfall Methodology. So, the information security professional knows that in 3 months they are going to need to do a code review and in 6 months they are going to need to do a penetration test before we go live.

Now this is true for companies who develop traditionally. But new companies who are cloud native, they develop really fast. So, we have a development life cycle of between a week to three weeks. We are deploying to production not once in 3 months, we are deploying to production sometimes 10, 20, or 100 times a day. So the pace is really changing, and this puts a lot of pressure on information security who used to do things manually. And this is most of, all of this long introduction is just to say that because the pace of development is changing, we also need to increase the pace of the security testing.

Otherwise, if you don’t do that, if the information security professional fails to do so, basically, they will develop the product without security. They will pass all the gates that information security needs to have in order to make sure that the software is accurate.

Jeremy Hess: And before we go forward, let’s talk about why in your eyes and your estimation, why is it so important to make sure that the minimal amount of security at least is in place properly before you even deploy your application to begin with?

Moshe Ferber: There are two aspects here. First, when companies moved to the cloud, when for instance startups moved to the cloud and when banks started to, or highly regulated industries, or everybody started to consume cloud services. The only thing that a bank can do with a SaaS service is make sure that they’re mature. So, this puts a lot of pressure on the SaaS companies on how they develop their products. And suddenly, in the past they used to develop a product and ship it to the organization. They were not responsible for operations. They were not responsible for incident response, log management, and stuff like that. So first of all, moving to SaaS puts a lot more responsibility on those companies. They used to develop and ship. Now they are required to do ongoing operations.

Second, because the customers of the SaaS companies, all they have is the ability to ask questions and verify that you are mature. That puts a lot of a focus on how you do your security. And again, I’m not talking about, I’m putting aside stories like SaaS companies who got breached and breaks. Because the worst scenario for your hand, we will not create. Probably, statistically you will not get breached, you will not have your information is stolen. Statistically, I’m saying. It might happen to you, but statistically.

Jeremy Hess: Yeah, there’s always that, information security people always say, well, one of the excuses we always hear from people is oh we’re too small to be breached. No one cares about the data that we have. Unfortunately it becomes, very quickly people realize well looks like we aren’t too small. We do have data that people will try to catch with the easiest means they can. Whatever automation tool they have to just put into your system. They’ll do it because it’s automated anyway. It doesn’t take any more effort for them.

Moshe Ferber: But what I’m trying to say is that if you don’t have proper security in place, your sales cycles will be longer. And suddenly, you’re in the middle of a sales cycle when it comes to the security professionals, then suddenly there’s a void. You don’t hear anything. You have no feedback. You don’t know what’s going on. The sales cycle is stuck. Why? Because you didn’t give the information security professional the right answers. So, even if you don’t get breached, if you’re lucky and you’re not part of the statistics. If you don’t have proper security tools and you’re selling to enterprises to organizations, you will not be successful in your business. And this is I think the biggest threat and this is what founders need to understand. They need to mature their application security. Again, not because of the threat of information security failure, but because companies will refuse to work with them, especially companies that are under regulation and stuff like this. So, my urge to everybody is to mature their services as soon as possible, because it will help them create a better company with faster sales cycles.

Why do we need, why do I focus on application security? Because today the industry is talking about shifting left. What do we mean by that?

We have a pipeline. On one end, we have a code developer working on code. The entire goal of everything that is related to cloud; when we talk about DevOps, micro services, Kubernetes, and every other buzzword you will hear, the goal of all those buzzwords is to make sure that when code goes into the pipeline on one hand, and gets into the production on the other hand, it does it as fast as possible. We don’t want to wait for a version, and we don’t want to wait for manual testing; everything should be automated. So, what’s the idea of shift left? Understand as soon as possible what your security defects are, where your security bugs are. Because if you detect them closer to production or in production, it costs much more. This is where you have questions from customers and this is where you have downtime, and you want to avoid this.

So, why should companies invest? First of all, it’s good for the business. Second, it will help them do things more reliably and cheaper. That’s the idea of application security in the cloud environment. The quality assurance guys understand, the developer guys, all the development teams understand that they need to be automated, that they need to be fast. Now we need to make sure that the security professionals get this concept – that they need to do things fast and automated. This is where we start our discussion on CI/CD pipelines.

What is CI/CD pipeline? Continuous integration. So, developers finish up a code. Now this code needs to be integrated with the new, sorry with the old code to create a new build version, deployment, whatever you want to call it. So, continuous integration is the process of taking the old code and integrating it with the new code. This is one phase. Second, now we have a new code. Now we have a new version that we need to test. Continuous deployment means that we deploy this new code first into the testing environment, and later on into the production environment.

So, this is CI/CD, and in short, it makes sure that we deploy fast, as soon as possible. As soon as the developers finish a new feature, we make sure that it will be rolled all the way as fast as possible to the production. Mature organizations can do this cycle within days. That’s the idea. As you already understand, there is no value in doing this manually. So, everything needs to be automated. The quality, all the processes of integration needs to be automated, the quality assurance testing. We stopped doing them manually, we started basically developing automated tests, and the security guys need to automate their own testing.

The professional term for this is that we are building guardrails. So, the entire building of the infrastructure with the coordinator is created inside the guardrails. So, we can build an infrastructure but based on certain guidelines. For instance, we are going to build a testing or a production environment automatically, but we are going to make sure that there are no open buckets or no open ports from the outside. Okay, those are basically the guardrails. We build the environment; we build everything automatically based on a certain standard. And throughout the guardrails, we need to have our security gates. This is the security testing that organizations do throughout the life cycle itself, to make sure that the software is valid, free from bags, secured – everything they want to ensure.

So, what I’m going to do in the next couple of minutes, if this is okay with you, is work on the different guardrails that we need to have along the way, in order to for our listeners to understand the different security gates and the different testing they need to implement.

Jeremy Hess: That was part of my next question. How does that work, and is that also connected with funding rounds of startups specifically? Is that something that you put in buckets?

Moshe Ferber: Yeah, well basically, I’m going to state like 5 or 6 different tests, okay. You cannot do them all from day one. You don’t have the money, you don’t have the manpower, and probably your application is not that complex. So, the rate of you adopting these different security gates and when you adopt them, is dependent on your funding rounds. I will try to say for each test, for each security gate like this. if it makes sense to perform it at the beginning or at the end. I’m not tying it to a specific schedule or to a specific funding round, because it’s very dependent on your software. If your software is for highly regulated industries, it’s very intrusive, and you keep a big amount of PII, then you need this to do this earlier. If you’re selling to consumers and not organizations, and you’re not too intrusive, you only keep very minimal PII, you can do this later  in later stages. So again, this is mostly dependent on your business.

So, what are the security gates and how can we make sure that they are built as we said mostly to the left? So, when a developer starts building, he usually doesn’t build anything from scratch. He adds external open-source packages. Like Gartner says, 70% of the software that is developed inside enterprises comes from an open source. So, the first test that you want to do is examine the packages that developer is incorporating. And I think you have an episode of that, probably your 3^rd episode in the podcast was about something similar to that or identical to that. How do I examine the open-source packages that I’m working on. We all understand after Log4J why it is important to map them and to give them different points.

Good products will be, as soon as the developers decide to include a new package or examine a new package, they will give some kind of insight on this package. If it’s vulnerable or not, what is the reputation of the developers, that maybe it has a better version. So again, shifting left means that from the developer dashboard, they need to provide this instance. So, this is the first test that we do,  and it’s also, the official name for it is SCA (Software Composition Analysis). And I will drag something more into that for the sake of time. We will also examine, for instance, when you build your virtual machine or your containers you use images. Those images often come from external sources. Then you need to examine those images as well to make sure that they are not vulnerable or don’t contain any malicious software.

Sometimes it’s part of the SCA, sometimes it’s a different process. But again, you want to do this as soon as the image is built, and not wait all the way for the production to find out that this image is vulnerable.

Moving on, the developer is working. Now he has a feature. Now he has a new code that he wants to integrate. This is the first time that we examine the code itself, and usually this is a test that is called Static Analysis. Static analysis basically reads the code and identifies, for instance, if we have an input field that doesn’t have a limitation of the size, and various aspects of the application and security mistakes that developers tend to make.

Again, shifting left, the best way to do this is, some of the more mature tools are even integrated into the developer’s environment, into the IDE. And once the function is built, they’re already giving him comments as he writes the application.

Jeremy Hess: Yeah, a feedback loop right away is always great. We’ll talk more about tips after you finish explaining this whole thing to us. We’ll go through some tips that you have for the developers so I’ll let you continue. Go ahead.

Moshe Ferber: Okay. The next test. So now we have a version that we already tested. We want to, sorry we tested, we read the code. Now we want to deploy it into the testing environment and start our testing environment. Start our testing procedures. This could be regular testing, QA, unit testing, regression testing, or security testing. At this point where we have an application that is already running, we usually run something that is called Dynamic Analysis or DAST.

Dynamic analysis doesn’t read the code. It’s black box testing. It tests the code and makes sure that it’s not vulnerable by actually trying an attack and seeing if it works. So, they put in a large input field to see if they can do off buffer overflow, use different encoding and stress load to see if they get an error message from which  they can learn about the application, and stuff like this. Most companies start with dynamic analysis. Most of the startups, sorry, start with dynamic analysis and not static analysis. Why? For dynamic analysis, there is a bigger variety of open-source tools. It’s a more, I wouldn’t use the word mature but it has had more years in the field, and we have more experience with it, and it’s easier to integrate.

Static analysis needs to integrate to the source code and needs to understand the frameworks that you are working with. Dynamic analysis you simply point it at a URL and you can start working. So usually, organizations start with dynamic analysis and when they make sure they add the static analysis.

Another thing that we have is we are going to deploy an environment now. We are basically, companies who are cloud native, startups or cloud native, basically deploy each time they test. They deploy the entire test environment and maybe later even the production environment from scratch. When you deploy it, you use a template. In this template we describe everything that we’re going to build. We’re going to build three VPCs connected with peering, we’re going to build these servers, and this managed database. So basically, we describe everything we’re going to build.

There are tools that check those templates. Infrastructure as code templates we call them. And basically, they tell you if this follows your security standards. There are no open loops. There are no holes, no open buckets, no open ports. They will also check that you are not using any secrets that can be exposed later.

A word about secrets, okay. So, what are application secrets? Basically API keys, access keys, connection string to databases, various types of text or strings that enable us to connect to different services. When you deploy a modern application today, especially if you’re doing this with CI/CD pipelines, you have tons of API keys. Because everything is connected to one another, so your CI/CD service goes to GitHub and pulls up the code that’s an API key. It then goes to Terraform or Cloud Formation or any other service and tells it to deploy the environment, it uses an API key or an access key.

Different application components talk to each other. These all fall under the category of application secrets. Now, the common mistake is to store the application secrets inside configuration files inside the template, inside the code, and this is where you get your headline. Because this is not the right place to store those keys. What is the right place? A location that is built for that, and cloud providers have their own services with their own benefits or with its own pros and cons, and there are external services to do so. Akeyless is one of those services that can also help you with storing keys.

So, when you just check your information, sorry your infrastructure as code templates, you need to verify if you’re storing keys or anything else, or if your deployment breaches some kind of production protocol. And if not, you are good to go. So, this is where we deploy everything, and then once the testing is over, we deploy into production. Usually, we use two different pipelines. This is the best practice. And why again? Because we don’t want the secrets from the test environment to get mixed with the secrets for the production environment. This is why we separate those two pipelines into two different environments just to separate everything between them.

And after you deploy, there’s the ongoing testing like vulnerability testing. Some organization even though I talked about automation still do, once every major version, they still do manual penetration tests, okay. This is a compensating control to make sure that you’re still doing that, you say automation doesn’t keep secrets. I mean doesn’t hide anything that you want to know. So, some of them still use manual testing. But again, it’s a compensating control, it’s not part of the pipeline. Yeah, I think that’s was a lot.

Jeremy Hess: Yeah, I mean this was a full, almost like a little degree that we just got in CI/CD. So, that was a fantastic explanation, and of course making sure that you’re implementing security throughout that whole development life cycle. It’s great for getting developers DevOps and all that to keep all these things in mind. Now Moshe, just to wrap up the conversation talking about CI/CD pipelines and security for developers. What would you say are one or two tips that you have for developers at startups to implement security practices that may seem difficult? But ways to implement those things without really taking too much of the developer’s time.

Of course, when we’re talking about you know, DevSec for startups, and we know that at startups a lot of developers don’t have as much time to focus on security, and really trying to bring security to the forefront here. Because it’s obviously super important with everything we’ve seen happening, especially lately. So, what are some tips that you have for developers say, here’s one or two things you can do right now that won’t take too much of your life cycles in terms of development, and you can implement them right away?

Moshe Ferber: Okay. So, most of the companies that do SCA (static code analysis) for instance. They have their own open-source tools that in the click of a button can help you in making the first decisions. After that you grow into more commercial products. But first start with the open-source tools, they’re usually easier to integrate, okay. The biggest problem in application security is that these tools are not usually, the application security tools are not embedded by the cloud provider. I mean, the cloud provider gives us a lot of infrastructure tools, but not application security tools. So again, go to OWASP, they have great tools, and almost all the large vendors also have some kind of open-source version that you can use, okay.

Pay extra attention to your Kubernetes images. Many of the breaches in the last couple of years happened because of the wrong Kubernetes images. So, pay attention to Kubernetes images and make sure to use open-source for your dynamic analysis. I think this will get you for the first couple of versions safely.

There’s always a conflict. Most regulations forbid the developers to do, well to the production. I mean that’s separation of job roles. But on the other hand,, your startups, sometimes you don’t have operations, and sometimes the developers need to go to production. Build your policies in a way that the developers can access the production. They can make changes. They cannot break the production, okay. Meaning, work on the permissions closely and make sure that most only have the right permissions.

This will be very helpful when you get an audit from your customers. Just to show them that when the development team accesses production, they’re doing it under their own guardrails as we talked about. Look for managed services, okay. This is true for many aspects that a startup does. You don’t have the time and you don’t have the manpower. So, take shortcuts by using managed services for monitoring, for testing. Use software as a service instead of building your own tools because it will save you time and operational burden.

Jeremy Hess: Perfect Moshe. Wow, thank you so much for those details. Now, before we wrap up, do you want to just give a little bit, something that you want to shout out, an event that you’re doing coming up. Anything like that?

Moshe Ferber: Well, our cyber week is coming in June. This is Israel’s largest conversation. And if you’re interested in cloud security, we always have an event there, talks about innovation and new stuff. You’re welcome to join us. Second, we are working on the next version of cloud security for startups with the CSA. Currently we are looking for contributors. If you’re able to contribute, if you have expertise in one of the areas of security management – of application security or platform security in the environment that startups are working on. Meaning the cloud environment, CI/CD, and in security management relevant to challenges of startups, then we are looking for both contributors who can write but also peer review. And look at our Facebook group where we publish all of this. It’s called Cloud Security Alliance Israel. Feel free to join it. It’s not limited to only Israelis; it’s open to everybody who wants to contribute, and come over and join us in this effort.

Jeremy Hess: Perfect. Thanks so much Moshe for your time, and hopefully we will be in touch again around cyber week. If not, then maybe around the version two of the CSA document. So, thanks again for your time. We learned an immense amount from you, and we look forward to the next time.

Moshe Ferber: Thanks a lot Jeremy. Thank you for having me.

Jeremy Hess: It’s a pleasure. Have a great day.