Policy Owner: Principal Engineer
...
Log user log-in and log-out
Log CRUD (create, read, update, delete) operations on application and system users and objects
Log security settings changes (including disabling or modifying of logging)
Log application owner or administrator access to customer data (i.e. Access Transparency)
Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action.
Logs must be stored for at least 30 days, and should not contain sensitive data or payloads
Protection of Log Information
...
Vulnerability scans shall be performed on public-facing systems in the production environment on an ongoing basis.
Penetration Customers and other third parties shall be permitted to perform penetration tests of the applications and production network shall be performed at least annually, and additional scanning and testing shall be performed following major changes to production systems and software.The Engineering team shall evaluate the severity of vulnerabilities identified from upon request.
The Engineering team shall evaluate the severity of vulnerabilities identified from any source, and if it is determined to be a risk-relevant critical or high-risk vulnerability, a Trello card will be created. The CloudCard assessed severity level may differ from the level automatically generated by scanning software or determined by external researchers based on CloudCard’s internal knowledge and understanding of technical architecture and real-world impact/exploitability. Tickets are assigned to the system, application, or platform owners for further investigation and/or remediation.
Vulnerabilities assessed by CloudCard shall be patched or remediated in the following timeframes:
Determined Severity | Remediation Time |
Critical | 14 Days |
High | 30 Days |
Medium | 60 Day |
Low | 90 Days |
Informational | As needed |
Service tickets for any vulnerability which cannot be remediated within the standard timeline must show a risk treatment plan and planned remediation timeline.
...
Risks shall be considered prior to the acquisition of, or significant changes to, systems, technologies, or facilities. Where requirements are formally identified, any relevant security requirements shall be included. The acquisition of new suppliers and services shall be made in accordance with the Third-Party Management Policy.
The company shall perform an annual network security assessment that includes a review of major changes to the environment such as new system components and network topology.
| Anchor | ||||
|---|---|---|---|---|
|
...
Any known violations of this policy should be reported to the Managing Director. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment.
Version | Date | Description | Author | Approved by |
1.0 | 2023-03-26 | First Version | Ryan Heathcote | Tony Erskine |
APPENDIX A - Configuration and Hardening Standards
Servers and Virtual Machines
...
1.1 | 2024-07-13 | Annual Review | Ryan Heathcote | Luke Rettstatt |
1.1.1 | 2024-08-17 | Minor Clarification | Ryan Heathcote | Luke Rettstatt |
APPENDIX A - Configuration and Hardening Standards
Servers and Virtual Machines
This is the standard for system-level server and virtual server (VM) configuration hardening. Some customization to these settings may be required to configure the system for its specific target environment, such as setting the proper names, groups, authentication settings, and other personalization options.
...
Network security rules and allowed traffic must be evaluated at least annually and formally approved by the Principal Engineer. Only HTTP and HTTPS traffic is to be allowed into the production network from any source. All HTTP traffic should be redirected to HTTPS as close to the edge as possible. RDP, SSH and Database traffic can be allowed from the internet for administrative use, but must be allowed only to specific IP addresses with a current business justification. Where possible, use internal AWS mechanisms (e.g. EC2 Session Manager) to make remote administration connections, rather than opening a port.
Appendix B - Configuration Management Plan
The configuration management plan applies to all configurations in AWS affecting production resources.
Where feasible, record configurations as code in the application monorepo (e.g. terraform, SQL migrations).
Provide detailed instructions for making the change in a trello card added to the CloudCard Release board. If the change cannot be recorded in code, it should be fully detailed in the trello card.
Configuration changes must be tested in the test environment unless it is a change that can only be made to production.
Even in the case of a production-only change, we should seek to test an equivalent change in the test environment.
Another engineer must review all configuration change cards and pull requests.
Configuration changes are typically applied during a release window prior to deploying the application package. Configuration changes that do not apply to an elastic beanstalk environment or that are of low risk can be applied as soon as they are reviewed.