Ok, so you're a CISO, a security architect/engineer, or a security enthusiast and you think you understand cloud infrastructure security. Sure it's not brand new anymore, maybe you've learned from other's bad experiences (hopefully not your own) and seen numerous vendor demonstrations at your yearly conferences for CPEs. But let me assure you the majority of security professionals today don't get it. They're not seeing the big picture. If you're reading this post and agree with everything I'm saying below this I applaud you. You are further along than most in this arena.
Here's a list of some of the laggers that don't get:
http://www.zdnet.com/pictures/biggest-hacks-leaks-and-data-breaches-2017/
Below are four key concepts for cloud infrastructure security. Please read if you want to secure our bank accounts of SSN from the dark web.
I'm focusing on the infrastructure because that's where the crown jewels of any corporations are.
A. Shared Responsibility Model
AWS put out a shared responsibility model to show what their customers are supposed to secure in their cloud infrastructure. This same model can be applied to other public cloud providers like Azure, Google, Rackspace, etc.
https://aws.amazon.com/compliance/shared-responsibility-model/
Not following the shared responsibility is one of the big things that people miss. If you don't know the shared responsibility model or aren't aware of it, you are probably exposing your organization in a number of ways off the bat.
In this model, AWS secures everything below the hypervisor
If you are utilizing a public cloud provider, you are operating in an IaaS model and you'll be in charge of securing everything above the hypervisor. That means all the applications and data that your hosting in the cloud is UNPROTECTED and CONNECTED TO THE INTERNET. Let me give you a real life example.
If you're using AWS and you spin up an S3 bucket, the S3 bucket is open by default. Unless you put the proper security controls on that S3 bucket, you're screwed. Now let's look at a Fortune 100 company with a team of 20 cloud engineers spinning up s3 buckets for months on end. All of those S3 buckets are unprotected unless the proper security controls are put in place every time. I'll discuss the solution to the scenario in a later rule.
Take away: It's the customer's responsibility to secure their applications and data. You public cloud provider will not do this for you.
B. The perimeter is gone
(
)
Another important concept to understand about cloud infrastructure security it that the perimeter is gone. It used to be fine to put a firewall around your datacenter and a couple of scanners and call it a day. This was because a data center is not expanding. This environment has a LOW RATE OF CHANGE and stays relatively the same. A static environment. The cloud, by comparison is always changing. The cloud has a high rate of change so the methodology of guarding the perimeter doesn't make sense. Let this soak in.
Since you can't seal the perimeter airtight, you need to look at security in a different view. This is where rule number 3 and 4 come to play
C. Layered Security
A coined term: https://en.wikipedia.org/wiki/Layered_security looks like it's important.
Since cloud infrastructure has cloudbursts and a high rate of change, it is imperative that you have many lines of defense. Since the attack surface is larger than that of a data center of equivalent servers/vms/instances.
The cloud security landscape is new so there is no vendor that can do everything for you, no matter what they tell you.
You'll need solutions whether you're buying them or make them yourself for application security, IOT, Network, and infrastructure security. When you think of your infrastructure you need to break that down into 2 parts.
Host-based and configurations.
i) Host-based
You need to have a layered approach when it comes to an IDS or IPS. File Integrity monitoring, Log-Based Intrusion Detection, Software Vulnerability Assessment etc. This will deter or slow down malicious actors from penetrating your infrastructure.
ii) Configurations
Then you need to have preventative controls in place to act as a safeguard for when they defeat your IDS/IPS. This can only be achieved if you have visibility into the state of your configurations within your infrastructure.
Being able to quickly see which ports are connected to the internet, what storage blobs or S3 buckets fall out of your security policy, these are things that need to be attainable. Most organizations are no where near that. This is where we need to be. If you don't have visibility into the state of your configurations, you have no idea who is controlling your infrastructure and what it looks like. There could be a couple of bitcoin miners hard at work, or someone siphoning off precious PII. You'll never know. Being able to configure your environment in a preventative effort to AWS/Azure/Google best practices are a must.
D. Automation
Wow that seems like a lot of work. You're right, it is. That's why automation is a must. Remember my earlier example with the fortune 100 cloud team spinning up S3 buckets willy nilly? You can't count on your entire security team or engineering team to follow all of your security policies perfectly, or make sure they are being enforced at all times. We are human, which means we are not perfect. This means you are putting your org at risk if you don't have an automated solution in place. Evident.io is an example of a vendor that gives you visibility into your configurations in real time by running automated checks of industry best practices and customized checks to fit your unique policies.
You don't need to automate remediation since you can learn a lot by how a threat has defeated you. It is recommended to automate a "low lever" alert, but nothing to complex.
These 4 high-level concepts will help you learn how to assessing risk in your organization and how to build a sound security strategy in the cloud.
Are you aware of any specific things that are helpful when it comes to logging cloud infrastructures?
Logging is huge, as I am sure you know, for monitoring and investigating. Do you know of any activities that are normally overlooked when logging cloud infrastructures?
Hey Biasnarrative,
Great questions. I'm not sure if I understand exactly what you mean but i'll give it a go. LIDS- having a Log based Intrusion Detection system set up for your IDS/IPS strategy can help filter specific logs to your SIEM for more efficient monitoring. This will also cut down the number of logs files sent to your SIEM (Splunk, sumo, etc) which would lower your bill.
As for activities that can be overlooked when logging cloud infrastructure, warning signs of compromise can be overlooked, user attribution. If your coworker Marissa spun up an EC2 instance without your orgs proper security policy applied, your log files might only tell you what they see on the surface. The fact that someone named "Marissa" or someone with the email "[email protected]" would be what's over looked. Log Files lack that ability to attribute which user did what. Having the ability of user attribution allows you to ask "Marissa" about this issues your self. If Marissa denies working with an EC2 instance that day, it could be a sign of her account being compromised.
I just work in a SOC and I am always looking for information on logs cause that a main part of our automated rule firing.
Never know when the business might go crazy with cloud! Haha
Congratulations @ksumma! You received a personal award!
Click here to view your Board of Honor
Do not miss the last post from @steemitboard:
Congratulations @ksumma! You received a personal award!
You can view your badges on your Steem Board and compare to others on the Steem Ranking
Vote for @Steemitboard as a witness to get one more award and increased upvotes!