DEV Community

fjavierm
fjavierm

Posted on Originally published at binarycoders.wordpress.com on

Cloud Security: Principles and Concepts

Time passes, and almost every single minute of the day there is a cybersecurity event. If you follow any news sources in the Infosec space, you’ll see multiple events happening. To see how visible and prominent simple events are, we can try to provision a server with a public IP, and the moment it’s provisioned, we’ll see automated bots and port scanners probing it, often within minutes or even seconds. Obviously, not all traffic will come from malicious attackers, some of it will be just continuous IP harvesting from security researchers, search engines like Shodan or Censys, but some of it will be malicious botnets constantly monitoring especially cloud providers IP ranges. And that is just the beginning. This example is not to scare anyone, it’s just to raise your awareness.

Despite the prominence, and the obvious potential damaging consequences an attack can have, there are still plenty of organisations where security teams have tight budgets, and security is treated as a second-level citizen that wastes money without return of investment (ROI).

To deal with that situation, given those restricted budgets, defenders and cybersecurity professionals need to focus on the most important and efficient parts to optimise the implementation of defence controls. As such, we are going to review a few principles and concepts that will help us to decide where to focus our resources.

Before we start creating our security program, and buying any tools or hiring another analyst, the first questions we should ask ourselves should always be “what are we protecting” and “what happens if we lose it”. While it sounds trivial and obvious, there is a surprising number of organisations running security programs without any idea of what the answers to those two questions are.

This is where asset inventory and data classification comes in play. And yes, I know that it’s not glamorous, but it is essential work. We cannot defend what you don’t know we have, and we cannot prioritise defences for assets we haven’t ranked by importance. For example, a defaced marketing page, and a breached customer database do not have the same importance, especially from a business continuity point of view. Without classification, they can end up competing for the same level of attention and resources.

Another thing that consumes resources unnecessarily is trying to pursue the latest threats. for example, the latest zero-day, a new ransomware, the latest nation-state APT technique, etc… All of them are curious, we should be aware of them, and, I’m not going to lie, they are fun, but probably they are not worth it part of our resources. We should be focus on risks and not just threats.

The Risk is a function of likelihood and impact, not just how alarming something sounds. A well-run risk register, even a simple one, forces the conversation from “this could happen” to “how likely is this to happen to us, and how bad would it actually be”. That shift alone reorients a lot of spending decisions away from fear and toward evidence.

Another thing that I see often in organisation is try to create and add more and more controls when they should, first, try to reduce their Attack Surface. The addition of controls is an attempt of fixing every gap and every crack we perceived with a new addition (e.g., a product, a methodology, a practice). But often the most cost-effective move is to remove something, not add something. For example, decommissioning unused servers, closing unnecessary ports, removing stale accounts, retiring shadow IT, and turning off default services nobody remembers enabling. Every unnecessary system, open port, or forgotten admin account is one more thing a defender has to monitor and one more thing an attacker can try. Shrinking that surface is often cheaper than defending it, and it directly reduces the noise our teams have to process.

One principle that it seems to be, finally after many years, in the spotlight is the Principle of Least Privilege. An unimaginable number of breaches turn into major incidents not because of the initial foothold, but because of what the attacker could reach afterward. Accounts with more access than needed, or flat networks are examples of misconfigurations that can turn a small compromise into a large one.

Least privilege isn’t a one-time project, it’s a discipline. Regularly reviewing who has access to what, removing permissions that accumulate over time (have you heard of “permission creep”), and segmenting networks so a breach in one area doesn’t cascade into another, all pay for themselves the first time they contain an incident that would otherwise have spread.

Another one that has been with us forever, and it feels that is never going away is patching and configuration management. Most successful intrusions don’t rely on rare or exotic zero-days. They rely on known vulnerabilities that were never patched, or misconfigurations that were never caught. A disciplined, prioritised patch management process, one that ranks patches by exploitability and exposure rather than trying to patch everything everywhere immediately, consistently delivers more risk reduction per dollar (euro or pound) than flashier initiatives. And yes, it’s boring, but from a return of investment point of view is difficult to match.

The same goes for configuration hardening, examples such as unchanged default credentials, overly permissive cloud storage buckets, loose rules on firewalls and VPCs, and unnecessary services running on servers are the kind of low-effort, high-impact fixes that we’ll never write an interesting article about, but can make a big difference in an incident report.

The next one is a tad contra intuitive. Organisation should invest in Detection and Response. A very naive approach is to think that we are fully protected, and that nothing can happen to us, but the sad truth is that no set of preventive controls is perfect, and treating prevention as the only goal leads to unpleasant surprises. Mature security programs plan for the moment prevention fails. This is why detection and response capabilities, logging, monitoring, alerting, and a tested incident response plan, deserve a seat at the budget table alongside preventive tools. An attacker who gets in but is detected and contained within hours causes a fundamentally different kind of damage than one who has weeks of undetected access.

The next one is the one that we can control the least, the human element. Have you heard that one that says that “the biggest cybersecurity risk is located between the chair and the monitor”? That is an immutable truth, unfortunately, for our systems to exists, they need to have users, and those users are prone to errors, intentional or not. In this way, technical controls matter, but a large share of incidents still start with a person (e.g., a phishing email, a reused password). Companies need to invest in Security Awareness training. And ideally, not consider it just a checkbox exercise to comply with this or that policy, but make it relevant, useful, and, if possible, engaging. When it’s practical, recurring, and tied to real examples rather than generic slideshows, it measurably reduces the number of incidents that reach our technical defences in the first place.

In parallel to the implementation of a training program, it is equally important to make easy and low-friction for employees to report suspicious activity without fear of blame. A culture where people flag a suspicious email quickly is worth more than a bunch of security tools.

One thing that we should be careful about, and never lose sight of it, it’s that our cybersecurity programs is not the reason why our organisation exist. The organisation is there to serve a purpose, to sustain a business, we are just there to protect business continuity and the organisation. As such we should always implement guardrails and use frameworks as a compass and not as a cage. A radical examples if we do not follow this principle will be to turn our computers and services off, we will have one of the most secure organisations, but it will be impossible to run the business.

Frameworks like the Critical Security Controls (CIS), NIST Cybersecurity Framework, or ISO 27001 exist because this prioritisation problem is universal. They won’t tell you exactly what your organisation needs, but they offer a tested starting point, and a way to benchmark maturity over time, so we’re not reinventing prioritisation logic from scratch or relying purely on gut feeling. If used well, a framework becomes a shared vocabulary between security teams and leadership, making it easier to justify budget requests in terms leadership already understands: maturity levels, coverage gaps, and risk reduction, rather than technical jargon.

And let’s never forget that this is not a one control fits all situation. Not every system needs the same level of protection. A public-facing payment system processing millions of pounds should not necessarily have the same controls as an internal application used by five people. This sounds obvious, but security programs sometimes end up applying controls uniformly because uniformity is easier to measure. The problem is that this can result in spending too much protecting things that don’t matter very much, while the truly critical assets receive no additional attention.

And finally, none of these principles work in isolation, and none of them can offer perfect security, because that doesn’t exist. What they offer instead is a way to make deliberate, defensible choices about where limited time and budget should go.

Security will never be “finished”, and budgets and resources will rarely feel like enough. There will always be another vulnerability, another threat, another product and another control that someone will tell us we absolutely need. The challenge is not to eliminate all of them. The challenge is to understand what matters to our organisation, understand the risks we face, and spend our limited resources where they can make the biggest difference.

Because ultimately, a good security program isn’t the one with the most controls. It’s the one that gives the organisation the best protection for the resources it can realistically afford.

Top comments (0)