Files
scrivas/findings/discovery_report.md
T
Alvaro Del Valle 3cce1fa61f Initial Scrivas AWS discovery deliverables
Read-only cloud discovery of the Scrivas AWS Organization (o-qfj0pvhhv7)
to inform a proposal.

- scripts/: boto3 org assessment, member-account assessment, fast discovery
- findings/: self-contained HTML dashboards, written report, summary JSON,
  and the rendered Prowler benchmark report
- docs/full_discovery_plan.md: phased full-discovery plan
- index.html: landing page linking all reports
- Pipfile/.python-version: reproducible pipenv env (Python 3.12.11)

Large raw scans (OCSF JSON, CSV, compliance/) are git-ignored.
2026-08-19 14:50:09 -04:00

4.1 KiB

Scrivas — AWS Organizations Discovery & Account Assessment

Prepared by: Dasnuve · Date: 2026-08-19 Access used: dasnuve-scrivas-louis-impersonation profile → arn:aws:iam::716468089330:user/louis (member of Admin, devops) Method: Read-only boto3 enumeration. Scripts in scripts/, raw output in findings/*.json.


1. Organization at a glance

Property Value
Organization ID o-qfj0pvhhv7
Feature set ALL
Management account 716468089330Scrivas Admin (ScrivasAdmin@scrivas.com)
Member accounts 547868853286Lazka (lgarrido@gmail.com)
Organizational Units None (flat — all accounts under Root)
Policy types enabled SERVICE_CONTROL_POLICY

Two-account, no-OU structure. All security tooling and all workloads currently live in the management account.


2. Assessment findings — the three targets

2a. Trusted access services (6 enabled)

cloudtrail · securityhub · guardduty (+ malware-protection.guardduty) · inspector2 · notifications

Org-wide security services have trusted access enabled — the client has started centralizing security.

2b. Delegated administrators — NONE ⚠️ (headline gap)

list_delegated_administrators returns empty. GuardDuty, Security Hub, and Inspector have org trusted-access enabled but no member account is delegated to administer them, so they are operated directly from the management account. AWS best practice is to delegate these to a dedicated security/audit account and keep the management account free of workloads and day-to-day operations.

2c. Trust policies

  • Organization resource policy: none set.
  • IAM role trust relationships (management account, 44 roles): almost all AWS service / service-linked roles. Two third-party cross-account trusts, both correctly gated with an ExternalId:
    • IntruderReadOnlyRole → trusts 123311413059 (Intruder.io — external vuln scanning)
    • SecureframeRole-f983f1e89008 → trusts 728997465891 (Secureframe — SOC 2 / compliance automation)
    • One OIDC-federated EKS role (AmazonEKS_EBS_CSI_DriverRole, cluster in us-east-2).
  • Lazka member account (6 roles): only default service-linked roles + OrganizationAccountAccessRole (trusts the management account). No GuardDuty/SecurityHub/Inspector roles present → org-enabled security services are not deployed into the member account.

3. Governance signals for the proposal

# Observation Why it matters
1 No delegated administrators despite trusted access enabled Security ops run from the mgmt account; violates AWS multi-account best practice
2 Workloads in the management account — EKS (scrivas-staging, gpu/infra/apps node groups), EC2, RDS, VPC flow logs Blast-radius & separation-of-duties risk; mgmt account should be minimal
3 Flat org, no OUs No policy boundaries (SCP targeting), hard to scale governance
4 Member account not monitored — Lazka lacks security service-linked roles Coverage gap; trusted access enabled but not delivered to members
5 Third-party access via Intruder + Secureframe; Macie/Config/Access Analyzer present Client is pursuing compliance — receptive to a landing-zone / governance engagement

  1. Enumerate the full resource footprint per account (compute/storage/network/cost) to size the proposal.
  2. Pull SCP contents attached to Root to understand existing guardrails.
  3. Pull CloudTrail configuration & organization trail status.
  4. Cost & Usage (Cost Explorer) for spend baseline and optimization signals.

5. How to reproduce

# Org-level assessment (management account)
python3 scripts/org_assessment.py --profile dasnuve-scrivas-louis-impersonation

# Member-account extension (assumes OrganizationAccountAccessRole)
python3 scripts/assess_member_account.py --account 547868853286 --name Lazka

Outputs: findings/org_assessment_report.json, findings/member_lazka_547868853286.json.