what is cybersecurity - Guide

Table of Contents

Cybersecurity is Just a Fancy Word for “Not Getting Fired for Someone Else’s Bad Code”

I once took down a regional payment gateway because I trusted a “secure” internal API. It was 2:14 AM on a Tuesday. I was trying to debug a latency spike in our order-processor service. I noticed that the service was spending 400ms waiting on a response from our internal user-profile service. To see what was happening, I decided to strace the process. In my sleep-deprived state, I didn’t realize that the user-profile service was logging the raw Authorization header in plain text whenever a 401 error occurred. I triggered a few hundred errors to “get more data.”

The logs were being ingested by a centralized ELK stack. Because the logs contained raw JWTs with admin claims, a developer on another team—who had read access to the logs—accidentally copied a “sample log” into a public Jira ticket to show a formatting bug. Within twenty minutes, an automated bot scraped that ticket, grabbed the admin JWT, and started hitting the /delete-customer endpoint on our production database. We lost 4,000 records before the database OOM-killed the connection due to the sheer volume of delete queries. That’s what cybersecurity actually looks like. It’s not a hooded hacker in a dark room; it’s a chain of small, stupid decisions that lead to a catastrophic failure.

What is Cybersecurity? (Hint: It’s Not a Dashboard)

If you search for “what is cybersecurity,” you’ll find a lot of garbage about “protecting the integrity of data” or “securing the digital perimeter.” That’s marketing speak. In the real world, cybersecurity is the practice of managing technical debt and human fallibility. It is the realization that every line of code you didn’t write is a liability, and every line you did write is a bug waiting to be exploited.

The industry wants to sell you a “Single Pane of Glass” to solve your problems. They want you to buy a WAF (Web Application Firewall) and call it a day. But a WAF won’t save you when your developer hardcodes a root password into a docker-compose.yaml file and pushes it to a public repo. Cybersecurity is the boring, repetitive work of ensuring that the principle of least privilege is actually enforced, not just talked about in slide decks.

Pro-tip: If a vendor tells you their tool “uses AI to stop 100% of threats,” hang up. They are selling you a statistical model that will eventually hallucinate and block your legitimate traffic at 3 PM on a Friday.

The Identity Crisis: Why IAM is Your Only Real Perimeter

The old model of security was the “Castle and Moat.” You had a firewall. Everything inside the firewall was “trusted.” Everything outside was “untrusted.” That model died a decade ago, but some people are still trying to perform CPR on it. In a world of microservices, Kubernetes clusters, and remote work, the network is irrelevant. Identity is the only thing that matters.

When we talk about “what is” security in a modern context, we are talking about Identity and Access Management (IAM). If you get IAM wrong, nothing else matters. I’ve seen companies spend $500k on network firewalls while their S3 buckets were open to AuthenticatedUsers (which, in AWS-speak, means *anyone* with an AWS account, not just *your* account).


# A dangerous IAM Policy that looks "fine" to the untrained eye
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::prod-customer-data",
                "arn:aws:s3:::prod-customer-data/*"
            ],
            "Condition": {
                "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
            }
        }
    ]
}

The policy above looks secure because of the IP restriction. But what happens when your CI/CD runner—which lives outside that IP range—needs to deploy a change? You “temporarily” add another IP. Then another. Then someone forgets to remove them. Suddenly, your “secure” bucket is accessible from a coffee shop in Berlin because your VPN exit node changed. Identity should be based on short-lived tokens and OIDC (OpenID Connect), not static IPs or long-lived access keys.

Stop using IAM Users. Use IAM Roles with OIDC providers like GitHub Actions or GitLab.
Rotate your keys every 90 days? No. Use keys that expire in 1 hour.

The Supply Chain is a Garbage Fire

Most of your application isn’t yours. When you run npm install or pip install -r requirements.txt, you are inviting thousands of strangers to run code on your production servers. Cybersecurity is the process of vetting those strangers.

Remember the event-stream incident? A popular package was handed over to a new maintainer who then injected malicious code to steal Bitcoin wallets. This wasn’t a “hack” in the traditional sense. It was a social engineering attack on the open-source ecosystem. If you aren’t using lockfiles (package-lock.json, poetry.lock, Go.sum) and auditing them with tools like npm audit or snyk, you aren’t doing cybersecurity; you’re just hoping for the best.

I prefer Debian-slim over Alpine for base images. People love Alpine because it’s small (5MB). But Alpine uses musl instead of glibc. I’ve spent more hours debugging weird DNS resolution issues and C-extension crashes in Alpine than I care to admit. Security isn’t just about the size of the attack surface; it’s about the maintainability of the system. If your “secure” image is so brittle that nobody wants to patch it, it’s not secure.

The False Security of “Encryption at Rest”

Compliance auditors love the phrase “encryption at rest.” It makes them feel warm and fuzzy. But let’s be real: if an attacker has gained enough access to your server to read the raw data off the disk, they likely already have access to the encryption keys stored in memory or in your KMS (Key Management Service).

Encryption at rest protects you from exactly one thing: someone physically stealing a hard drive out of a data center. How many times has that happened to you lately? Exactly. The real threat is “encryption in transit” and “application-level encryption.”

If you’re using PostgreSQL 15, don’t just rely on the cloud provider’s disk encryption. If you have sensitive data (like PII or API keys), encrypt that specific column using pgcrypto. That way, even if someone gets a database dump via an SQL injection, the data is still useless without the application-level secret.


-- Example of application-level encryption in Postgres
INSERT INTO users (username, secret_token) 
VALUES ('admin', pgp_sym_encrypt('super-secret-password', 'your-encryption-key'));

-- To read it back
SELECT pgp_sym_decrypt(secret_token, 'your-encryption-key') FROM users WHERE username = 'admin';

Yes, this adds latency. Yes, it makes searching by that column impossible without a blind index. That is the trade-off. Cybersecurity is the art of choosing which trade-offs you can live with.

The Network is Not Your Friend

We need to talk about mTLS (Mutual TLS). In the old days, we trusted the network. If a request came from 10.0.5.42, we assumed it was the billing-service. But in a Kubernetes world, IPs are ephemeral. A pod dies, a new one starts, and it gets the old IP. If your legacy-service doesn’t check who is talking to it, it might accept a “delete all” command from a compromised frontend-pod that just happened to inherit a trusted IP.

This is why tools like Linkerd or Istio exist. They handle the heavy lifting of rotating certificates and ensuring that every single service-to-service communication is encrypted and authenticated. It adds a 2-3ms overhead to your P99 latency. Is it worth it? If you’re handling credit card data, yes. If you’re running a cat meme generator, maybe not. Stop following “best practices” blindly and look at your actual risk profile.

Monitoring vs. Observability: Seeing the Breach

You will be breached. It’s a statistical certainty. The question is: will you know? Most companies find out they’ve been hacked when the FBI calls them or when their data shows up on a leak site. That’s a failure of observability.

Cybersecurity isn’t just about blocking attacks; it’s about detecting anomalies. If your api-gateway usually handles 500 requests per second and suddenly jumps to 5,000, that’s an alert. But if it stays at 500 requests per second but the *outbound* data volume triples, that’s a data exfiltration event. You won’t see that on a standard CPU/Memory dashboard. You need VPC Flow Logs, and you need to actually query them.

Note to self: Check the CloudWatch logs for 403 Forbidden spikes. It’s usually a misconfigured service, but sometimes it’s a crawler looking for .env files.

The “Gotcha”: SSRF and the Metadata Service

Here is a “War Story” favorite: Server-Side Request Forgery (SSRF). This is the “pro” move that bypasses almost every firewall. Imagine you have a feature where a user can provide a URL, and your server fetches the OpenGraph image for them.

A clever attacker won’t give you https://google.com/logo.png. They will give you http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role.

That IP address is the AWS Instance Metadata Service. If your server fetches that URL, it will return the temporary AWS credentials for the role attached to that server. The attacker now has your IAM keys. They didn’t “break in”; you handed them the keys through a legitimate feature.

To fix this, you need to:

Use IMDSv2, which requires a session header (this stops most basic SSRF).
Run your fetching logic in an isolated sandbox with no access to the internal network.
Use an allow-list for domains, not a deny-list.
Validate that the IP resolved from the domain isn’t a private IP (10.x.x.x, 172.16.x.x, 192.168.x.x).
Set a strict timeout on the request so it can’t be used for port scanning.
Use a non-privileged user to run the service.

The “Shift Left” Lie

The industry loves the phrase “Shift Left.” It means “make developers responsible for security.” In theory, it’s great. In practice, it’s a way for management to avoid hiring actual security engineers. You can’t just give a developer a 400-page PDF of vulnerabilities found by a static analysis tool (SAST) and expect them to fix it. Most of those “vulnerabilities” are false positives.

If you want to “Shift Left,” you have to make the secure path the easiest path. Don’t tell developers to “be careful with secrets.” Give them a library that automatically fetches secrets from HashiCorp Vault and rotates them. Don’t tell them to “secure their Dockerfiles.” Give them a base image that is already hardened and scanned. Cybersecurity is a platform engineering problem, not a training problem.

The Human Element (The Part We All Hate)

I can spend six months hardening a Kubernetes cluster, implementing mTLS, and setting up eBPF-based runtime security. It won’t matter if the CEO clicks on a link in an email that says “Urgent: Your Payroll is Delayed” and enters their Okta credentials into a phishing site.

Phishing is still the #1 entry point for breaches. Why? Because humans are wired to be helpful and reactive. We can’t “patch” humans. The only solution is to remove the human from the equation as much as possible. This means:

FIDO2/WebAuthn hardware keys (Yubikeys). SMS and TOTP (Google Authenticator) are phishable. Hardware keys are not.
Zero Trust Access (ZTA). Just because you’re on the VPN doesn’t mean you get access to the production DB. You should still have to authenticate to the DB individually.

The Cost of Security

Security is a tax on velocity. Every security measure you implement will slow down development.

Code reviews take longer.
CI/CD pipelines take longer because of scanners.
Architecture becomes more complex because of isolation.

The goal isn’t to have “perfect” security. The goal is to have “enough” security to make the cost of attacking you higher than the value of what you’re protecting. If it costs an attacker $10,000 in compute and time to steal $5,000 worth of data, they will go somewhere else. That’s the economic reality of cybersecurity.

YAML-Hell and Configuration Drift

In the SRE world, we live in YAML. Kubernetes manifests, Terraform files, GitHub Actions workflows. These files *are* your infrastructure. If your Terraform state is stored in an unencrypted S3 bucket, your entire infrastructure is compromised. If your Kubernetes RoleBinding gives cluster-admin to the default service account, your cluster is a ticking time bomb.


# A snippet of YAML-hell that will get you pwned
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: permissive-binding
subjects:
- kind: ServiceAccount
  name: default
  namespace: prod-apps
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

I’ve seen this exact block in production environments because “it was the only way to make the app work.” This is where cybersecurity meets SRE. We have to find out *why* the app needed those permissions and narrow them down to the specific API groups and resources it actually needs. It’s tedious. It’s unglamorous. It’s cybersecurity.

The Real World: Log4Shell and the Ghost of Java Past

Let’s talk about CVE-2021-44228, better known as Log4Shell. It was the perfect storm. A ubiquitous library (Log4j), a “feature” that nobody used (JNDI lookups), and a simple exploit string. You could literally take over a server by sending a specific string in a User-Agent header.

The reason Log4Shell was so devastating wasn’t just the vulnerability itself. It was that most companies didn’t even know where they were running Java. They had forgotten about that “legacy reporting tool” running in a VM in the corner of the data center. Cybersecurity is 80% asset inventory. You can’t protect what you don’t know exists. If you don’t have a live, automated inventory of every service, container, and server in your environment, you are already compromised; you just don’t know it yet.

Final Advice for the Weary SRE

Cybersecurity is not a project with a start and end date. It is a state of constant, controlled paranoia. Stop looking for the “perfect” security tool and start looking for the “least bad” way to implement your features. If you can’t explain how a request is authenticated, authorized, and logged from the moment it hits your load balancer to the moment it touches the disk, you don’t have a secure system; you have a lucky one. And in this industry, luck eventually runs out.

Build your systems to fail gracefully. Assume the attacker is already in your network. Assume your developers will commit secrets. Assume your dependencies are malicious. If you build with those assumptions, you might actually survive the next 2 AM page.

Now go rotate your SSH keys. I know you haven’t done it in a year.

Explore more insights and best practices:

what is cybersecurity – Guide