Savvi Technologies, Inc. Updated 2023-01-11
Edit this page at https://github.com/savvi-legal/security-policy/blob/main/infosec-slr.md.
This Service-Level Agreement (SLA) is between the cyber security team and the management of Savvi to meet Savvis 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.
The internal roadmap for bringing legacy processes and systems into compliance with these policies can be found at https://github.com/savvi-legal/security-policy.
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
The primary goal is focusing on proactive security is to reduce the likelihood of risk that necessitates the use 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.
The network topology is automatically maintained by the Ubiquiti Dream Machine and can be viewed by any admin.
Each of the following are directly connected to the Dream Machine (Security Gateway):
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.
Our database is backed up every 8 hours, controlled by the backup server.
A copy of the backup is stored on either app1 or app2, as well as the backup server.
Backups older than 45 days are automatically deleted.
tags: inf_sec_vulnerability_management
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, Windows Update, and
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 thread it will be disabled.
We use socket.dev, which covers a broad range of checks (see https://socket.dev/npm/issue) to protect against supply chain attacks.
Dependencies should be limited and packages with a large number of transitive dependencies should be avoided.
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.
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
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.
If a virus has made its way to one of an employee’s devices, the security training has failed.
The event will be investigated to determine the method of transmission (i.e. 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.
In the event of infection, the policy for detection shall be executed.
Additionally:
If the virus includes a keylogger or otherwise may have gained access to credentials or sensitive information, the relevant policies shall also be executed.
Edit this page at https://github.com/savvi-legal/security-policy/blob/main/infosec-slr.md.