Panfactum LogoPanfactum
PillarsSecurity

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.

CategoryCodeGoal
System AccessS.A.1Standard roles for role-based access control (RBAC) exist and all human access is provisioned via these roles.
S.A.2All human access to all systems is controlled through a single root identity provider.
S.A.3All human access requires multi-factor authentication (MFA) using either TOTP or hardware tokens.
S.A.4All systems authenticate users via a single sign-on protocol (e.g., SAML, OIDC, etc.).
S.A.5All credentials used by humans to access systems in day-to-day operations are just-in-time provisioned and short-lived (< 8 hours).
S.A.6All static credentials are encrypted and centrally stored in a secure system with limited access.
S.A.7Service credentials are just-in-time provisioned and short-lived (< 8 hours) whenever possible.
S.A.8Service credentials are always bound to specific IP CIDR ranges.
S.A.9Static credentials are rotated at least once per quarter.
S.A.10Static credentials are rotated anytime anyone with access is off-boarded.
S.A.11Access logs from all systems are captured and stored within the observability platform.
S.A.12Access logs are immutable and stored indefinitely.
S.A.13Unusual log entries are automatically detected and trigger a notification.
S.A.14All servers run an active intrusion detection system (IDS).
S.A.15System access for a human user can be completely revoked within five minutes.
S.A.16Organization maintains formal process for requesting, documenting, and approving access control changes.
S.A.17All permissions are provisioned in a deny-by-default manner.
S.A.18User passwords require a minimum complexity and are automatically checked against public databases such as HaveIBeenPwned.
S.A.19Access to production systems and data occurs solely through automated means.
S.A.20Deployed containers do not run as root.
S.A.21Deployed containers drop all unnecessary linux capabilities.
S.A.22Deployed containers run with a read-only root file system.
S.A.23Deployed containers are provisioned with memory and storage size limits.
S.A.24Deployed containers run minimal base images such as distroless.
S.A.25Deployed containers and VMs are restarted at least once per week.
System ConfigurationS.C.1Organization maintains formal process for requesting, documenting, and approving system configuration changes.
S.C.2All configuration changes are logged immutably and stored indefinitely.
S.C.3Static code analysis is applied to application and infrastructure code changes.
S.C.4Drift from intended configuration is automatically detected and remediated.
S.C.5Code changes are cryptographically signed (e.g., git commit signing).
S.C.6Your organization maintains global deployment controls that are automatically enforced at time of deployment.
Network TrafficS.N.1All network traffic is encrypted using a recent protocol with no known security vulnerabilities.
S.N.2All internal network traffic uses mutual TLS with certificates rotated at least once per quarter.
S.N.3All inbound network application traffic undergoes analysis via a web application firewall (WAF) that identifies and prevents common attacks (e.g., SQL injection).
S.N.4All inbound network application traffic passes through interfaces capable of DOS mitigation.
S.N.5All inbound network application traffic generates logs that records standard information about the client (e.g., IP address, user agent, etc.).
S.N.6Inter-service communication must be explicitly allowed on a per-service basis (denied-by-default).
S.N.7Egress traffic must have destinations explicitly allowed on a per-service basis (denied-by-default).
S.N.8The majority of workloads run in private subnets and access the public internet via NAT with static IP addresses.
S.N.9Databases are not exposed directly via a public IP address.
S.N.10IP allowlists are not used as the sole security measure for internal services.
S.N.11Public DNS records use DNSSEC.
S.N.12Network traffic denied by firewall policies should be logged in the observability platform and trigger an alert.
S.N.13Public HTTP traffic configures secure headers.
S.N.14Public HTTP traffic removes headers that enable attacker surveillance (e.g., X-Powered-By).
S.N.15HTTP cookies are always configured to be HTTPOnly and Secure.
Vendor ManagementS.V.1Your organization maintains a central location for tracking information about all software vendors.
S.V.2Your organization maintains a standard security questionnaire that is used to assess each vendor's security posture.
S.V.3Your organization reviews each security questionnaire annually and identifies any potential security risks.
S.V.4Your organization maintains a copy of each vendor's compliance certifications and internal process documents.
S.V.5Your organization maintains a concrete list of all of the types of sensitive data each vendor stores or has access to.
S.V.6When necessary, each vendor receives unique, dedicated credentials.
S.V.7Your organization maintains a migration plan should you need to rapidly remove any individual vendor.
S.V.8Your organization maintains a "one strike" policy should a vendor be found to misrepresent their security posture.
S.V.8Your organization obtains source code for all products hosted on your infrastructure.
Software Supply ChainS.S.1All third-party dependencies are automatically checked for reported vulnerabilities.
S.S.2All build artifacts are automatically scanned for known vulnerabilities.
S.S.3All third-party software is automatically updated with the latest patch and minor versions.
S.S.4Your organization maintains a SBOM for each first-party software project.
S.S.5All third-party software is installed via a specific, globally unique hash or checksum.
S.S.6No third-party software can be updated without a specific record of the version change.
S.S.7Third-party software is deployed following the principle of least privilege.
S.S.8Third-party dependencies are pulled from a self-hosted artifact cache rather than directly from public endpoints.
S.S.9Your organization immediately remediates significant vulnerabilities found in third-party dependencies.
S.S.10Your organization does not run unsupported software that no longer receives security patches.
Data StorageS.D.1All data is stored encrypted-at-rest using AES256 or stronger encryption.
S.D.2Data encryption keys are rotated at least quarterly.
S.D.3Production data never leaves production-hardened systems.
S.D.4Logs and other observability data are automatically sanitized of sensitive data or PII.
S.D.5Your organization maintains a record of all types of personally identifiable information for your users, what systems store it, and who has access.
S.D.6You maintain offline data backups that could be used to restore your entire production environment from scratch.
S.D.7Direct, manual, production data access is recorded in an audit log at the granularity of individual queries / files.
Physical Access ManagementS.P.1All facilities are protected via electronic access control connected to the central identity provider.
S.P.2All employer-issued devices have MDM software installed.
S.P.3All user devices with access to production systems have standard protections such as vulnerability scanners, remote wiping capabilities, and encryption-at-rest.
S.P.4All on-premise user networks are protected via user-unique identities connected to the central identity provider.
S.P.5Your organization maintains an audit log of all facility access, both physical and network connections.
S.P.6On-premise servers are protected by a second-layer of physical access control.

Footnotes

  1. This primarily list focuses on the technical goals. For organization and process goals related to security, see the Coordination Pillar.