Security isn’t just one thing, it’s lots of little things. It’s software, and standards and processes within your business. That’s why it’s so hard to just go out to the market and get a company to fix your security. Cloud security can look vastly different from business to business. But adding security in layers, one on top of the last, can really enhance the overall security of your platform. Let’s check out layered security in the cloud.
Layered Security In The Real World
This blog post came about while working with one of my very favourite clients. Even though we’re talking about how secure their platform genuinely is, I won’t name them. Revealing what technology they use actually removes one of their layers. As we talk more about what a layer of security looks like, this will become more clear.
As I was saying, I was working on security for a client. We decided to implement an alarm which would pop a message into slack if any server logged more than 3 disconnects in a 5 minute period. When you try to authenticate an SSH session to a Linux server, if you get a username, password or keyfile wrong, you will be disconnected, and that event it logged. The team is fairly small, and they have a deployment pipeline, so there aren’t too many reasons to log into a server. That means the alarm won’t be triggered by a flurry of activity by developers for example.
How Does The Alarm Work
This particular client use the CloudWatch Logs agent on all servers. That means when events are written to logfiles on the server, they’re scooped up, and pushed into the CloudWatch Logs dashboard so everyone can view them. For more information about CloudWatch Logs, check out our recent post all about logs in the cloud.
We then defined a filter on the log stream, and a custom CloudWatch metric. The last step is to define a CloudWatch Alarm when the metric threshold is breached. The action of the CloudWatch Alarm is an SNS topic, to which a Lambda function is subscribed. That Lambda function pushes a message into a Slack channel via a Slack API call. Flash!
Last Line Of Defence
All this sounds very logical I think. We have strung together some AWS services which we don’t have to manage, to alert us to bad things happening in our cloud. All this costs next to nothing, and it gives great peace of mind. But couldn’t we remove the threat of brute force SSH logins all together using a VPN?
If you thought that, you get 10 Beaty Points! Beaty points can be exchanged for buying me a pint next time you see me. What do you mean you don’t want the points? Ungrateful…
Anyway, yes, stopping bad actors from getting to your servers in the first place is a much better way to secure your network than alerting you when it does inevitably happen. But what if you did both? Then you would be layering the alerting on top of good perimeter security.
Privilege Escalation
This idea of making provision for one thing going wrong is prevalent throughout technology. Lots of patches for our computers and software address a problem known as privilege escalation. Privilege escalation is where an attacker gets a little bit of access to a system, and is then able to switch, or escalate, to an administrator of that system. Administrators can do whatever they want, so that’s where the attacker wants to be.
Privilege escalation bugs are not useful to attackers on their own. They have to find a way into the system first before they can escalate their privileges. But software companies take these bugs very seriously for the same reason we built the SSH brute-force alarm described above. Having the perimeter breached is bad, but having it breached and then admin access attained is worse.
Your Cloud Layers
Spend 5 minutes just now thinking about the cloud services you use, and how you could layer security practices to help secure them. Maybe turn on two-factor authentication in case your password is lost? Start using a password manager in case one of your passwords is leaked? There’s always more we can do to enhance our own, and our business’ security.
