InfoSec Service Level Requirements

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

This Service-Level Agreement (SLA) is between the cyber security team and the management of Savvi to meet Savvi’s Service-Level Requirements (SLR).

This SLA/SLR is modeled after the SANS SLA White Paper. See https://sansorg.egnyte.com/dl/ROZN7Fbvrb and https://www.soscanhelp.com/blog/what-is-a-service-level-agreement.

References

The internal roadmap for bringing legacy processes and systems into compliance with these policies can be found at https://github.com/paperos-labs/security-policy.

Proactive Security

tags: inf_sec_awareness_training

Our stance is primarily proactive rather than reactive. We aim to identify and prevent root causes of vulnerability.

This includes

• Relying on constant, real-time vulnerability scanning over delayed schedules
• Using a constant, real-time network scanning and logging security gateway
• Reducing the number of applications and services necessary to perform core tasks
• Working with all employees to find simpler, more secure software alternatives
• Working with the dev team to reduce the number of dependencies in our supply chain
• Providing regularly scheduled training
• Updating training materials at the time deficiencies are identified
• Scheduling regular software updates

The primary goal of focusing on proactive security is to reduce the likelihood of risk that necessitates the use of intrusive (and potentially expensive) tools and services that “lock down” computers and devices, often making them slower, forcing reboots at inconvenient times, and generally getting in the way of productivity, comfort, and convenience.

Network Topology & Documentation

The network topology is automatically maintained by the Ubiquiti Dream Machine and can be viewed by any admin.

Each of the following is directly connected to the Dream Machine (Security Gateway):

• PoE WiFi Access Point (AP)
• PoE Cameras
• Unmanaged switches

The Dream Machine’s console UI, available at https://unifi.ui.com, shows which devices are directly connected on each port, and each client device (endpoint) is connected to the Dream Machine itself, AP, or switch.

This documentation should be updated as part of any network topology change.

Customer Data Backups

We take a full-system snapshot every hour. Snapshots cover the database, email logs, API transaction logs and customer files.

Snapshots are kept on a layered schedule: the latest 3 snapshots, 25 hourly, 8 daily, 6 weekly and 4 monthly. This gives restore points going back about four months.

Snapshots are sent to three backup sites, in San Francisco, Salt Lake City and Provo, Utah. The Provo site is scheduled to move to Richmond, Virginia later in 2026.

Retention is controlled by the backup sites, not by production. A compromised production system cannot delete snapshots or shorten their history.

We also take atomic database backups twice a day and pull them offsite to a separate provider in a separate region. Weekly database archives are kept as well, and currently go back to 2022.

Backup access is isolated from production. Database backups are pulled from production, and the backup sites decide when snapshots are deleted. This is designed so that ransomware or a compromised account cannot destroy backups.

Customer files are kept in two places: on PaperOS-operated document storage and in Box.

Vulnerability Scanning & Management

tags: inf_sec_vulnerability_management

Employee & Contractor Devices

All devices - whether personal or business - must employ continuous, real-time vulnerability scanning - such as XProtect, Windows Defender, and AppArmor, as well as automated vulnerability reporting provided by App Store, System Update, and Windows Update.

Network Scanning

As described in the General Employee Security Policy, the network is constantly scanned in real-time for threats. All traffic is analyzed and logged. See General Employee Security Policy.

Only audited devices will be allowed on the internal network. If a device is detected as a threat it will be disabled.

Node.js Dependency / Supply Chain Management  

We use Socket.dev, which covers a broad range of checks (see https://socket.dev/npm/issue) to help protect against supply chain attacks.

Dependencies should be limited and packages with a large number of transitive dependencies should be avoided.

Ubuntu Linux VM/VPS Management

Security updates should be applied automatically via unattended-upgrades, which should be installed and running by default (or sudo apt install unattended-upgrades if not).

VPSes should be treated as standalone applications that do not require system-level facilities to perform their function. If a system-level dependency is necessary, that functionality should be split off into its own service.

Tools should be installed from static builds where possible, rather than bringing in system-level dependencies.

Implementation: Our application does not require any C libraries to run. We install Node in a user folder and run without sudo. Updates to Node are part of our deployment process.

Incident Response

tags: inf_sec_incident_management, inf_sec_awareness_training

When vulnerabilities are reported, they will be assessed to determine the severity, urgency, and assigned a time window to be patched within 72 hours of the report.

The assessment may consider factors such as

• MTTD (mean time to detect/discover)
• MTTE (mean time to exploit)
• MTTR (mean time to resolve/repair)

If it is determined that further research, auditing, and/or logging is necessary to resolve the issue, it will be conducted as needed.

High-to-Medium risk incidents that can be solved by non-breaking software patches shall be fixed within 72 hours. Incidents that require custom workarounds or breaking changes that require testing and adjustment will be assessed and an estimate given within 72 hours.

Low risk incidents may or may not be addressed.

Viruses: Detection

If a virus has made its way to one of an employee’s devices, this is treated as a gap in security training.

The event will be investigated to determine the method of transmission (e.g., email, USB drive, etc.), and the appropriate training will be updated if necessary, and reviewed with the employee.

As appropriate, broader training or notice may be made.

Depending on the circumstances, it may be necessary to presume that the computer has been infected and execute the appropriate policy.

Viruses: Infection

In the event of infection, the policy for detection shall be executed.

Additionally:

1. Shut down the computer (except for ransomware)
2. Create a full backup, if necessary
3. Wipe & restore to factory settings

If the virus includes a keylogger or otherwise may have gained access to credentials or sensitive information, the relevant policies shall also be executed.