Security
Overview
Security focuses on preventing unauthorized access to your organization's systems, software, and data. While this requires contributions from the entire organization, platform engineers are typically responsibility for building secure practices in the following areas:
-
System Access: How your organization ensures that access to various systems is granted only when necessary. This includes establishing patterns for role-based access control, reducing the use of static credentials, keeping detail audit trails, and much more.
-
System Configuration: How your organization validates and approves system changes in order to align with compliance standards, prevent security lapses, and create awareness about the current state of the system.
-
Network Traffic: How you organization protects your networked infrastructure and in-transit data. This includes not only preventing malicious inbound traffic but also unintended egress of sensitive data.
-
Vendor Management: How you assess vendor security practices and manage their access to your systems and data. Often this involves ensuring that any vendor with sensitive access adheres to industry standard frameworks for system and organizational controls such as SOC 2.
-
Software Supply Chain: How your organization evaluates third-party code for vulnerabilities and exploits. As organizations increasingly rely on third-party code for the vast majority of their own software's functionality, this has become an increasingly important threat vector to build secure practices around.
-
Date Storage: How your organization ensures that persisted data cannot be exfiltrated by an attacker.
-
Physical Asset Management: How your organization ensures that physical assets such as office spaces or employer-provided hardware (e.g., laptops) are secured against unintended access, damage, theft, or other misuse.
While specific security practices will vary significantly depending on your organization's context, there are many best-practices that should apply to the vast majority of software companies. We provide that list below. 1
Importantly, great security practices should address the above threat vectors without negatively impacting the experience or performance of your organizational stakeholders.
Motivation
This pillar provides organizational value for the following reasons:
-
Prevents risks to business continuity:
- loss of ability to deliver business services (e.g., denial-of-service attacks)
- irrecoverable data loss (e.g., ransomware attacks)
- regulatory fines or injunctions
-
Prevents damage to public reputation and customer trust caused by security breaches
-
Improves development velocity by
- providing well-defined standards for the software-development lifecycle
- unifying system access controls (e.g., single sign-on)
- improving tooling for dependency management
-
Reduces loss of development velocity caused by
- remediation of security risks or incidents
- remediation of concerns during customer security evaluations
- internal consternation over insecure practices
-
Unlocks new customers and partnerships that require industry-standard certifications such as SOC 2, PCI DSS, HITRUST, etc.
-
Reduces costly cyber insurance premiums
Best Practices
This list is meant to serve as a starting point that covers fundamental security practices. Additional practices may be necessary depending on your organization's goals and context.
Category | Code | Goal |
---|---|---|
System Access | S.A.1 | Standard roles for role-based access control (RBAC) exist and all human access is provisioned via these roles. |
S.A.2 | All human access to all systems is controlled through a single root identity provider. | |
S.A.3 | All human access requires multi-factor authentication (MFA) using either TOTP or hardware tokens. | |
S.A.4 | All systems authenticate users via a single sign-on protocol (e.g., SAML, OIDC, etc.). | |
S.A.5 | All credentials used by humans to access systems in day-to-day operations are just-in-time provisioned and short-lived (< 8 hours). | |
S.A.6 | All static credentials are encrypted and centrally stored in a secure system with limited access. | |
S.A.7 | Service credentials are just-in-time provisioned and short-lived (< 8 hours) whenever possible. | |
S.A.8 | Service credentials are always bound to specific IP CIDR ranges. | |
S.A.9 | Static credentials are rotated at least once per quarter. | |
S.A.10 | Static credentials are rotated anytime anyone with access is off-boarded. | |
S.A.11 | Access logs from all systems are captured and stored within the observability platform. | |
S.A.12 | Access logs are immutable and stored indefinitely. | |
S.A.13 | Unusual log entries are automatically detected and trigger a notification. | |
S.A.14 | All servers run an active intrusion detection system (IDS). | |
S.A.15 | System access for a human user can be completely revoked within five minutes. | |
S.A.16 | Organization maintains formal process for requesting, documenting, and approving access control changes. | |
S.A.17 | All permissions are provisioned in a deny-by-default manner. | |
S.A.18 | User passwords require a minimum complexity and are automatically checked against public databases such as HaveIBeenPwned. | |
S.A.19 | Access to production systems and data occurs solely through automated means. | |
S.A.20 | Deployed containers do not run as root. | |
S.A.21 | Deployed containers drop all unnecessary linux capabilities. | |
S.A.22 | Deployed containers run with a read-only root file system. | |
S.A.23 | Deployed containers are provisioned with memory and storage size limits. | |
S.A.24 | Deployed containers run minimal base images such as distroless. | |
S.A.25 | Deployed containers and VMs are restarted at least once per week. | |
System Configuration | S.C.1 | Organization maintains formal process for requesting, documenting, and approving system configuration changes. |
S.C.2 | All configuration changes are logged immutably and stored indefinitely. | |
S.C.3 | Static code analysis is applied to application and infrastructure code changes. | |
S.C.4 | Drift from intended configuration is automatically detected and remediated. | |
S.C.5 | Code changes are cryptographically signed (e.g., git commit signing). | |
S.C.6 | Your organization maintains global deployment controls that are automatically enforced at time of deployment. | |
Network Traffic | S.N.1 | All network traffic is encrypted using a recent protocol with no known security vulnerabilities. |
S.N.2 | All internal network traffic uses mutual TLS with certificates rotated at least once per quarter. | |
S.N.3 | All inbound network application traffic undergoes analysis via a web application firewall (WAF) that identifies and prevents common attacks (e.g., SQL injection). | |
S.N.4 | All inbound network application traffic passes through interfaces capable of DOS mitigation. | |
S.N.5 | All inbound network application traffic generates logs that records standard information about the client (e.g., IP address, user agent, etc.). | |
S.N.6 | Inter-service communication must be explicitly allowed on a per-service basis (denied-by-default). | |
S.N.7 | Egress traffic must have destinations explicitly allowed on a per-service basis (denied-by-default). | |
S.N.8 | The majority of workloads run in private subnets and access the public internet via NAT with static IP addresses. | |
S.N.9 | Databases are not exposed directly via a public IP address. | |
S.N.10 | IP allowlists are not used as the sole security measure for internal services. | |
S.N.11 | Public DNS records use DNSSEC. | |
S.N.12 | Network traffic denied by firewall policies should be logged in the observability platform and trigger an alert. | |
S.N.13 | Public HTTP traffic configures secure headers. | |
S.N.14 | Public HTTP traffic removes headers that enable attacker surveillance (e.g., X-Powered-By ). | |
S.N.15 | HTTP cookies are always configured to be HTTPOnly and Secure . | |
Vendor Management | S.V.1 | Your organization maintains a central location for tracking information about all software vendors. |
S.V.2 | Your organization maintains a standard security questionnaire that is used to assess each vendor's security posture. | |
S.V.3 | Your organization reviews each security questionnaire annually and identifies any potential security risks. | |
S.V.4 | Your organization maintains a copy of each vendor's compliance certifications and internal process documents. | |
S.V.5 | Your organization maintains a concrete list of all of the types of sensitive data each vendor stores or has access to. | |
S.V.6 | When necessary, each vendor receives unique, dedicated credentials. | |
S.V.7 | Your organization maintains a migration plan should you need to rapidly remove any individual vendor. | |
S.V.8 | Your organization maintains a "one strike" policy should a vendor be found to misrepresent their security posture. | |
S.V.8 | Your organization obtains source code for all products hosted on your infrastructure. | |
Software Supply Chain | S.S.1 | All third-party dependencies are automatically checked for reported vulnerabilities. |
S.S.2 | All build artifacts are automatically scanned for known vulnerabilities. | |
S.S.3 | All third-party software is automatically updated with the latest patch and minor versions. | |
S.S.4 | Your organization maintains a SBOM for each first-party software project. | |
S.S.5 | All third-party software is installed via a specific, globally unique hash or checksum. | |
S.S.6 | No third-party software can be updated without a specific record of the version change. | |
S.S.7 | Third-party software is deployed following the principle of least privilege. | |
S.S.8 | Third-party dependencies are pulled from a self-hosted artifact cache rather than directly from public endpoints. | |
S.S.9 | Your organization immediately remediates significant vulnerabilities found in third-party dependencies. | |
S.S.10 | Your organization does not run unsupported software that no longer receives security patches. | |
Data Storage | S.D.1 | All data is stored encrypted-at-rest using AES256 or stronger encryption. |
S.D.2 | Data encryption keys are rotated at least quarterly. | |
S.D.3 | Production data never leaves production-hardened systems. | |
S.D.4 | Logs and other observability data are automatically sanitized of sensitive data or PII. | |
S.D.5 | Your organization maintains a record of all types of personally identifiable information for your users, what systems store it, and who has access. | |
S.D.6 | You maintain offline data backups that could be used to restore your entire production environment from scratch. | |
S.D.7 | Direct, manual, production data access is recorded in an audit log at the granularity of individual queries / files. | |
Physical Access Management | S.P.1 | All facilities are protected via electronic access control connected to the central identity provider. |
S.P.2 | All employer-issued devices have MDM software installed. | |
S.P.3 | All user devices with access to production systems have standard protections such as vulnerability scanners, remote wiping capabilities, and encryption-at-rest. | |
S.P.4 | All on-premise user networks are protected via user-unique identities connected to the central identity provider. | |
S.P.5 | Your organization maintains an audit log of all facility access, both physical and network connections. | |
S.P.6 | On-premise servers are protected by a second-layer of physical access control. |
Footnotes
-
This primarily list focuses on the technical goals. For organization and process goals related to security, see the Coordination Pillar. ↩