houey

The Email Trap: How Civilized Life Depends on a Single Point of Failure

Every morning, millions of people check their email before getting out of bed. What they don’t realize is that this single account controls access to nearly every aspect of their digital existence.

As someone who has spent two decades building authentication systems, I’ve watched a disturbing trend unfold: the complete colonization of daily life by email dependent services. What began as a convenient way to verify accounts has evolved into a digital house of cards where losing access to your email address can mean losing access to your electricity, healthcare, banking, and even your home.

This isn’t a theoretical security concern; it’s today's consumer protection crisis hiding in plain sight. When major email providers experience outages, face government seizures, or simply decide to terminate accounts, ordinary people lose access to the basic services they need to survive in modern society.

The Real Stakes: Life’s Necessities

houey

Breaking the Email Dependency: A Critical Security Vulnerability Hiding in Plain Sight

The single greatest threat to digital identity security isn’t sophisticated nation state attacks or zero day exploits; it’s the ubiquitous email address that serves as the skeleton key to our digital lives.

After two decades in cybersecurity, from building authentication systems at Fortune 500 companies to advising moonshot startups on digital identity, I’ve watched the same architectural flaw persist across every major platform: the dangerous over reliance on email as the ultimate root of trust. This dependency has created a house of cards that even security conscious organizations and individuals struggle to escape.

The recent erosion of privacy protections at major email providers, combined with increasing government surveillance capabilities, has transformed what was already a single point of failure into an existential threat to digital sovereignty. It’s time we acknowledge the depth of this problem and chart a

houey

#!/usr/bin/env python3


"""
AWS Identity Collector: Extract Trust and Privilege Data Across Accounts

This script collects identity and access metadata from one or more AWS accounts,
including IAM roles, IAM users, SSO (AWS IAM Identity Center) users, and their policies.
It’s used as a precursor for analyzing trust relationships and admin-equivalent access
across AWS environments.

houey

FWD:CLOUDSEC 2025 CONFERENCE ATTENDANCE PROPOSAL

EXECUTIVE SUMMARY

I am requesting approval to attend the fwd:cloudsec 2025 North American conference, a premier event focused on cloud security innovation and best practices. This conference represents a strategic investment in our organization's cloud security capabilities and will provide immediate value through expert-led sessions, hands-on training, and networking opportunities with industry leaders.

CONFERENCE DETAILS

Event: fwd:cloudsec 2025 North American Conference
Dates: [Insert conference dates when available]
Location: [Insert location when available]
Estimated Cost: [Insert estimate based on registration, travel, and accommodation]

houey

Complete AWS IAM Conditions and Operators Cheat Sheet

Table of Contents

1. String Operators
2. Numeric Operators
3. Date Operators
4. Boolean Operators
5. IP Address Operators
6. ARN Operators
7. Set Operators (Multiple Value)

houey

@echo off

REM Get list of SCPs in the organization
for /f "tokens=*" %%i in ('aws organizations list-policies --filter SERVICE_CONTROL_POLICY ^| jq -r ".Policies[].Id"') do (
    set scp_id=%%i

    REM Get SCP content
    for /f "tokens=*" %%j in ('aws organizations describe-policy --policy-id !scp_id!') do (
        set scp_content=%%j
    )

houey

#!/bin/bash

# Get list of SCPs in the organization
scps=$(aws organizations list-policies --filter SERVICE_CONTROL_POLICY | jq -r '.Policies[].Id')

# Loop through each SCP and save its content into a JSON file
for scp_id in $scps; do
    # Get SCP content
    scp_content=$(aws organizations describe-policy --policy-id $scp_id)

houey

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "NotAction": [
        "dax:*",
        "es:ESHttp*"
      ],
      "Resource": "*",
      "Effect": "Deny",

houey

Preface:

It is, unfortunately, extremely common for customers and enterprises operating in AWS to have chosen a workload/storage bearing account (more than likely, the main production account) as the Organization Management Account (formerly known Organization "Master" account, before AWS adopted better naming).
Many customers and companies operating in AWS made this decision in 2018 or so and its unforunately not something that can be easily changed as of 2024. Many customers have requests to AWS to make a friendly path for rehoming the Org Management account, but last I heard it is still not prioritized. Thus, we as customers are left to go through the nerve-wracking, if not dangerous process of migrating to a new AWS Organization in order to align with modern best practices and reduce common privilege escalation and account to account lateral movement concerns (made worse if you happen to have enabled things like Cloudformation Stacksets, Control Tower, or other powerful services in the same

houey

#usage deleteallapis.sh us-east-1
for api_id in $(aws apigatewayv2 get-apis --region $1 --query 'Items[*].ApiId' --output text); do aws apigatewayv2 delete-api --region $1 --api-id $api_id ; done