Savvi Technologies, Inc. Updated 2023-01-11
Edit this page at https://github.com/savvi-legal/security-policy/blob/main/infosec-policy.md.
tags: inf_sec_hosting, inf_sec_governance
We strive to meet all applicable standards and regulations in relation to HIPAA, SOC 2 and PCI-DSS, and generally protect the PII of our customers. We begrudgingly do the bare minimum to satisfy virus-like overreaching fascist regimes that put forth ineffective security theatre at the expense of the flesh-and-blood human customer experience, such as for GDPR.
tags: inf_sec_awareness_training, inf_sec_vendor_management
Trainings are scheduled annually during the first quarter (Q1).
tags: inf_sec_encrypt_in_transit
All HTTP, web, and API services must reject vulnerable versions and algorithms of SSL and TLS and must only support known-secure versions and algorithms.
Implementation: caddy is used to ensure that connections are always encrypted, certificates are always valid, and insecure TLS algorithms are rejected. Currently TLS 1.2 and 1.3 are supported.
tags: inf_sec_access_authentication
We enable two-factor authentication where available. We only use production services that offer two-factor authentication.
We use the following methods where available:
Our stance is that passwords are fundamentally broken and that the primary factor of security is a high-entropy WebAuthn-compliant Security Key (not an Authenticator).
We assume that all user-chosen passwords are inherently insecure and do not count as active security measures.
All employees shall use a password manager.
Passwords are not to be duplicated between accounts.
Shared accounts that rely on password sharing shall be rotated yearly after the first general security training of the year, before the end of Q1.
As per the General Employee Security Policy, all devices (endpoints) are audited prior to being connected to the company network and all traffic is logged and monitored (e.g. domain names, ip addresses, devices, etc).
Devices are secured by individual building access codes and video recording.
Device Audit
All devices shall either be shut down each Friday, or rebooted Monday morning to allow system updates to run.
Employee and contractor devices are required to be secured from malicious code (such as by XProtect, Windows Defender, AppArmor).
See General Employee Security Policy: Device Policy.
Tags: inf_sec_malicious_code
All device and software purchases, such as Laptops, Phones, and Drives from Amazon, eBay, and Facebook Marketplace shall be inspected to ensure that they are sealed from the original manufacturer.
Any used devices shall be wiped and reset to factory defaults before use to protect against Out-of-Box-Experience hacks. See https://www.appletech752.com/blog.html.
Devices that do not function normally shall be inspected for physical tampering. See https://www.securityweek.com/mobile-devices-exposed-spying-malicious-batteries-researchers and https://www.theverge.com/2019/4/17/18412427/college-saint-rose-student-guilty-usb-killer-destroyed-computers.
All devices and software are audited upon receipt to ensure that they comply with our Device and Asset Management policies.
Presently only our network security gateway (as part of IDS) and video surveillance are On-Prem.
Rationale: We don’t have a reliable source of electrical power or Internet
connectivity.
Due to the age of the building, we occasionally experience the breakers tripping
when someone runs a microwave and heater at the same time. Due to the nature of a
shared network, we regularly experience connectivity issues.
We do not currently use colocation services.
We may explore this option in the future with XMission or a similar co-location center.
tags: inf_sec_encrypt_at_rest, inf_sec_network_segmentation
Production service providers must be SOC (2 or 3) and PCI-DSS compliant. They must be independently audited.
Implementation: Digital Ocean lists its compliance levels and its auditors at https://www.digitalocean.com/trust/certification-reports (see also https://www.digitalocean.com/trust).
Production accounts shall be entirely separate from development accounts.
The degree of separation between accounts is to be the same as if they were two separate companies signing up for individual accounts.
Implementation: We use Digital Ocean for VPSes. They have both “Projects” and “Teams” features for isolating resources. Although it’s common to have Development and Production “Projects”, we instead maintain separate Team accounts for Savvi Production and Savvi Development with their own billing information and access controls, entirely separate - no shared tokens, permissions, passwords, etc. https://www.digitalocean.com/products/teams
Production access should be logged per each administrator.
Implementation: On development systems we may share credentials to easily access logs and perform debugging. On production systems each developer and admin have their own credentials.
Credentials, configuration, and user data shall be on encrypted volumes, perhaps apart from application code.
The practical concern here, aside from “because compliance”, is to protect against physical theft of drives at the data center and against adjacent containerized applications being able to read a newly allocated volume and discover secrets - because when we release the container or volume the next container or volume to be created on the service may reuse the same physical bits of storage. If unencrypted, a read of the “empty” drive’s blocks would reveal the data they contain. See https://github.com/fog/fog/issues/2525 and https://unix.stackexchange.com/q/642880/45554.
On local computers it would be required that some user authentication is taken on physical reboot, but this is not a concern in cloud environments since 1) it’s imperative that the container reboot into a working state and 2) the access is virtual, not physical, and many of the higher-level controls are already in the hands of the service provider.
Example: Digital Ocean VPS boot volumes are not encrypted-at-rest. However, block storage volumes are encrypted-at-rest. We can store our application code and binaries on the default volume, but all customer data and configuration must be stored on an encrypted volume. It would also be acceptable to use a “vault”-like feature that only needs a single token stored on the default volume to access the encrypted-at-rest data on another volume or service.
“Encryption: Volumes are encrypted using the LUKS (Linux Unified Key Setup) specification. The entire storage cluster is encrypted, which ensures that snapshots of volumes are also encrypted at rest.” - https://www.digitalocean.com/docs/volumes/overview/
See also https://www.digitalocean.com/products/block-storage.
Development and production should be done with LTS and LTS candidate operating systems, software, and frameworks.
Exceptions shall be approved by the development team and documented at https://github.com/savvi-legal/security-policy
Example: Node v18 provided some new features that were significant improvements over Node v16 LTS. It was not yet in the LTS phase when we started using it in development, but it was always an LTS candidate. We never used Node v17, even though it included many of those features, because it was not an LTS candidate. We use Ubuntu 22.04 and 20.04, but not 18.04 as it will not .
All systems, platforms, and frameworks should be updated to the next major version before reaching end-of-life for security updates.
Exceptions for work that is “complete” (and unlikely to be affected by security updates) shall be approved by the development team and documented at https://github.com/savvi-legal/security-policy
tags: inf_sec_access_governance, inf_sec_change_governance,
inf_sec_change_testing, inf_sec_change_code_reviews, inf_sec_audit_trail
In order for assets (such as workflows, front end code, APIs) to be deployed to production environments, it must go through the following process:
For the sake of expediency, some hotfixes that cannot be applied cleanly to the staging environment may need to go through an altered QA process and use pre-release versioning. PRs are always required.and version tag step.
tags: inf_sec_monitoring_alerting
Production credentials are only stored on encrypted-at-rest devices and are only accessible through individual, auditable logins.
Potentially leaked credentials are monitored in real-time by GitHub Secret Scanning as well as Socket.dev’s leaked secret detection. See https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning and https://socket.dev/npm/issue.
tags: client_2fa
We do not currently enforce 2fa.
tags: inf_sec_independent_testing
We have not yet been independently audited, nor undergone penetration testing.
We do not yet have a schedule for audits and pen tests.
tags: privacy_consumer_consent, privacy_data_minimization,
privacy_data_usage
We have a Privacy Policy and Terms of Use describing our collection, processing, and storing of customer data.
Most of the data we collect is by the user explicitly giving it to us. Some data, such as IP address and device type are collected for auditing or logging purposes and are also collected with consent.
Due to the nature of the workflow system, we only collect the information that is necessary for the current actions of the user.
Users must contact support to request data removal and fully delete their account and data. This does not include signed agreements, which are stored for future reference of any involved party. Nor does this include data that is used for logs and auditing - such as login times and devices.
Some data is shared through common analytics tools, such as Google Analytics and Sentry, but we DO NOT sell customer data.
Edit this page at https://github.com/savvi-legal/security-policy/blob/main/infosec-policy.md.