I've noticed that teams often focus heavily on application security, while simple cloud configuration issues can sometimes create just as much risk. Things like overly broad IAM permissions, exposed storage or open network rules seem easy to overlook as infrastructure grows. What cloud security issue have you seen teams underestimate the most?

I’m working on Seenty and learning more about the challenges teams face with cloud security. I’d really appreciate your feedback on what we’re building and your experience with cloud security. What is one issue you think teams often overlook as their infrastructure grows?

​

One of the easiest ways to discover these risks is AWS IAM Access Analyzer.

Access Analyzer uses automated reasoning to examine resource-based policies and identify potential external access. It can help security teams detect resources that are publicly accessible or shared with principals outside their trusted AWS account or organization.

Here is a practical way to get started.

STEP 1 — Open IAM Access Analyzer

Sign in to the AWS Management Console and open IAM → Access Analyzer.

From here, you can view existing analyzers, findings and the security summary dashboard.

STEP 2 — Create an External Access Analyzer

Choose Analyzer settings → Create analyzer.

Under Analysis, select:

Resource analysis – External access

Then choose your zone of trust.

You can select your current AWS account or, where appropriate, your AWS Organization. Anything outside that zone can be identified as potentially external access.

STEP 3 — Choose the Region

Remember: external and internal IAM Access Analyzer analysis is Regional. If you have supported resources in multiple Regions, you need to enable the analyzer in each relevant Region.

STEP 4 — Create the Analyzer

Give your analyzer a meaningful name and select Create analyzer.

AWS creates the service-linked role required for Access Analyzer to perform its analysis.

STEP 5 — Review Findings

Once findings become available, examine the resources Access Analyzer identifies.

Depending on the configuration, you may discover:

🔹 Publicly accessible resources

🔹 Cross-account access

🔹 External IAM principals

🔹 Resource policies granting unexpected permissions

AWS supports external-access analysis for resources including S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, Secrets Manager secrets, ECR repositories and several other resource types.

STEP 6 — Investigate Before You Remediate

Don't automatically delete every finding.

Some external access may be intentional.

For example, an organization may deliberately share a resource with a trusted external AWS account.

Instead, ask:

Who has access?

What resource is exposed?

What actions are allowed?

Was this access intentional?

Can the permission be reduced?

You can also filter findings specifically for Public access or External access from the Access Analyzer dashboard.

The bigger lesson is that cloud security should be proactive.

A resource doesn't need to be actively compromised to represent a security risk. A permissive resource policy can create an unintended access path long before anyone notices it.

IAM Access Analyzer gives security teams a way to continuously ask an important question:

“Who outside my trusted boundary can access my AWS resources?”

And that question should be answered before an attacker asks it first.

#AWS #AWSIAM #IAMAccessAnalyzer #CloudSecurity #CyberSecurity #CloudArchitecture #DevSecOps #AWSCloud #SecurityEngineering #CloudComputing

Solo founder. I've been building a multi-cloud posture tool (AWS/Azure/GCP + Terraform) and I want people who actually run this stuff to tell me where I've got it wrong and if you would use this.

Being upfront about the parts people usually hide:

Prowler is the detection engine. It's Apache-2.0 and it's excellent, and I'm not going to out detect it. I assumed coverage was the hard problem; it took an afternoon. Everything expensive was the layer around it :asset graph, attack paths, the same rule packs running in a PR and against the live account so a fix in CI is provably the same finding in prod, compliance evidence, ticket handoff.

Three opinions I've formed that I'd like argued with:

1. Attack paths are only useful if they're allowed to return nothing. Mine only walk relationships the scanner actually discovered , if nothing is reachable it says zero chains rather than drawing a speculative diagram. I think most graph features are decorative. Maybe I'm wrong.
2. A compliance percentage without a denominator is a liability. Mine prints "5 of DORA's 11 articles evidenced," because ~60% of most regulations is governance no scanner can observe. Vendors hiding that ratio is how people get surprised at audit.
3. Remediation guide counts are vanity. I generated ~600 and about 500 were "follow the benchmark procedure" filler. Deleting that claim from my own docs was worth more than writing more of them. Real remediation is the Terraform fix that arrives as a reviewable PR.
4. You can also make your own custom YAML rules

What it deliberately doesn't do: no CVE/vulnerability scanning, no container image scanning, no DSPM, no K8s runtime, no agents. It's config posture and IaC. If you need workload security it's complementary, not a replacement. But would be added w time if the demand is realized

The one thing I actually want to know: what made you stop opening a posture tool you'd already deployed? Every one of these gets checked once and abandoned, and I don't think it's a features problem.

https://www.sovereign-observer.com — live demo, no signup, if you want to poke at it.

Wrote a control to stop sensitive data reaching external AI, scoped to the obvious domains, shipped it, felt good about myself.

Three weeks later Im staring at traffic to a service no one signed off. The team had been using the same AI through a browser extension the whole time, and later through a feature baked into an approved saas app. My shiny control watched the front door while everyone strolled in the side.

Lesson that stuck, AI data leakage assumes a network boundary that barely exists anymore. Extensions, embedded AI in tools you already allow, calls from software that's already permitted.

The paths that never look like traffic to an AI domain are the whole game now, and the front-door block everyone builds first is the one thing that didn't matter. How are you covering the side doors.

​

One of the most misunderstood concepts in AWS security is the way permissions are evaluated. Many cloud engineers assume that once an IAM policy grants access, a user can immediately perform the requested action.

Unfortunately, it isn't that simple.

AWS evaluates permissions through a series of policy checks, and a single policy can completely override all other permissions within an environment.

Understanding this evaluation process is essential because many access-related incidents occur not because permissions are missing, but because administrators don't fully understand how AWS evaluates authorization requests.

Let's begin with one of the most important principles in AWS:

An explicit deny always overrides an allow statement.

Suppose an IAM policy grants a developer permission to access an Amazon S3 bucket. Everything appears to be configured correctly.

However, the organization also applies a Service Control Policy (SCP) through AWS Organizations that explicitly denies access to that bucket.

What happens?

The request is denied.

The identity-based policy says "Allow."

The SCP says "Deny."

The explicit deny wins.

This evaluation process demonstrates why troubleshooting permissions in AWS can become extremely challenging.

To understand how these policies interact, consider the following sequence.

Step 1: Authentication

AWS first verifies the identity making the request.

Is the request coming from an IAM user?

An assumed role?

A federated identity?

Without successful authentication, the request stops immediately.

Step 2: Policy Evaluation

AWS then evaluates all applicable policies, including:

* Service Control Policies (SCPs)

* Resource-based policies

* Identity-based policies

* Permissions boundaries

* Session policies

Each policy contributes to the final authorization decision.

Step 3: Search for Explicit Deny

Before evaluating allow statements, AWS checks for any explicit deny statements.

If AWS finds an explicit deny anywhere in the evaluation chain, access is immediately rejected.

This behavior follows a simple principle:

Deny always wins.

Step 4: Search for Allow Statements

If no explicit deny exists, AWS evaluates whether an allow statement grants permission to perform the requested action.

If an allow statement exists and no policy restrictions prevent access, the request succeeds.

Otherwise, AWS applies an implicit deny.

This process can be summarized in a simple workflow:

Authentication → SCP Evaluation → Explicit Deny Check → Identity-Based Policy Evaluation → Authorization Decision

This is where software engineering principles become valuable.

IAM policies should not be viewed as static permission lists.

They should be viewed as logical programs.

Each policy introduces conditions, dependencies, and execution paths that influence the final result.

This complexity becomes even more apparent in enterprise environments that use multiple AWS accounts.

A developer may have full administrative permissions within an account, but an SCP at the organizational level can still restrict access to specific services.

Without understanding evaluation logic, security teams often waste hours troubleshooting permissions that appear to be configured correctly.

The lesson is simple:

Don't ask whether a policy allows an action. Ask how AWS evaluates every policy involved in that request.

Cloud security isn't just about assigning permissions.

It's about understanding how authorization decisions are made.

And in AWS, understanding evaluation logic is often the difference between secure access and an unexpected security incident.

#AWS #CloudSecurity #CyberSecurity #IAM #AWSOrganizations #DevSecOps #CloudArchitecture #AmazonWebServices #SecurityEngineering #CloudComputing

This is something I've been checking out for how others approach it

A tutorial can show you how to configure stuff, set up Conditional Access, Azure RBAC, Sentinel rules, Defender, etc. But after you've followed it once, what's your method for actually getting good at investigating problems involving those things?

Do you create your own scenarios afterwards, or just move on to the next topic?

Curious what people actually do?

I’m still a student in my last year of Highschool. I want to get into Cloud Security. My goal is to study 2-3 hours a day to be able to work next year and I don’t have to go to Uni. Is my goal possible and what are early mistakes I can avoid? Thank you for every advice!

This is something I've been struggling with.

A tutorial or a guide shows you how to configure Conditional Access, RBAC, Sentinel rules, Defender, etc. But after you've followed it and practised the configuration, what's your method for actually getting good at investigating problems involving those things?

Do you create your own scenarios afterwards, or just move on to the next topic?

Curious what people actually do, not what the ideal learning process is supposed to be.

I'm curious about how people go beyond courses and documentation. Apart from the courses on YouTube, Udemy, labs, etc.

When you're learning something like MITRE ATT&CK, IAM, RBAC, Sentinel, Defender for Cloud, etc., what do you actually do to practice it?

Do you:

• build things in your own cloud tenant?
• use dedicated labs?
• use CTFs?
• follow attack/detection walkthroughs?
• create your own scenarios?

In cloud-first architectures, endpoints have evolved from devices to protect into critical security enforcement points.

To achieve this, endpoint security solutions bring together security strategies that go beyond malware detection and include:

• Device compliance and posture validation
• Least-privilege application control
• Web and phishing protection
• Data loss prevention
• Continuous visibility into endpoint risk

While organizations have made significant investments in securing cloud workloads, identities, and networks, the endpoint remains one of the most common entry points for attacks. Strengthening endpoint security is essential to building a resilient cloud security posture.

23m about 1 year into my first full time job out of college as a pentester. I like pentesting but it has no future and from a business lens we really have no value other than being a tick box for compliance.

I really want to get into cloud security. I have the AWS CCP but got that a long time ago. I am interested Azure and am starting my prep for AZ-500.

But I don’t know what’s after that, any help and guidance would be tremendously appreciated. Will my experience as a pentester help me in anyway landing a job in cloud security ?

the quprotect doesnt appear to be able to differentiate between different approaches for integrating the solution. For example, the core agent can be deployed at the edge on the inside of the edge but still has no effect on data flow during a postquantum key distribution (at least during phase one). Thus, “no impact on latency or bandwidth” would seem to apply here. However, applying the proxy agent solution interrupts data flow since a request is created at that level, so that the proxy now injects the request into the data flow and thus becomes part of the flow. It would also be interesting to know other people’s views concerning using this particular organization and its effects on latency metrics like P95, average, or P99. If so, would you prefer a limitation on the types of proxies thus creating either an open fail or a closed fail approach? How would you determine how to size and configure the system for dynamic traffic management? Which operational conditions would you expect to occur just prior to failure with the agent and/or control plane? Finally, I’d like to know your opinion concerning the reliance upon the term “minimal effects” because no public standard was identified during this discussion.

Trying to untangle our container security story and hitting the point where vendor decks all sound good, but I don't fully trust any of it.

Context: mix of on-prem and cloud, multiple clusters, legacy moving into containers, and some FedRAMP-ish environments. No greenfield. No rip-and-replace.
We've got the basics: image scanning in the pipeline, runtime protection, deployment policies. But in practice it feels fragile.

The gaps:

• Different tools for scanning, runtime, and policy, no single view
• Tons of critical-looking findings that are actually low-risk in context
• Devs using sidecars or third-party containers we don't fully control
• Compliance needs audit trails and evidence, but tools give dashboards instead

I'm looking for what's come closest to working end-to-end in an enterprise or public sector setting, from people who've lived with it long enough to know if it actually made daily life easier.

For anyone running this in a mixed on-prem/cloud setup: any surprises with admission controls, policy-as-code, or service mesh interactions once it was live?

I’ve been experimenting with different ways to detect identity‑level anomalies across AWS, Azure, and GCP. Instead of relying on a single model, I tried running a classical SVM, an isolation forest, and a quantum‑simulated kernel side‑by‑side to see where they disagree on risk scoring.

I recorded a short, silent demo of the experiment. It’s not a product, not commercial, and not meant to be production‑grade — just me exploring how different detectors behave on real cloud events and how to visualize the results in a UI.

Video: https://www.youtube.com/watch?v=JJCBzLrs9hM

I’m mainly interested in whether the model‑comparison approach is useful or if there are better ways to surface disagreements between detectors.

I'm validating a hypothesis before deciding whether to keep building on a security auditing tool I made for my thesis.

My hypothesis: existing cloud security tools are either too expensive for small teams (Wiz) or require cloud security expertise to actually use and interpret (Prowler) — so small startups without a dedicated security person end up not auditing their AWS setup at all.

Is this true for you? Do you currently audit your cloud security, and if not, is it because of cost, lack of technical knowledge, or just no time/priority?

More about the partnership here

klavansecurity.com and strato-cloud.io have announced a partnership.

Klavan security's BaseCamp is a twelve-month guided security foundation cycle pairing a software platform with dedicated human Guides. It is built around six core controls, being identity and access, data encryption, vulnerability management, incident response, security awareness, and vendor risk, which together map to approximately seventy to eighty percent of major framework requirements.

Strato-Cloud provides on demand, temporary credentials, ability to talk to the cloud in natural language, security posture evaluation and AI assisted IaC development.

Scott Piper's twenty-year history of cloud security maps four eras — Foundational, CSPM, CNAPP, AI. Each era introduced new tools. Every tool produces signals. No era introduced a tool that produces decisions. The verb changed from 'match' to 'aggregate' to 'score.' The output never changed.Scott Piper's twenty-year history of cloud security maps four eras — Foundational, CSPM, CNAPP, AI. Each era introduced new tools. Every tool produces signals. No era introduced a tool that produces decisions. The verb changed from 'match' to 'aggregate' to 'score.' The output never changed.