March 29, 2016
Ep. #5, Developers are People Too
In this episode David and Steve are joined by Justin Baker, Lead Product Designer at LaunchDarkly. The three discuss how developers are peop...
Cloud infrastructure is quite literally the backbone of most software startups (and, increasingly, enterprise businesses) today, which makes the security of that infrastructure all the more critical. While a recent study revealed that 66% of IT professionals say that security is a top concern for teams using cloud infrastructure, many teams still struggle to navigate the complexities of assessing infrastructure security. We chatted with Al Ghous, CSO and Head of Security for ServiceMax and collaborator on the Security 4 Startups Guide, about how startups can take a security-centric approach to ensure that their cloud infrastructure to mitigate risks and build a strong foundation for future security needs.
The easiest way of looking at it is the lower you go in the stack (like IaaS), the more security controls the customer has to apply. And the higher you go in the stack (like SaaS or PaaS) the fewer security controls you have to apply. This is because the IaaS service provider only secures the core infrastructure and manages tenancy. It requires the customer to secure everything else.
Inversely, the SaaS provider will secure everything from infrastructure on up to the application layer. But it still leaves things like identity and access management to the customer.
Not all cloud infrastructure providers are created equal, and it’s really incumbent on the customer to do their due diligence. Here are the steps I would recommend taking as you decide on a provider:
Check for certifications like ISO 27001 and attestations like SOC 2 T1 or T2. These show that they have the basics down. That doesn’t mean that they’re fully secure; we know of a lot of companies that were breached even though they are fully compliant. But it shows that they’ve gone through the extra effort of thinking about security.
Take a look at the Security or Trust content they have on their public website. This will give you a better sense of their security posture and transparency.
I always ask my peers about the cloud company I’m considering and perform some online research to determine if they have had any major incidents.
If you’re engaging in discussions to potentially adopt the cloud provider’s services, then it’s time to send them some form of Security Questionnaire with questions that are important to you. There are a lot of vendor security questionnaires like Shared Assessment’s SIG (Standardized Info Gathering) or Cloud Security Alliance CAIQ-Lite (Consensus Assessments Initiative Questionnaire). You don’t have to use them exactly as they are — you can customize them to fit your needs. Fortunately, it has become more common these days for service providers go as far as filling those out and posting them on their trust or security websites. If you look for those, they can save you from having to go through the process of sending them questions and waiting to get a response
I think teams still believe that majority of infrastructure security is handled by the IaaS provider. That’s not the case. IaaS providers will provide lots of services to help teams secure their cloud infrastructure, but they are only responsible for core infrastructure. For example, AWS will provide CIS-based AMIs. They also provide other native services to use like Security Groups, WAF, etc., but they will not protect your VPCs and apps for you.
Fully understanding that shared responsibility model that we touched on earlier is also very important, but often overlooked. Here are a couple resources that can help you learn more about it:
If there’s one thing you can do right out of the gate, it’s to implement appropriate access of controls, for example MFA (multi-factor authentication). There are different ways of doing this, but having another level of authentication apart from a simple password is critical these days. It’s unbelievable that people are still fearful of introducing another layer into the login process.
I would also perform the same amount of rigor in deploying infrastructure as you do deploying apps. The reason is that most of us deploy applications via automation and pipelines. The deployment and configuration automation code, whether something like CloudFormation, Terraform, Chef, etc. has to be done securely or you can leave a gaping hole. We have a requirement to run all our infrastructure deployments through a Secure Systems Development LifeCycle (S-SDLC), just like we do for software. This process reduces tech debt and ensures that controls are in place to eliminate configuration drift during runtime.
I don’t think there is a hard set number or percentage. The security budget depends on the startup’s business and what’s important to them from a risk perspective. They have to ask themselves, what am I protecting? Is it IP and/or customer PII, ePHI, etc.? If you’re a FinTech or HealthTech, you’re going to spend a bit more perhaps vs. if you’re a gaming service.
At the end, aside from what I call table stakes (such as access management, SGs, MFA, vulnerability scans, etc.), the customers will dictate where else security spend should go. Case in point: banks typically require TLS internally within the VPCs. So there has to be a way to implement this and manage all the certs required.
Jumping in and looking at the vendor community right out the gate can be confusing. There are a lot of competing products out there with a lot of buzzwords. Startups should focus on the foundation and leverage as much cloud native services as possible. This makes infrastructure easier to manage and more cost-effective until their needs grow. Combining open source with cloud-native services will provide a foundation to build upon, and if you want to go out to 3rd party vendors eventually then you can make that transition.
It may sound cliché, but there really is a reason why we have security in multiple layers. If one fails, you’ll have something to fall back on. Endpoint security, as it pertains to cloud and cloud workloads, is just as critical as network layer or application layer security. Whether it’s detective in nature or preventative in nature, it really does help to have protection on the endpoints.
The simplest way to start is to harden the underlying VM, or AMI if in AWS. Using the CIS-based AMIs for AWS is a good example. Enabling logging and collecting logs is another important factor. Then adding some type of endpoint detection or prevention software will round things out.
Note that startups don’t have to spend a lot of money here. In the case of Azure, one can leverage native services like Endpoint Protection and Security Center. For AWS, they can opt for open source tools.
As a founder or someone starting out fresh, you’re probably going to go with one of the big three cloud providers (AWS, Azure or GCP), and they all have good resources around infrastructure security. I would start there to learn more about their services and the problems they solve. Some of them, like AWS, also have some free training that you can take advantage of.
Security 4 Startups is a great product-agnostic resource. I worked with an esteemed group of colleagues and friends to build this framework for founders and startups to help them get their security programs off the ground. There is an excellent section on Infrastructure Security and it starts with the foundation. Our goal is to give startup founders a place to start with security and build a foundation, and as they grow from angel to seed and other higher rounds of investments, knowing how to build on that foundation.
Finally, it’s important to note that almost every cloud security vendor who plays in the infrastructure space has some sort of best practices. But I would recommend not going down those rabbit holes early on — they tend to be focused on how their product fits into the landscape.
Building on a major cloud provider’s platform doesn’t guarantee security. At DevGuild: Enterprise Security, CISOs from organizations like Atlassian, HashiCorp and Splunk discussed topics including Essential Cloud Infrastructure Security.