diff --git a/_category_ copy.json b/_category_ copy.json new file mode 100644 index 0000000..1756f65 --- /dev/null +++ b/_category_ copy.json @@ -0,0 +1,6 @@ +{ + "label": "operationss-ish" +} +commti combining finincails with taxes + +onbeanigng beta to legacy static \ No newline at end of file diff --git a/_category_.json b/_category_.json new file mode 100644 index 0000000..ea39e4f --- /dev/null +++ b/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Compliance Manual" +} +not forall \ No newline at end of file diff --git a/imgs/logo.png b/imgs/logo.png new file mode 100644 index 0000000..399326f Binary files /dev/null and b/imgs/logo.png differ diff --git a/imgs/logo.svg b/imgs/logo.svg new file mode 100644 index 0000000..9d26690 --- /dev/null +++ b/imgs/logo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/incidents/README.md b/incidents/README.md index 31978f5..fd3727d 100644 --- a/incidents/README.md +++ b/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. diff --git a/incidents/SECTIONS.md b/incidents/SECTIONS.md new file mode 100644 index 0000000..4aba040 --- /dev/null +++ b/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) diff --git a/incidents/_category_.json b/incidents/_category_.json new file mode 100644 index 0000000..5ad9a7d --- /dev/null +++ b/incidents/_category_.json @@ -0,0 +1,3 @@ +{ + "label": "Compliance Manual" +} diff --git a/incidents/attack-surface-map.md b/incidents/attack-surface-map.md new file mode 100644 index 0000000..6e2267f --- /dev/null +++ b/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. diff --git a/onboarding/team-member-onboarding-agreement.md b/onboarding/team-member-onboarding-agreement.md new file mode 100644 index 0000000..09a8ee8 --- /dev/null +++ b/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. diff --git a/team.md b/team.md new file mode 100644 index 0000000..2fe33e9 --- /dev/null +++ b/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 +``` diff --git a/values.md b/values.md new file mode 100644 index 0000000..d58fcfd --- /dev/null +++ b/values.md @@ -0,0 +1,171 @@ +# Values + +## Flawless is Acceptable + +Although most companies rightfully move fast, we take our time given our work's +implications. Founded by investors for investors, we fix monopolistic Wall +Street theft. As a public utility, we will transition to a nonprofit once TAD3 +matures. + +> Give me six hours to chop down a tree and I will spend the first four +> sharpening the axe. +> +> — Abraham Lincoln + +DRS adoption is a serious challenge with material implications. These are the +principles we use to make TAD3 worth trusting. + +- Benefit investors before extracting margin. +- Stretch issuer dollars further than legacy intermediaries. +- Operate compliance-first with transparent controls. +- Make quality equity access more global and less exclusionary. + +## 1: Benefit Investors {#benefit-investors} + +In every step we take, the prosperity of our investors remains our guiding star. + +We're not just accounting for investments; we're nurturing retirements, +ambitions, and futures. + +We prioritize the welfare of our investors above our own profit margins, to +create value for you. + +When it comes to the choice to charge a fee or not, our stance is clear: we opt +for free. Ensuring efficiency for our investors is paramount. + +At the heart of Block Transfer lies a steadfast commitment: our investors always +come first. Every decision we make and every path we tread is aligned with the +best interests of our investors. + +When it comes to fees, we believe less is more. Every penny counts, and over +time even small savings compound into a significant difference for investor +portfolios. + +We advocate for clear, open communication from our clients, empowering the +investing community to make informed decisions through transparent corporate +activity. + +We're in the business of nurturing small businesses, fueling economic growth, +and helping established companies soar to new heights. + +Every company deserves the chance to raise capital to its fullest potential. We +designed TAD3 to connect issuers with a pool of interested, qualified investors +while removing traditional barriers. + +We reject percent-based fees for originations and avoid per-transaction fees at +all costs. Instead, we spread account service costs across clients because +onboarding and maintenance are approximately fixed per investor. + +In our pursuit of efficiency, we've adopted electronic notice systems. This +minimizes polluting physical mail, reduces bills, removes large intermediaries, +and improves operational efficiency. + +## 2: Benefit Companies {#benefit-companies} + +We stretch your dollar further than traditional brokers, custodians, or other +centralized financial systems with inherent conflicts of interest. + +We spread out TAD3 costs so that emerging businesses can focus on what they do +best: innovate. + +## 3: Compliance First {#compliance-first} + +We actively engage with regulators to ensure our policies not only meet but +exceed the standards set for legacy intermediaries. + +We believe in operating with transparency and integrity. + +TAD3 respects the past, embraces the present, and looks forward to a more +transparent, efficient, and compliant financial future. + +Incumbent systems, though once efficient, rely on dark central securities +depositories born from legacy technological constraints. We move beyond that +with a direct and efficient capital market. + +Securities regulations traditionally focus on intermediated ownership. Direct +transactions between investors have always been less governed. We view this not +as a loophole, but as a realm of responsibility. + +Our internal policies don't just follow the letter of the law, but its true +spirit. We're dedicated to understanding and aligning with the intent behind the +international laws governing legacy capital-market firms. + +## 4: Global Impact {#global-impact} + +We're committed to tearing down the barriers that prevent people from accessing +valuable compounding equities. + +Socioeconomic status should not prevent you from investing. + +Billions of people around the world are deprived of access to quality equity +investments, trapping them in cyclical generational poverty. + +We strive to make TAD3 accessible to anyone while adhering to monetary laws. We +believe that widespread prosperity can bring peace, stability, and more +responsible capitalism. + +We understand that investing costs can be a major hurdle. Our services should +not be reserved for the privileged few, but be accessible regardless of +financial background. + +We embrace the challenge of building robust global infrastructure with localized +rails so the platform is not just universally accessible, but genuinely relevant +to unique users. + +## 5: Collective Wisdom {#collective-wisdom} + +In the vast expanse of financial innovation and market dynamics, no single +entity can claim to possess all knowledge or perspectives. + +TAD3 pioneers a path for capital formation that benefits everyone. + +Our approach to growth is deeply rooted in listening, really listening, to the +feedback we receive, because we don't have all the answers. + +We believe that the collective wisdom of the masses is a powerful tool. Feedback +from seasoned investors, curious newcomers, and skeptical observers all matter. + +We're charting new courses in finance with a clear understanding that this +journey does not belong to us alone. Make your voice heard. + +By tapping into diverse thoughts, experiences, and insights, we ensure that our +systems and services stay connected to real needs and remain truly by investors, +for investors. + +## 6: Trustless Trust {#trustless-trust} + +Our operations are under the vigilant eye of the Securities and Exchange +Commission within a framework designed to protect you. + +Trust in TAD3 is inherent with every transaction, not imposed. + +Our systems are fortified with advanced security measures to protect personal +data. We do not profit from or share identity information, preferring to let +TAD3 present an unbiased selection of investments. + +While embracing the decentralized nature of blockchain, we recognize the +necessity of certain transparent controls. These tools protect users and +preserve platform integrity. + +As a Delaware company, we have the autonomy to accept or reject clients. That +freedom carries a responsibility to be discerning, and accepting a new client is +not an endorsement of their business practices or ethics. + +## 7: Extreme Security {#extreme-security} + +We've adapted our security measures to the digital realm, ensuring the highest +level of protection for our clients' assets. + +We respect and maintain the autonomy of our investors. + +We never ask for your seed phrase, the private key that controls digital assets, +and we do not deal with insecure physical certificates. + +Where limited central control exists, our systems follow the principle of least +privilege necessary. + +For particularly sensitive items, we rely on cold hardware wallets not connected +to the internet. + +When given access to sensitive wallets, team members must pass FBI background +checks.