Security Controls in public cloud

It seems like there is news of another security breach every day. While a lot of us won’t be hit by every security incident, statistics suggests that given enough time we’ll all see some effect of security incidents. Perhaps we will personally get affected, or the company we work for gets compromised. What’s fueling this increase in wave of incidents? 

• Migration of applications and services to public cloud is certainly a factor. Companies are moving away from the closet servers and private/shared data centers to public clouds like AWS, Azure, Google Cloud and others. While the public clouds aren’t less secure by themselves, the applications and processes for security, monitoring, updates, etc. need to be revisited and reviewed from the ground up.
• Increase in sub-services and sub-components that are vulnerable. With the availability and convenience of open source software and managed service components there are higher chances that vulnerabilities exist in one or more of those services that is exploited.

What can you do to protect yourself, and more importantly, your customers data?

As a startup, not surprisingly, you’re strapped for resources. Your team is rigorously racing to get features developed and validated by customers. Last thing on your mind is process and security. Unfortunately, this is the mentality of majority of startups. After all, if you had to make a choice between putting your resources on developing features that could provide a lifeline to your startup, vs security tools and processes where it will not matter if your company folds, you’ll probably see why startup CEO’s make such decisions. However the CEO’s and VC’s realize that market and customers are a lot less forgiving when it comes to breaches by a startup, and that is a good motivator.

If you’re a startup, here are 3 things you can do now to have some visibility and protection against security breaches. These suggestions will give you guidance to build a robust security framework:

1) Allocate resources dedicated to security

Security work is hard and it takes continuous time to make it effective. Many CEO’s don’t internalize this, and they treat it as something they get someone to do once and they’re done. That’s a recipe for disaster waiting to happen. Reality is that setting up security controls, and operating those controls is an ongoing task and you want someone who is solely focused on those activities. To be clear, I’m not suggesting that security work will only be done by these resources. In fact, thinking about security is something that should be second nature. Just like a developer needs to think about and design how their components will be tested, they should also be thinking about how will their component be compromised and what is the blast radius if it happens. Formally dedicating someone to be in charge of security activities puts focus and accountability that a fuzzy, distributed model lacks. This person(s) will be facilitating and ensuring that security framework is defined, activities are executed and processes are followed.

2) Build security into your architecture from day one. If you’re past that point, go back and rearchitect

Unless your product is delivering a security feature, chances are your architecture is addressing how to deliver the features you are selling, and how it’s going to scale as your customers grow, and what technology and stack is delivering that solution. A critical component of that architecture has to be security. Review your architecture in light of what will happen if there is a security breach, including but not limited to vulnerability through external exploits as well as disgruntled employees. Ask the obvious security questions:

• How would I know if there is a breach? 
• This question highlights what to monitor. If there is a breach, what are you monitoring to indicate suspicious activity? Ultimately someone will discover the breach. The more prepared you are on security framework and processes, the quicker you will know before your customers would notify you.
• What do I do when there is a breach?
• When there is a breach, and your monitoring processes pick up a suspicious activity, how will people get notified, and what will the do? What quarantine mechanisms do you have in place? Have you exercised them frequently enough with different people so that the person receiving the alert knows what to do to contain the damage. What are the communication channels for people inside the company to notify and escalate all the way to CEO. Also, what are the communication channels to notify customers?
• What should I treat as confidential data?
• This is a critical question whose answer forces everyone to be on the same page as to what is the tolerance of data breach and what is “confidential data”. Once your team agrees on what the data they should protect is, then it can guide the activities and tools that will be necessary to provide the protection. Reality is that not all data is sensitive and needs to be protected (e.g. Log files that may have status or debug entries while running the application may not be as sensitive as financial data for a client).

3) Establish security processes by documenting what they are, implementing, monitoring and reviewing them on a predefined and set schedule (at least once a month)

One of the most effective forcing functions for a company to start this exercise is to go through some certification process like SOC 2. These types of certifications forces you to think about processes and documenting them and share it with the rest of company. Unfortunately there are no guidelines for where to begin. There are, however many auditors and consultants who specialize in these that you can leverage, but they can get costly. I recommend to start small and define and document simple processes and build on that. Here are some areas to start, not in any order of importance:

• Employment processes - Document what your recruitment process is, how do you ensure you hire and train your employees who may have access to sensitive data (e.g. background checks)
• Access Control - How do you control who gets access to sensitive data/systems and who monitors that. How do you know if your employee accessed a file that they shouldn’t have? How do you ensure your departed employees don’t have access to systems or data.
• Data protection - What is sensitive data, how do you protect the data and access to that data. What is the life cycle of data passing through your system?
• Encryption - What does your encryption process look like? How do you encrypt the data, where are the keys and how do you ensure the right people have access to the keys? Where does encryption come into play in your data life cycle?
• Application and Server/VM protection - How do you ensure your servers and your OS/open source software components are not exposing your systems to vulnerabilities? What are all the possible ways for a malicious person or software to get access to your running servers? How would you know if you’re continually checking for exposure? And what do you do when you discover such vulnerabilities?
• Change management - You never have a static system, which means you’ll continually have updates to applications and 3rd party components. How do you control what goes to your production and how do you ensure you don’t introduce new vulnerabilities every time you release a new version?
• Incident management - Vulnerabilities will eventually get exploited. It’s a question of when, not if. When this happens, how do you handle the incident. How would you know when the incident happens, who gets notified and engaged, who will facilitate and coordinate the efforts across the company to quickly isolate, remove the vulnerability and do forensics on what happened? How do you notify customers when there is a security breach?

Once you have the initial set of processes defined and implemented, you then need to operationalize it by frequently reviewing them because:

• New security vulnerabilities are discovered every day that could affect components or systems that you use
• Your architecture is likely to change frequently with new component and services being introduced and existing components may alter
• New employees start and some employees may leave. You want your new employees to be intimately aware of, and participate in this process. 

Your security team should implement a workflow similar to below. 

• Define - Whether it’s the first time or as part of the regular review cycle, you’ll have some new processes or modifications to existing ones. This step will help you talk about these with the team and management to get feedback and assess feasibility and cost of addressing a security concern. You can determine whether the security concern can be addressed by implementing a solution yourself, or whether a service or a tool exists that you maybe able to leverage. 
• Document - Follow a standard template to document new procedures or enhancements to existing ones. You’ll need to submit documentation for security certification anyway, so do it when it’s fresh in your minds.
• Implement - Implement what you document. Test it to ensure it serves the purpose of the control. Ensure you can measure and capture the metrics the control is intended to address. This will tell you if it’s working or not.
• Monitor - Have a way to see the metrics that all controls are making available and pay attention to anomalies (e.g. missing data) as they could indicate an exploit or lapse in visibility.
• Review - Determine what was working since last time you had this review and what needs improvements. Determine what new components are added and how that changes the security landscape of your system. Outcome of the review will be a set of new or improvements that will feed back to the definition step.

It takes real investment to implement and continuously improve your company's security activities, but it is vital and an area well worth the investment.  You'll find that it'll pay many dividends such as visibility for where vulnerabilities can be expected, and your customers and investors will appreciate your attention to this important area. 

--- Ramin Naimi