Magic Toybox
| Version | Date | Author | Approver |
|---|---|---|---|
| 0.01 |
The purpose of this document is to lay out the high-level security policy for Magic Toybox. This includes policy pertaining to:
The intended audience of this document is internal employees involved with the creation and maintenance of network and product.
The Company network consists of:
MT’s primary network segmentation is divided into:
All cross-boundary traffic between Internal and External segments must traverse approved firewall controls and be logged.
Customer-facing production systems accessed by:
Primary categories:
Network baseline configuration is found in the **Baseline Configuration - ** documents, including:
All documentation is available on company internal servers.
Changes to documentation (including baseline or procedural changes):
Network documentation is subject to quarterly sync reviews.
Access to MT internal assets is restricted to company-issued assets (primarily laptops).
Security controls include:
No asset will be issued that is not compliant with baseline standards.
Non-compliant assets:
Approved remote access software is listed in Baseline Configuration - Devices.
Internal server access is configured through:
All server settings must align with baseline configuration, as listed in Baseline Configuration - Servers.
Employees will rotate user passwords quarterly. All passwords will be stored in the approved Keystore application.
All departments will report the completion of this rotation to the Security Manager.
Baseline server standards conform to the document inventory stipulated in Baseline Configuration - Servers, incorporating:
Provisioning must be performed by a management-level system administrator using the cloud provider’s designated UI, as defined in the baseline under Baseline Configuration - Cloud Provider.
Server secrets must be stored in the approved Keystore defined in the baseline under Baseline Configuration - Keystore Application.
This includes:
SSL Certificates will be assigned using certbot. All server passwords and SSH keys will be rotated quarterly for all Internal and External environments. All passwords will be stored in the approved Keystore application.
All departments will report the completion of this rotation to the Security Manager.
All applications must follow the Baseline Configuration - Servers, enforcing naming conventions across:
.env files are centrally located on site.env files must be pushed from keystoreDeployment of development or production servers requires:
Management-level approval
Server setup testing & approval
Adherence to security procedures
Post-launch testing & approval
Integration into:
Production distribution additionally requires:
Deployment to publicly available domains requires management approval.
Development server updates:
Acceptable migration tools:
scpsshsmbProduction updates:
All deployment procedures are found in company online documentation. The most recent version must be used.
Weekly backups of production systems
Include disk images of:
Stored on designated storage servers (See: Asset Inventory)
Retained for 6 months
Restore testing performed every 2 months
Servers must deploy approved antivirus scanning tools (See: Baseline Configuration - Servers).
System administrator is responsible for implementing and managing approved Vulnerability Management Procedure.
All keys in keystore storage must be rotated on designated schedules.
Management-level administrator oversees:
Patching schedules depend on threat level.
Developer systems:
Production systems:
PII exists across:
Unless specifically exempted, all data is assumed to contain PII.
Examples:
All service users must agree to:
Policy permits mobile device data gathering with consent.
Data resale is prohibited.
Incidents are categorized by:
Incidents may require:
Volume classification applies when more than 1–5 identifiable parties are involved.
| Incident Type | Response Time | Network Impact | Data Exposure | Report Responsibility |
|---|---|---|---|---|
| Zero Day | Under Guidance | Varies | Varies | Discretionary |
| Network Degradation (Low) | 12h | Low | No | Internal |
| Network Degradation (Med) | 4h | Medium | No | Internal |
| Network Degradation (High) | Immediate | High | No | All Customers |
| Outage | Immediate | Outage | No | All Customers |
| Data Breach (Suspected) | 24 | Varies | Suspected | Internal |
| Data Breach (Confirmed Small) | 24 | Varies | Confirmed | Internal |
| Data Breach (Confirmed Volume) | Immediate | Significant | Confirmed | All stakeholders & authorities |
In the case of any cybersecurity incident, management falls on the Lead System Administrator, under the supervision of the Security Manager. The Security Manager retains final authority on notifications to stakeholders, customers, and the public.
Any employee may report an incident.
Zero-day detection responsibility lies with the network team.
Forensics will align with industry-standard best practices for the affected device.
All incidents require internal review.
Incident evidence assessed at low or medium priority will be dispositioned at the discretion of the security manager. The Security Manager will retain any evidence of incidents greater than a Low or Medium Severity for 180 days, unless granted written authority to destroy by the CISO.
Authority for changes to policy will rest with the CISO or Security Manager.
Responsibility for enforcement of this policy rests with all department managers, under supervision of the Secruity Manager
All changes must be approved by management-level employees, defined in this policy as being the Lead System Administrator, Security Manager, or CISO
All exceptions must be approved by management-level employees, defined in this policy as being the Security Manager, or CISO
Exceptions apply to both changes of security policy, as well as changes to the implementation baseline network and application configurations. Management of these exceptions will be owned by the Lead System Administrator, and implemented by Network Team. The approval of the Security Manager is required for exceptions lasting over 30 days. Any exception that is intended to last more than 30 days must establish in exception request why it is not to be treated as a change.
Exceptions to security policy must be documented by the implementing authority. Documentation must include:
Change Management Policy applies to all changes to network or application baseline, differentiating them from exceptions. Management of these changes will be owned by the Lead System Administrator, and implemented by Network Team, following approval by the Security Manager
Changes to network baseline must be documented by the implementing authority. Documentation must include:
Internal personnel will proceed through the following lifecycle steps through onboarding and offboarding, as well as during their time as internal personnel.
The supervision of personnel offboarding is the responsiblity of the Human Resources department. Personnel approved for onboarding must fulfill the approved procedure for distribution and enablement of assets and systems. All access must be approved by internal personnel's supervisor, and the Security Manager. Procedures established in Onboarding Procedure Detail this process.
While internal personnel at Magic Toybox, personnel will be bound by all tenets of "Section 6: Access Control" Policy. This includes remote access policy, password rotation, and incident response responbililities.
The supervision of personnel offboarding is the responsiblity of the Human Resources department. Personnel approved for offboarding must fulfill the approved procedure for securing of assets and systems approved by the Security Manager. Procedures established in Offboarding Procedure Detail this process.
Information on offboarded personnel will be stored for 12 months. This includes image of company laptop, email account records, and any paperwork, including scanned copies of physical paperwork or electronic documents.