adelvalle/scrivas
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Initial Scrivas AWS discovery deliverables

Browse Source 
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.
This commit is contained in:
Alvaro Del Valle
2026-08-19 14:50:09 -04:00
commit 3cce1fa61f
17 changed files with 67154 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
findings/discovery_report.md
+72
View File
@@ -0,0 +1,72 @@
# 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 | `716468089330` — *Scrivas Admin* (`ScrivasAdmin@scrivas.com`) |
| Member accounts | `547868853286` — *Lazka* (`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 |
---
## 4. Recommended next discovery steps
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
```bash
# 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`.