Security Essentials

These notes cover the foundational security concepts every DevOps engineer must understand. Security isn't just an afterthought — it's a core component of the entire software delivery pipeline. This chapter lays the groundwork for understanding the threats, attack vectors, and defensive strategies that define the DevSecOps landscape.

Importance of Security

Security is defence against malicious actors — anyone attempting to gain unauthorized access to systems, data or applications
What needs to be secured:
- Customer data — the most valuable and legally sensitive asset
- Company data — intellectual property, trade secrets, financials
- Internal applications — tools used within the organization
- User-facing applications — everything exposed to the public
Hacking into one internal system should not give access to all systems — this is the principle of segmentation and defense in depth
All application components need to be secured — from the frontend to the backend, database, infrastructure, and even CI/CD pipelines

Types of Security Attacks

Different hacking methods and tactics exist to target different systems. Understanding them is the first step to defending against them.

Phishing Attack

Targets humans rather than systems directly — the weakest link in security
How it works:
1. Personalised phishing emails that appear legitimate
2. Redirects to malicious pages designed to steal credentials
3. Links to malicious websites that may download malware
4. Tricking users into downloading malicious scripts
Phishing is the most common initial attack vector in data breaches

XSS — Cross-Site Scripting

Allows execution of scripts from malicious sources in a victim's browser
How it works:
- An attacker exploits input fields on a website (like comment sections, search bars) to inject malicious code
- When other users visit the affected page, the injected script is served to their browsers and executed automatically
- The application allows fetching and executing scripts from arbitrary sources
XSS is one of the most common web application vulnerabilities

CSRF — Client-Side Request Forgery

A common impact of XSS is stealing user identity
The attacker forges requests — essentially pretending to be another user
The attack happens on the client side — the victim's browser unknowingly sends requests on behalf of the attacker
Example: If you're logged into your bank account and visit a malicious page, that page could trigger a transfer request using your authenticated session

SSRF — Server-Side Request Forgery

The attacker manipulates the server (not the client) to send requests to protected/internal resources
The server is tricked into making requests it shouldn't — e.g., fetching data from internal APIs, cloud metadata endpoints, or databases
SSRF is the server-side counterpart to CSRF

SQL Injection

Targets the database layer by injecting malicious SQL queries
Exploitations include:
- Fetching sensitive user data
- Manipulating database records
- Deleting data entirely
SQL injection typically occurs when a web application doesn't properly validate or sanitize user inputs before incorporating them into SQL queries
User inputs include data entered into web forms, URL parameters, or cookies
One of the oldest but still extremely common attack types

Security Issues in Libraries

Applications often have many dependencies (libraries, frameworks), which form a significant part of the software
These libraries can have vulnerabilities, just like your own code
Many applications don't even know they are using vulnerable third-party code
Hackers can exploit those third-party security holes to compromise your entire application
This is why tools like Snyk, Dependabot, and OWASP Dependency-Check exist

Weak Passwords

Cybercriminals use trial and error (brute force) to break into networks or websites
They typically use automated hacking tools to attempt thousands of login combinations
People commonly use weak passwords and reuse the same password across multiple systems
For companies, it's essential to enforce strong password policies
Password manager tools can help users maintain unique, complex passwords

DoS — Denial of Service Attack

Makes an application unable to respond to legitimate user requests
Often involves thousands of bots sending requests simultaneously (DDoS — Distributed Denial of Service)
This results in the attacker:
- Consuming all available bandwidth
- Consuming too many connections
- Exhausting the server's resources (CPU, memory)
The goal is not to steal data, but to take the service offline

Security Posture

Refers to an organisation's overall security status and its ability to defend against and respond to security threats and incidents
Key questions to evaluate:
- How secure are the applications?
- How secure is the underlying infrastructure?
A strong security posture means having visibility, controls, and response capabilities across all layers
It's a security principle that it is easier to hack into systems than to defend them — this is why layered, proactive defence is critical

OWASP and the OWASP Top Ten

What is OWASP?

OWASP stands for Open Web Application Security Project
A nonprofit organization dedicated to improving the security of software
Raises awareness about common web application security risks
Provides resources, tools, and documentation to help organizations and developers enhance security
One of OWASP's most well-known initiatives is the OWASP Top Ten

The OWASP Top Ten

The OWASP Top Ten lists the most critical web application security risks. Companies should adopt this document to minimize these risks. It is regularly updated to reflect emerging security trends.

Broken Access Control
Cryptographic Failures
Injection
Insecure Design
Security Misconfiguration
Vulnerable and Outdated Components
Identification and Authentication Failures
Software and Data Integrity Failures
Security Logging and Monitoring Failures
Server-Side Request Forgery (SSRF)

1. Broken Access Control

Access control enforces policies so that users cannot act outside of their intended permissions
Failure leads to unauthorized access — users seeing or doing things they shouldn't
Common vulnerabilities:
- Violation of the least privilege principle — giving users more access than they need
- Bypassing access control checks by modifying the URL (e.g., changing /user/123 to /user/456)
- Fails to detect request forgery
- Returning unauthorized data in API responses
- Phishing attacks and session hijacking exploiting weak access controls

2. Cryptographic Failures

Previously known as "Sensitive Data Exposure" — the name shift emphasizes the root cause rather than the symptom
Common vulnerabilities:
- Lack of or weak cryptography
- Hard-coded sensitive data in source code
- Use of broken or risky crypto algorithms (e.g., MD5, SHA-1 for passwords)
- Using insecure protocols (e.g., HTTP instead of HTTPS, FTP instead of SFTP)
You must protect data in transit and at rest
Leads to sensitive data exposure and access to unauthorized resources

3. Injection

Allows hackers to inject malicious code into an application
The injected code can be JavaScript, SQL, NoSQL, OS commands, or template code
Types include:
- Cross-Site Scripting (XSS)
- SQL Injection
- Template Injection — exploiting server-side template engines
How to avoid:
- Validate and sanitize all user input
- Avoid creating templates from user input
- Always expect malicious user input by default — never trust client-side data

4. Insecure Design

Focuses on risks related to design and architectural flaws — not implementation bugs
This is about issues in the pre-implementation phase — the design itself is insecure
Insecure design vs. insecure implementation: You can have a perfectly implemented system that is still fundamentally insecure because the design didn't account for certain threats
Missing or ineffective control design leads to:
- Bad credential management
- Bad permission handling
- Insecure infrastructure configuration
The call for more:
- Threat modelling — systematically identifying possible threats for a specific application or system
- Secure design patterns — proven architectural patterns that are inherently more secure
- Reference architectures — vetted blueprints that organisations can adopt

5. Security Misconfiguration

Can occur at any level — storage, network config, application config
Examples:
- Improper access configuration
- Unnecessary open ports
- SSH port allowing access from any source (should be restricted to known IPs)
- Debugging features enabled in production
- Using default accounts and passwords (e.g., admin/admin)
Modern applications have become more complex and highly configurable, which means more chances of misconfiguration
This is one of the most commonly seen issues in cloud environments (e.g., open S3 buckets, overly permissive security groups)

6. Vulnerable and Outdated Components

There is no difference between your own code and library code from a security threat perspective
A vulnerability in a third-party library affects your whole system
You are likely vulnerable if:
- You don't know the versions of all components you use
- You do not scan for vulnerabilities regularly
- Developers do not test the compatibility of updated, upgraded, or patched libraries
This is why having an SBOM (Software Bill of Materials) and automated dependency scanning is critical

7. Identification and Authentication Failures

Relates to the failure to properly identify and authenticate users
Identification: The act of identifying a particular user (often through a username)
Authentication: The process of validating that a user is who they claim to be (proof of identity)
Common vulnerabilities:
- Weak confirmation of user identity
- Allowing weak passwords
- Missing or ineffective multi-factor authentication (MFA)
- Weak credential password recovery process
- Plain-text or weakly hashed passwords stored in the database
- User sessions not properly invalidated after logout or timeout

8. Software and Data Integrity Failures

Relates to code and infrastructure that does not protect against integrity violations
Examples:
- Using libraries and plugins from unverified sources
- Auto-update downloading without integrity verification (no checksum or signature validation)
- Weak digital signatures that can be forged
This category also covers CI/CD pipeline integrity — ensuring that your build artifacts haven't been tampered with

9. Security Logging and Monitoring Failures

This category exists to help detect, escalate, and respond to active breaches
Without logging and monitoring, breaches cannot be detected
Logging and Tracing:
- Without it, we have no insights on system behavior
- Involves recording events, actions, and errors
Monitoring and Alerting:
- Must notify on attack attempts
- Without monitoring, you are blind and deaf to attacks
- Gives attackers enough time to probe around in systems undetected
The pipeline: Logging → Monitoring → Alerting

10. Server-Side Request Forgery (SSRF)

SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL
Allows an attacker to coerce the application to send a crafted request to an unexpected destination (accessing a protected resource)
SSRF attacks circumvent firewalls, VPNs, and network access control lists
Attack scenarios:
- Port scanning internal servers
- Sensitive data exposure from internal services
- Access metadata storage (e.g., cloud instance metadata like AWS 169.254.169.254)

Security in Layers (Defense in Depth)

Security must be implemented at multiple layers — this is the principle of layered security or defense in depth.

It includes:

Access management — who can access what
Network security — firewalls, segmentation, VPNs
Application security — secure code, input validation, auth
Logging — recording everything that happens
Monitoring — watching for anomalies and threats

The layers (from outermost to innermost):

Policy & Procedures — organizational security policies
Physical — physical access to data centers and hardware
Network — firewalls, network segmentation, IDS/IPS
Host — OS hardening, patching, endpoint protection
Application — secure coding, vulnerability scanning
Data — encryption, access controls, backups

The key principle: If attackers gain access to some part of our system, they should not get access to our whole system. Each layer acts as an independent barrier.