Vocabulary for Cloud Security Engineers

Cloud security engineering has developed a highly specific vocabulary drawn from traditional information security, cloud-native practices, and compliance frameworks. Whether you are communicating risk to non-technical stakeholders, writing runbooks, or participating in threat modelling sessions, precision in this vocabulary matters.

Cloud Security Posture

Security Posture

Security posture refers to the overall state of an organisation’s security readiness — including policies, configurations, patch levels, and detection capabilities.

“Our current security posture assessment identified seventeen critical misconfigurations across our three AWS accounts.” “Improving our security posture requires both technical controls and process changes.”

CSPM (Cloud Security Posture Management)

CSPM tools continuously monitor cloud infrastructure for misconfigurations, policy violations, and compliance gaps.

“We deployed a CSPM tool that now scans all S3 buckets for public access configurations and alerts us immediately when a new one is introduced.” “The CSPM flagged that our production RDS instance was not encrypted at rest — a critical finding.”

CWPP (Cloud Workload Protection Platform)

A CWPP provides security for workloads running in cloud environments — including containers, VMs, and serverless functions — focusing on runtime protection and vulnerability management.

“The CWPP detected an unusual process running inside a container at runtime and automatically isolated the affected pod.”

Identity and Access Management

IAM Policy

An IAM (Identity and Access Management) policy is a document that defines what actions an identity (user, role, or service) is allowed or denied on specific resources.

“The IAM policy grants the Lambda function read access to the S3 bucket but explicitly denies deletion operations.” “We follow the principle of least privilege — every IAM role should have only the permissions it strictly needs.”

Principle of Least Privilege (PoLP)

The principle of least privilege states that a user, service, or system should have access to only what it needs to perform its function — nothing more.

“Our audit found that several service accounts had AdministratorAccess attached — a direct violation of the principle of least privilege.”

Role Assumption

Role assumption is the process of temporarily adopting the permissions of another IAM role.

“The CI/CD pipeline assumes the DeploymentRole to push container images to ECR and update the ECS service.”

Service Control Policy (SCP)

An SCP is an organisation-level policy in AWS that sets maximum permission boundaries across all accounts in an AWS organisation.

“We use SCPs to prevent any account in the organisation from disabling CloudTrail or changing the security logging configuration.”

Threat Modelling

Threat Modelling

Threat modelling is a structured process for identifying, prioritising, and mitigating potential security threats to a system before they are exploited.

“We conduct a threat modelling session for every new service before it reaches production. The output is a list of threats, their likelihood, their potential impact, and the mitigations we’re implementing.”

STRIDE

STRIDE is a common threat modelling framework that categorises threats by type:

• Spoofing — impersonating another user or system
• Tampering — modifying data or code
• Repudiation — denying an action took place
• Information Disclosure — exposing data to unauthorised parties
• Denial of Service — making a system unavailable
• Elevation of Privilege — gaining access beyond what is authorised

“Using STRIDE, we identified an elevation of privilege risk in the admin API — the endpoint wasn’t verifying that the requester’s role matched the operation.”

Attack Surface

The attack surface is the total set of points where an attacker could try to enter or extract data from a system.

“Reducing the attack surface was one of our key security objectives — we removed three unused public endpoints and disabled SSH access in favour of SSM Session Manager.”

Blast Radius

Blast radius describes the extent of damage that a security incident or compromise could cause.

“By isolating each microservice into its own IAM role, we limit the blast radius of a credential compromise — an attacker who steals one role can only access that service’s resources.”

Detection and Response

SIEM (Security Information and Event Management)

A SIEM collects and correlates security logs from across an environment and generates alerts for suspicious activity.

“We centralise logs from CloudTrail, VPC Flow Logs, and application logs into our SIEM. It detected an unusual pattern of API calls at 3 AM that turned out to be a credential stuffing attempt.”

Zero Trust

Zero trust is a security model that assumes no user, device, or service should be trusted by default — even if they are inside the network perimeter. All access must be explicitly verified.

“We’ve moved to a zero trust model: every service-to-service call requires a valid short-lived token, regardless of whether it’s internal or external.”

Security Group and Network ACL

• A security group is a stateful virtual firewall for EC2 instances and other resources.
• A network ACL (NACL) is a stateless firewall at the subnet level.

“The security group for the database tier allows inbound traffic only from the application security group — not from the public internet.”

Practical Phrases for Cloud Security Engineers

• “This IAM role is overly permissive — I’d recommend scoping it down to the specific S3 bucket ARN.”
• “We identified this in our threat model as a high-likelihood, high-impact risk.”
• “The blast radius of a compromised service account is limited because of our workload isolation strategy.”
• “Our CSPM flagged this as a critical misconfiguration — we need to remediate within 24 hours per our policy.”
• “We apply the principle of least privilege at both the IAM role level and the SCP level.”

Cloud security vocabulary bridges the gap between technical controls and business risk language. Using these terms accurately allows you to communicate security concerns effectively to both engineering peers and non-technical leadership.

In Practice: Bridging the Gap – Phrasing for Collaboration

For non-native speakers, understanding not just what a term means but how it’s used in conversation is often the biggest hurdle. Cloud security isn’t just about technical definitions; it’s a highly collaborative field. You’ll be constantly communicating with other engineers, operations teams, and sometimes even business stakeholders – all speaking (or attempting to speak) a common language of security best practices. A perfectly accurate translation doesn’t always translate into effective communication. Let’s look at some specific scenarios where nuanced phrasing is crucial.

Consider a code review comment. A simple “This violates IAM policy” isn’t enough. A native speaker would likely say, “I noticed this resource has overly permissive access; it might be beneficial to scope down the IAM roles assigned to this service to minimize potential blast radius in case of compromise.” This phrasing immediately provides context – why it’s a problem and suggests a solution. It acknowledges the reviewer’s perspective while constructively highlighting the issue. Similarly, when writing a Pull Request description, avoid overly literal translations. Instead of “Implemented vulnerability scan,” try “Performed automated vulnerability scanning using [Tool Name] to identify potential weaknesses in the application architecture and deployed remediation steps as recommended.” The latter provides more information about the process and the outcome.

Another common challenge is discussing security posture. It’s not just about stating that something is “secure”; it’s about articulating how secure it is within a defined context. Phrases like “Our current security posture aligns with CIS benchmarks for AWS” are standard, but adding detail – “Specifically, we’ve implemented all controls outlined in the CIS benchmark for EC2 instances and have documented our configuration changes” – demonstrates a deeper understanding and allows others to assess the level of assurance. Remember, clear and concise communication reduces ambiguity and fosters trust within your team.

Finally, don’t be afraid to ask for clarification. If you’re unsure how someone is using a term or phrasing, politely request an explanation. For example, if a teammate says “Let’s harden the CWPP,” you could respond with, “Could you elaborate on what ‘hardening the CWPP’ entails in this context? I want to ensure I understand the specific steps involved.” This demonstrates your commitment to learning and collaborating effectively.

# Example using AWS Security Hub CLI for identifying vulnerabilities
aws securityhub findings list --region us-east-1 --query "Findings[*].Id"

This command illustrates a practical use case – quickly querying Security Hub for identified vulnerabilities. The phrasing here is straightforward, but understanding the purpose of running this command (to prioritize remediation efforts) is equally important.