Information Security Policy (ISP)

Savvi Technologies, Inc., dba PaperOS. Updated 2023-01-11

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. For privacy regulations such as GDPR, we implement the controls required where they apply to our services, while keeping the customer experience simple.

Scheduled Trainings & Internal Audits

tags: inf_sec_awareness_training, inf_sec_vendor_management

Trainings are scheduled annually during the first quarter (Q1).

The items below are internal to PaperOS. They are not independent third-party audits. See Independent Auditing and Testing.

• General Employee Security Policy (Document: General Employee Security Policy)
• Shared Password Rotation (Section: Credential Management)
• End-of-Life Device Audit
• Removed Devices Audit
• Weekly system updates policy

General Security

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 require that connections are encrypted, to keep certificates valid, and to reject insecure TLS algorithms. Currently TLS 1.2 and 1.3 are supported.

Employee Credentials

tags: inf_sec_access_authentication

Two-Factor Authentication

We enable two-factor authentication where available. We only use production services that offer two-factor authentication.

This section applies to employee accounts. Customer account authentication is described in Customer Authentication.

We use the following methods where available:

• “Security Keys” (WebAuthn)
• Apple TouchID
• Windows Hello
• Yubico FIDO2 (or latest standard) USB devices
• “Authenticators” (RFC 6238, RFC 4226)
• Authy
• Okta

Credential Management

Our approach is to treat passwords alone as a weak security measure and to prefer a high-entropy WebAuthn-compliant Security Key (not an Authenticator) as the primary factor of security.

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.

Asset Management

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

• Is the device rooted? (self-reported)
• Are automatic updates turned on (and current)?
• Is the device still in the security update schedule (not end-of-life)?
• What is the purpose for connecting the device (work, convenience, etc)?

All devices shall either be shut down each Friday, or rebooted Monday morning to allow system updates to run.

Malicious Code

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

Asset Intake

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.

Devices that do not function normally shall be inspected for physical tampering.

All devices and software are audited upon receipt to ensure that they comply with our Device and Asset Management policies.

Servers and Services

On-Prem Services

Presently only our network security gateway (as part of IDS) and video surveillance are On-Prem. Production services are not hosted on-premises (see Cloud Hosting).

Rationale: We don’t have a reliable source of electrical power or Internet connectivity at our office.
Due to the age of the building, we occasionally experience power interruptions. Due to the nature of a shared network, we regularly experience connectivity issues.

Co-located Servers

We do not currently use colocation services.

Cloud Hosting

tags: inf_sec_encrypt_at_rest, inf_sec_network_segmentation

1. Production service providers must be SOC (2 or 3) and PCI-DSS compliant. They must be independently audited. This requirement applies to our service providers. For PaperOS’s own audit status, see Independent Auditing and Testing.

   Implementation: DigitalOcean lists its compliance levels and its auditors at https://www.digitalocean.com/trust/certification-reports (see also https://www.digitalocean.com/trust).

2. 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 DigitalOcean 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 production and development with their own billing information and access controls, entirely separate - no shared tokens, permissions, passwords, etc. https://www.digitalocean.com/products/teams

3. 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.

4. Credentials, configuration, and user data shall be on encrypted volumes, which may be separate from application code.

   The practical concern here, aside from compliance requirements, 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: DigitalOcean 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.

   DigitalOcean documents that its Volumes (block storage) are encrypted with LUKS, that the storage cluster is encrypted at rest, and that snapshots inherit this encryption. See https://docs.digitalocean.com/products/volumes/details/features/.

   See also https://www.digitalocean.com/products/block-storage.

5. 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/paperos-labs/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.

6. 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/paperos-labs/security-policy

Production Deployment

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, they must go through the following process:

• Static analysis (linting, error checking, code style formatting)
• PR. All changes require a code change audit trail.
• Staging deployment for QA to test code changes
• Code review (currently implemented through GitHub Branch Protection)
• Version tag

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, as is the version tag step.

Production Credentials

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 automatically 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.

Customer Authentication

tags: client_2fa

We do not currently enforce 2fa.

Independent Auditing and Testing

tags: inf_sec_independent_testing

We have not yet been independently audited, nor undergone penetration testing.

We do not yet have a schedule for independent audits or penetration tests.

Customer Consent to Data Collection

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, in addition to the audit, logging, and analytics data described in this section.

Users must contact support (support@paperos.com) to request data removal and delete their account and data, subject to the exceptions below. 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.