Server Security Policy
Understand Roboto Studio's Server Security Policy. Learn about our robust measures to protect data integrity and ensure server reliability.
1.0 Purpose
The purpose of this policy is to establish standards for the base configuration of servers (physical and virtual) owned and/or operated by Roboto Studio. Effective implementation of this policy will minimize unauthorized access to Roboto Studio’s proprietary information and technology.
2.0 Scope
This policy applies to servers owned and/or operated by Roboto Studio and to servers registered under any Roboto Studio-owned internal network domain.
3.0 Policy
3.1 Ownership and Responsibilities
An organizational team must own all servers managed by Roboto Studio. Approved server configuration guides must be established and maintained by each operational group based on business needs and approved by Roboto Studio IT.
3.2 General Configuration and Backup Guidelines
Operating System configuration should be following approved guidelines. Access to services should be logged and protected through access-control methods. Production servers shall be backed up daily.
3.3 Monitoring
All security-related events on critical or sensitive systems must be logged, and audit trails saved. Logs should be sent to a central log management platform. Security-related events should be reported to Roboto Studio IT.
3.4 Patch Management
All servers under Roboto Studio’s control will be maintained with the latest security patches. Each organizational unit or group is responsible for servers under its control. IT/Information Security is responsible for performing a vulnerability scan on systems after each patch window.
3.5 Decommissioning a Server
Roboto Studio shall define a process for decommissioning servers. This process will be different for virtual servers and physical servers. The data on the servers must be completely destroyed before the machine is taken out of service.
3.6 Compliance
Periodic audits will be performed as authorized by Roboto Studio management. Efforts will be made to prevent audits from causing operational failures or disruptions.
Version History
A list of all the versions including their version, author, date and comments.
Version | Author | Date | Comments |
---|---|---|---|
0.1 | Joe Pindar (Fresh Security) | 2022-05-16 | First Draft |
1.0 | Joe Pindar (Fresh Security) | 2022-06-01 | Sign Off |
1.1 | Joe Pindar (Fresh Security) | 2023-10-01 | Add patching timeliness requirements. Add policy review schedule. Review for best practice alignment. |