diff --git a/engineering-standards.md b/engineering-standards.md new file mode 100644 index 0000000..b38ef92 --- /dev/null +++ b/engineering-standards.md @@ -0,0 +1,192 @@ +# Engineering Standards + +These are our opinionated engineering standards we use internally at Distrust, +and expect from all contractors and vendors. + +## Summary + +This process is recommended for any binaries, that if compromised, could result +in a loss of funds exceeding $1,000,000, which is the rough level where +incidents of violent coercion or deployments of expensive ($200k+ per Zerodium) +"zero-day" exploits have been seen in our industry. + +It is reasonable to expect any privileged general-purpose OS kernels, tools, +or binaries may, in some use cases, have access to memory that holds a high value +secrets. This makes such binaries and those that maintain them significant +targets for supply chain attacks by malicious adversaries, be it covert via a +0day of overt via violence. + +It is also reasonable to expect that a binary that runs on multiple engineer +workstations could have the power to deploy to production. + +This document seeks to largely mitigate all classes of supply chain attacks we +have seen deployed in the wild with high accountability build and release +processes and maintain a high standard of code quality and security. + +## Motivation + +80% of software bugs are memory safety issues, which speaks to poor coding +standards, and failure to use memory safe languages where possible. + +Also adversaries are demonstrating an increased willingness to resort to +supply chain attacks to gain value from software systems. + +Examples: +* [CI/CD system compromised by covert and sophisticated rootkit](https://igor-blue.github.io/2021/03/24/apt1.html) +* [NPM supply chain attack on CoPay wallets](https://medium.com/@hkparker/analysis-of-a-supply-chain-attack-2bd8fa8286ac) +* [Web analytics supply chain attack deployed on Gate.io exchange](https://www.welivesecurity.com/2018/11/06/supply-chain-attack-cryptocurrency-exchange-gate-io/) +* [0day in Firefox used to attack Coinbase](https://www.zdnet.com/article/firefox-zero-day-was-used-in-attack-against-coinbase-employees-not-its-users/) +* [Ruby Gem Supply chain attack to facilitate cryptoasset theft via clipboards](https://www.bleepingcomputer.com/news/security/malicious-rubygems-packages-used-in-cryptocurrency-supply-chain-attack/) + +Worse even than this, when such vectors are not readily viable, some are even +willing to resort to physical violence just to get a signature from a +the private key that can directly or indirectly control significant value. + +Examples: +* [Physical Bitcoin Attacks](https://github.com/jlopp/physical-bitcoin-attacks/blob/master/README.md) +* [Violent datacenter robbery with hostages](https://www.computerworld.com/article/2538534/data-center-robbery-leads-to-new-thinking-on-security.html) +* [History of datacenter break-ins](https://www.hostdime.com/blog/server-room-security-colocation/) + +Given this, we should expect that humans in control of any single point of +failure in a software ecosystem that controls a significant amount of +value are placing themselves at substantial personal risk. + +To address this, we must avoid trusting any single human or any system they +control by design in order to protect those individuals and downstream users. + +## Threat Model + +* Every human will make coding mistakes +* Any single human or computer involved in the supply chain is compromised +* All systems managed by a single party (IT, third parties) are compromised +* Any code or binaries controlled by one system or party are compromised +* All memory of all internet-connected computers is visible to an adversary +* Any logging or backups that are not signed are tampered with +* Adversary wields a "zero-click" "Zero-Day" exploit for any system + +## Requirements + +The following only applies if code is bound for production, and these can be +met in any order or cadence desired. + +* Third-party code: + * MUST have extensive and frequent reviews. + * Example: The Linux kernel has well funded distributed review. + * MUST be hash-pinned at known reviewed versions + * MUST be at version with all known related security patches + * SHOULD be latest versions if security disclosures lag behind releases + * Example: The Linux kernel +* First-party code: + * MUST be signed in version control systems by well-known author keys + * MUST be signed by a separate subject matter expert after a security review +* All code MUST build deterministically +* All binaries: + * MUST be built and signed by multiple parties with no management overlay + * Example: One build by IT, another by Infrastructure team managed CI/CD + * MUST be signed by well-known keys signed by a common CA + * Example: PGP Smartcards signed under OpenPGP-CA. +* All signing keys: + * MUST be stored in approved PERSONAL HSMs + * MUST NOT ever come in contact with network-accessible memory +* All execution environments SHOULD be able to verify m-of-n binary signatures + * Example: Custom Secure Boot verifies minimum signatures against CA +* Only code required for sensitive operation SHOULD be present + * Example: A server has no need for sound card drivers + + +## Workflows + +## Design + +Many implementations are possible under the above requirements and threat model +however, the following opinionated workflows can be used as a reference when in +doubt. + +### Engineer Workflow + +Will vary significantly by project, but at a minimum: + +1. Engineer makes source code change +2. Engineer builds and tests changes locally +3. Engineer makes commit signed with PERSONAL HSM and pushes +4. Submits code for peer review if multiple engineers are active in codebase + +### Continuous Integration + +This is ideal, though not always present for all projects. + +1. Pulls code +2. Verifies commit signature by key signed with hardcoded CA key +3. Builds binaries +4. Verifies binary hashes match hashes in signed commit +5. Runs test suite +6. Signs binary with a well-known key (ideally held in HSM) +7. Publishes binary and signature to artifact storage +8. Continuous Integration notifies project team of success/error of above steps + +### Security Reviewer + +1. Reviews all code changes between release candidate and last commit +2. Reviews all third-party changes and evidence they are appropriate +3. Appends tag signed with PERSONAL HSM to release candidate commit reviewed + +### Release Engineer + +1. Release engineer verifies: + * Commit signature and security reviewer signature on commit are valid + * The artifact corresponding to this commit is signed by the CI key + * The artifact hash is in the release candidate commit +2. Release engineer generates detached artifact signature with PERSONAL HSM +3. Release engineer publishes detached signature to artifact store + +## Guidelines + +### Boilerplate + + All projects should have: + - A README.md containing goals, requirements, and build/usage instructions + - A Makefile configured such that 'make' will build the project + - A Stagex Containerfile responsible for the building project deterministically + +### Dependency Choices + +Use the following rationale guidelines to help decide when and how to use third party dependencies + +```mermaid + flowchart TD + A[Can it be done with the standard Library in under ~10k easily readable lines?] + A --> D{No} --> E + A --> B{Yes} --> C + + E[Can it be done with a library used in the official interpreter or compiler?] + E --> F{Yes} --> X + E --> G{No} --> I + + I[Does a widely used, well vetted, well reviewed, and well maintained library with exist?] + I --> J{Yes} --> X + I --> K{No} --> L + + L[Is this a cryptography or security sensitive use case?] + L --> M{No} --> O + L --> N{Yes} --> P[Review by yourself and pay for reputable external security audit] --> X + + O[Does -any- suitible library exist small enough for you to review yourself?] + O --> Q{No} --> C + O --> R{Yes} --> S[Review by yourself and by a peer] --> X + + C[Write it yourself] + + X[Document rationale and use library at specific version we have reason to trust] +``` + +## Language Guidelines + +### Rust + +TBD + +## Glossary + +### MUST, MUST NOT, SHOULD, SHOULD NOT, MAY + +These keywords correspond to their IETF definitions per RFC2119