🛡️ Checklists and brainstorming for attack surfaces

_category_ copy.json

@@ -0,0 +1,6 @@
+{
+  "label": "operationss-ish"
+}
+commti combining finincails with taxes
+
+onbeanigng beta to legacy static

_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Compliance Manual"
+}
+not forall

incidents/README.md

@@ -2,112 +2,78 @@
 
 Create a private inventory and public tracking issue for AWS/cloud access governance without exposing sensitive account details.
 
+The goal is to make sure the project knows which cloud accounts, identities, credentials, and permissions exist; who owns them; whether they are still needed; and how they would affect incident detection, investigation, containment, and recovery.
+
 ### Inventory scope
 
-- [ ] Inventory all cloud computing accounts currently in use.
-- [ ] Inventory all AWS accounts involved in the project.
-- [ ] Inventory all service accounts.
-- [ ] Inventory all human user accounts.
-- [ ] Inventory all console-access accounts.
-- [ ] Inventory all accounts with API access.
-- [ ] Inventory all accounts with cross-account access.
-- [ ] Inventory all tokens used between accounts.
-- [ ] Inventory all access keys.
-- [ ] Inventory all API keys.
-- [ ] Inventory all long-lived credentials.
-- [ ] Inventory all temporary credentials or session-based access paths.
+- [ ] Inventory all cloud accounts and identities currently in use, including AWS accounts, human users, service accounts, console access, API access, and cross-account access.
+- [ ] Inventory all credentials and access paths, including API keys, access keys, tokens, long-lived credentials, and temporary or session-based access.
 - [ ] Inventory all accounts that can access protected data.
-- [ ] Inventory all accounts used for CRON jobs or automated workflows.
-- [ ] Inventory all accounts used by deployment systems.
-- [ ] Inventory all accounts used by monitoring, logging, or alerting systems.
-- [ ] Inventory all accounts used by third-party services.
+- [ ] Inventory all non-human and automation access, including CRON jobs, automated workflows, deployment systems, monitoring, logging, alerting systems, and third-party services.
 - [ ] Inventory all backup, archival, or recovery access paths.
+- [ ] Store the sensitive inventory in a private operational record.
 
 ### Admin account review
 
 - [ ] Identify all admin accounts.
-- [ ] Treat any account that can create other accounts as an admin account.
-- [ ] Treat any account that can grant permissions as an admin account.
-- [ ] Treat any account that can rotate credentials as an admin account.
+- [ ] Treat any account that can create accounts, grant permissions, or rotate credentials as an admin account.
 - [ ] Treat any account that can access protected data as requiring elevated review.
-- [ ] Document who owns each admin account.
-- [ ] Document why each admin account exists.
-- [ ] Document whether each admin account is still needed.
+- [ ] For each admin account, document the owner, business purpose, and whether the access is still needed.
 - [ ] Remove or reduce unnecessary admin access.
 - [ ] Confirm that admin accounts use MFA.
 - [ ] Confirm that root or owner-level accounts are separately protected.
 
 ### Credential review
 
-- [ ] Record when each password was last changed.
-- [ ] Record when each API key was last rotated.
-- [ ] Record when each access key was last rotated.
-- [ ] Record when each console-access token was last reviewed.
+- [ ] Record the last rotation or review date for each credential.
 - [ ] Record whether each credential is still active.
-- [ ] Record whether each credential is assigned to a known owner.
-- [ ] Record whether each credential has a documented business purpose.
-- [ ] Record whether each credential has least-privilege permissions.
-- [ ] Record whether any credentials are stale or unused.
-- [ ] Remove stale credentials.
+- [ ] Confirm each credential has a known owner.
+- [ ] Confirm each credential has a documented business purpose.
+- [ ] Confirm each credential has least-privilege permissions.
+- [ ] Identify stale, unused, or unnecessary credentials.
+- [ ] Remove stale or unused credentials.
 - [ ] Rotate credentials that are overdue.
-- [ ] Establish a recurring key-rotation cadence.
+- [ ] Establish a recurring credential rotation and review cadence.
 
 ### Access-policy review
 
-- [ ] Review what each account can access.
+- [ ] Review each account’s effective permissions.
 - [ ] Review what protected data each account can reach.
 - [ ] Review whether access is read-only or write-capable.
-- [ ] Review whether any account can modify logs.
-- [ ] Review whether any account can disable monitoring.
-- [ ] Review whether any account can change security settings.
-- [ ] Review whether any account can create, delete, or alter users.
-- [ ] Review whether any account can create, delete, or alter service accounts.
-- [ ] Review whether any account can create new API keys.
+- [ ] Review whether permissions match the current operational need.
+- [ ] Review whether any account can alter security-critical controls, including logs, monitoring, or security settings.
+- [ ] Review whether any account can manage identities or credentials, including users, service accounts, and API keys.
 - [ ] Review whether any account can assume roles across accounts.
 - [ ] Review whether any public or shared credentials exist.
-- [ ] Review whether permissions match the current operational need.
+- [ ] Remove or reduce permissions that are broader than needed.
 
 ### Incident response connection
 
 - [ ] Map accounts to the incident response program.
-- [ ] Identify which accounts could be involved in detecting breaches.
-- [ ] Identify which accounts could be involved in investigating breaches.
-- [ ] Identify which accounts could be involved in containing breaches.
-- [ ] Identify which accounts could be involved in recovering from breaches.
-- [ ] Identify which accounts have access to protected data.
-- [ ] Identify which logs are needed to detect misuse of each account.
+- [ ] Identify which accounts could be involved in detecting, investigating, containing, or recovering from breaches.
+- [ ] Identify which accounts could affect protected data during an incident.
+- [ ] Document the logs needed to detect misuse of each account.
 - [ ] Identify where access logs are stored.
 - [ ] Identify who reviews access logs.
 - [ ] Identify how suspicious access is escalated.
-- [ ] Identify what happens if an admin account is compromised.
-- [ ] Identify what happens if a service account is compromised.
-- [ ] Identify what happens if an API key is exposed.
+- [ ] Document response procedures for compromised admin accounts, service accounts, and exposed API keys.
+- [ ] Confirm that incident responders know where the private access inventory is stored.
 
 ### Review cadence
 
-- [ ] Establish a recurring review cadence for all accounts.
-- [ ] Establish a recurring review cadence for admin accounts.
-- [ ] Establish a recurring review cadence for API keys.
-- [ ] Establish a recurring review cadence for access tokens.
-- [ ] Establish a recurring review cadence for service accounts.
-- [ ] Establish a recurring review cadence for cross-account access.
-- [ ] Establish a recurring review cadence for protected-data access.
+- [ ] Establish recurring review cadences for accounts, admin access, service accounts, credentials, cross-account access, and protected-data access.
 - [ ] Document when each review occurs.
 - [ ] Document who performed each review.
 - [ ] Document what changed after each review.
 - [ ] Document any unresolved findings.
+- [ ] Track unresolved findings until they are resolved, accepted, or assigned a follow-up owner.
 
 ### Public issue safety
 
-- [ ] Do not publish account names if they create security risk.
-- [ ] Do not publish usernames.
-- [ ] Do not publish emails tied to privileged accounts.
-- [ ] Do not publish API keys.
-- [ ] Do not publish access keys.
-- [ ] Do not publish tokens.
-- [ ] Do not publish passwords or password-history details.
+- [ ] Do not publish sensitive identity details, including usernames, privileged-account emails, or account names that create security risk.
+- [ ] Do not publish secrets or credential details, including API keys, access keys, tokens, passwords, or password-history details.
 - [ ] Do not publish detailed permission maps if they would help an attacker.
-- [ ] Publicly document that the inventory exists.
+- [ ] Publicly document that the private inventory exists.
 - [ ] Publicly document that the inventory is reviewed on an appropriate cadence.
 - [ ] Keep the sensitive inventory in a private operational record.
 - [ ] Keep the public issue focused on policy, cadence, and evidence of review.

incidents/SECTIONS.md

@@ -0,0 +1,34 @@
+# ORGANIZATION final as README
+
+- Risk registry
+  - Control assessments
+  - Technology assessments
+  - Cybersecurity assessments
+- Vulnerability management
+  - TAD surfaces
+  - Stellar surfaces
+  - Deployment vulnerabilities
+- Key management
+  - Technical administration, provisioning
+  - Physical safeguards
+  - Oversight
+- Investor Classification
+  - Covered Investor Information
+  - Investor notices
+  - Mail materials
+- Service provider oversight
+  - What's outsourced (info diagrams)
+  - Public collaboration platforms
+  - Provider secrets access
+- Incident response program
+  - Intrusion detection
+  - Activity responses
+  - Response & recovery
+- Decentralized coordination
+  - Thesis ethos (ref values #decentralized {#collective-wisdom})
+  - Collaborative friendship ([gov -- Who owns risk, policy, roles, oversight, suppliers, and priorities])
+  - Open network ([detection and monitoring of the Registrant's intra environment; ec exec2])
+- Team reports
+  - Post security incidents **demonstrating Incident Response Program steps were followed**
+  - System monitoring log
+  - Team protective practices (**collection of concepts with sourcing akin to the nondirective bias basis)

incidents/_category_.json

@@ -0,0 +1,3 @@
+{
+  "label": "Compliance Manual"
+}

incidents/attack-surface-map.md

@@ -0,0 +1,63 @@
+# Attack Surface Map
+
+This document maps the primary attack surfaces that may affect covered investor information, operational records, internal systems, and incident response readiness.
+
+The map covers systems, accounts, vendors, communications channels, and human workflows that could be used to gain unauthorized access, disrupt operations, or expose sensitive information.
+
+## External Services
+
+- Cloud infrastructure
+  - AWS sys in py-TAD3
+  - storage, databases, and deployment services
+- Domain registrar, DNS, email delivery, and authentication services
+- Public websites, documentation sites, investor portals, and hosted forms
+- Third-party collaboration, support, analytics, and monitoring tools
+- Vendor support channels with administrative or diagnostic access
+
+## Identity and Access
+
+- Administrator accounts and privileged roles
+- Shared operational inboxes and distribution lists
+- Single sign-on, multi-factor authentication, and recovery workflows
+- API keys, access tokens, service accounts, and automation credentials
+- Onboarding, offboarding, and access review gaps
+
+## Application and Data Surfaces
+
+- Investor records, notices, subscription materials, and classification records
+- Internal spreadsheets, financial records, and operational documents
+- Application forms, upload flows, and document storage
+- Source repositories, deployment pipelines, and configuration files
+- Logs, exports, backups, and temporary working files
+
+## Communications Surfaces
+
+- Email conversations with investors, issuers, vendors, and service providers
+- Calendar invitations, shared documents, and messaging platforms
+- Public social, website, and repository activity
+- Support requests, vendor tickets, and incident communications
+
+## Human and Process Surfaces
+
+- Phishing, impersonation, and social engineering attempts
+- Manual handling of investor or issuer materials
+- Approval workflows for payments, account access, and vendor requests
+- Informal workarounds during urgent operations or incidents
+- Delayed revocation of access after role or vendor changes
+
+## Monitoring Signals
+
+- Unusual login location, device, or authentication pattern
+- Privileged role changes or new service credentials
+- Unexpected data export, deletion, or sharing activity
+- DNS, domain, email, or certificate changes
+- Source repository, deployment, or infrastructure configuration changes
+- Vendor notifications, abuse reports, or suspicious support activity
+
+## Response Priorities
+
+1. Identify the affected system, account, vendor, data set, and time window.
+2. Preserve logs and records before retention windows expire.
+3. Contain access by rotating credentials, disabling sessions, and reducing privileges.
+4. Determine whether covered investor information or operational records were accessed, altered, or exposed.
+5. Record decisions, evidence, notices, vendor contacts, and recovery actions in the incident timeline.

onboarding/team-member-onboarding-agreement.md

@@ -0,0 +1,36 @@
+# Team Member Onboarding Agreement
+
+Draft v0
+
+
+
+## Confidentiality
+
+The team member agrees to protect non-public company information, including customer records, issuer records, investor records, credentials?, }}MNPI here
+
+The team member may use confidential information only for authorized company work and may not disclose it to any person, service, or system unless the disclosure is authorized and necessary for that work.
+
+## Customer and Regulated Data
+
+The team member must not copy, export, upload, share, or discuss customer sensitive regulated data outside ++approved company systems??.
+
+When sensitive data is needed for authorized work, the team member must use the minimum data necessary and follow applicable access, retention, and deletion instructions.
+uhm k lol
+
+## AI Tools
+
+The team member must not submit customer PII, investor records, issuer records, credentials, confidential regulated data, private keys, seed phrases, passwords, API keys, or other company secrets to AI tools, chatbots, browser extensions, IDE assistants, meeting assistants, document assistants, or similar services.
+^^ main bit
+
+
+
+## Account Security
+
+Setup from AccID here}}
+
+~~- Report lost devices, exposed credentials, suspicious access, or security concerns promptly.~~
+
+
+When access is no longer required, or when the company requests it, the team member must return or delete company materials, remove local copies, revoke shared access, and assist with offboarding.
+
+Confidentiality and data-protection obligations continue after access ends.

team.md

@@ -0,0 +1,11 @@
+# Team
+
+- John Wooten (`@JFWooten4`) -- todo make this a table like how we end up on the DUNA registry (some??) [AccID: BIYES3WTN]
+
+```mermaid
+flowchart TB
+    subgraph members["Team Members"]
+        direction LR
+        john["John Wooten"]
+    end
+```