Policy Owner: Principal Engineer
...
All CloudCard information systems that are business critical and/or process, store, or transmit company data. This Policy applies to all employees of CloudCard and other third-party entities with access to CloudCard networks and system resources.
...
| Anchor |
|---|
...
|
Documented Operating Procedures
...
Separation of Test and Production Environments
Test and local development environments shall be strictly segregated from production SaaS environments to reduce the risks of unauthorized access or changes to the operational environment. Confidential production customer data must not be used in local development or test environments without the express approval of the Managing Director.
...
Production network access configuration rules shall be reviewed at least annually. Tickets These rules shall be created documented in an appropriate git repository, and pull requests used to obtain approvals for any needed changes.
...
CloudCard does not regularly backup user devices like laptops. Users are expected to store critical files and information in company-sanctioned file storage repositories.
Backups are configured to run continuously and incrementally, as well as daily on in-scope systemson in-scope data storage or stateful systems to run continuously and incrementally where possible. If continuous incremental backup is not possible, hourly backups shall be configured. The backup schedules are maintained within AWS. Backup restoration should be tested as part of the annual testing of the Business Continuity and Disaster Recovery PlanBackups do not need to be configured on application server instances or other servers that can be easily replaced from a combination of machine image and source code from a repository or artifact server.
Backup restoration should be tested as part of the annual testing of the /wiki/spaces/CCD/pages/2516680707.
| Anchor | ||||
|---|---|---|---|---|
|
...
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
...
System administrator and system operator activities shall be logged and reviewed and/or alerted in accordance with the system classification and criticality.
...
...
Data Restore Logs
...
In the event the company needs to restore production data containing PII from backups, either for the purposes of providing services or for testing purposes, shall be logged or tracked in auditable tickets.
...
Unauthorized intrusions and access attempts or changes to CloudCard systems shall be investigated and remediated in accordance with the Incident Response Plan.
...
| Anchor |
|---|
...
|
The installation of software on production systems shall follow the change management requirements defined in this policy.
...
| Anchor |
|---|
...
|
...
Information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities shall be evaluated, and appropriate measures taken to address the associated risk. A variety of methods shall be used to obtain information about technical vulnerabilities, including <vulnerability vulnerability scanning, penetration tests , and review of external vendor alerts, and the bug bounty program>.
Vulnerability scans shall be performed on public-facing systems in the production environment at least <quarterly>on an ongoing basis.
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 <IT and Engineering> departments 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 service ticket 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 timeframes12:
Determined Severity | Remediation Time |
Critical | 30 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.
...
| Anchor |
|---|
...
|
Rules governing the installation of software by users shall be established and implemented in accordance with the CloudCard Information Security Policy13.
...
| Anchor |
|---|
...
|
Audit requirements and activities involving verification of operational systems shall be carefully planned and agreed to minimize disruptions to business processes.
...
| Anchor |
|---|
...
|
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 Policy14.
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 |
|---|
...
|
...
|
Requests for an exception to this policy must be submitted to the <approver of exceptions to this policy, e.g., IT Manager> Managing Director for approval.
| Anchor |
|---|
...
|
...
|
Any known violations of this policy should be reported to the <person who should receive reports of violations of this policy, e.g., IT Manager>. 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.Anchor
Version | Date | Description | Author | Approved by | ||
<11.0>0 | <292023-Apr03-2020>26 | <First Version> | <OWNER> | <APPROVER>First Version | Ryan Heathcote | Tony Erskine |
APPENDIX A - Configuration and Hardening Standards
Configuration and hardening standards shall be maintained on the internal documentation portal.
...
Servers and Virtual Machines16
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.
<INSERT OS/SYSTEM BASELINE>17
In addition to the requirements to secure systems to the baseline outlined above, all physical and virtual systems must adhere to the following technical requirements:
All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, Simple Network Management Protocol (SNMP) community strings, etc.) must be changed before a system is installed on the network.
Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, SNMP, etc.) must be removed or disabled before a system is installed on the network.
Only one primary function may be implemented per server or virtual machine to prevent functions that require different security levels from coexisting on the same system.
Only necessary services, protocols, daemons, etc., may be enabled, and only as required for the function of the system. All unnecessary functionality (such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers) must be disabled
Additional security features for any required services, protocols or daemons that are considered to be insecure must be documented in Appendix B of this document, justified, and tested to ensure that they do not introduce unnecessary risk or vulnerabilities.
All security patches identified as <critical, high, or medium> must be applied to systems within SLAs established in this policy.
Network Standards
Management of network rules and settings may only be performed by authorized members of <ENGINEERING TEAM etc.> and all changes must comply with change Management procedures defined in the Operations Security Policy.
Network diagrams must be created and kept current. Significant changes (additions or deletions to VPCs and subnets, new external connections, etc.) must be documented in the diagrams; even if no changes occurred, the diagrams will be reviewed at least <annually> for completeness and accuracy, and approved/acknowledged (in version number/date field etc.) by authorized members of <Engineering Team etc.>
Supported network controls for production networks are <TYPE e.g. AWS NACLs>. Management of production network systems is accomplished through the use of <MANAGEMENT SYSTEM, SSH, ETC>
In the <PRODUCTION ENVIRONMENT>, defined rules and configurations must be enforced to control traffic from untrusted networks (e.g. publicly available services) to internal production networks; additionally, rules must be in place to restrict traffic to and from production networks to untrusted networks, and all inbound and outbound traffic must be evaluated by the the traffic management configuration.
Network control systems must be configured to use default Network Address Translation to prevent the disclosure of internal IP addresses to the Internet. If private IP addresses are used, any disclosure to external parties must be appropriately authorized, documented, and periodically reviewed for business necessity.
Mobile devices connecting to production networks must employ the use of a personal firewall or equivalent (such as endpoint protection with network restrictions enabled). Disabling or bypassing personal firewalls while connected to CloudCard systems is prohibited. Personal firewalls must be configured to specific standards, including: <disabling the use of split tunneling, configurations to block known malicious sites, blocking of insecure protocols, etc.>.
All network control systems must be configured with default antispoofing rules to block or deny inbound internal addresses originating from the Internet
Network control systems may only allow established connections into the internal network and must deny any inbound connections not associated with a previously established session.
External configurations must limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
Port and IP ranges are prohibited unless specifically reviewed and justified; all available services must be justified, and support secure configurations, all other ports, services, and network traffic must be specifically denied.
Use of insecure services and protocols without justification and documentation of additional security features implemented to mitigate risk is prohibited.
Remote access sessions must be configured to enforce timeout after a specified period of (X hours).
Remote-access technologies for vendors and business partners used to access production systems must be enabled only when needed for business purposes and immediately deactivated after use.
Any hybrid networks with both cloud and on-premise access shall be scanned and tested at least annually to ensure that security requirements are maintained18
<OTHER COMPANY SPECIFIC REQUIREMENTS>
Specific NACLs, ports, zones, and services allowed in and out of the production environment are defined below: Rules and allowed traffic must be evaluated at least annually and formally approved by <Network Team, Security Engineering, etc.>:
<UPDATE WITH approved/allowed rules/NACLs/Services etc.>
...
Source Zone
...
Dest. Zone
...
Source Address
...
Dest. Address
...
Service
...
Action
...
Purpose
...
Trust
...
MGMT
...
X.X.X.X
...
X.X.X.X
...
VPN
SSH
HTTPS
...
Permit
...
Allow management host access
...
Untrust
...
EXT
...
X.X.X.X
...
X.X.X.X
...
HTTP
HTTPS
SFTP
...
Permit
...
Allow inbound web services from the Internet
...
MONOPS
...
Trust
...
X.X.X.X
...
X.X.X.X
...
HTTPS
...
Permit
...
Allow remote monitoring by Operations
...
Untrust
...
Trust
...
X.X.X.X
...
X.X.X.X
...
Any
...
Deny
...
Default deny all
...
8 Logging content policy added for v2. Aligned to MVSP. Modify as needed.
9 Restore logs added for v2
10 Remove these paragraphs if your company does not have a file integrity monitoring and intrusion detection-related control.
11 Tailor this language to your environment
12 Update this table to describe your company’s vulnerability remediation commitments. Some organizations may set different policies based on system or network type. For example, external-facing systems are required to be patched more quickly than internal systems. If a policy like this exists within your organization, detail it here.
13 This is a reference to another Vanta policy. If you are not using that policy, describe your company’s policy for the installation of software by users here.
14 Reference to another Vanta Policy. Tailor as needed.
15 Include a link to your company’s wiki page about your company’s configuration and hardening standards. If you do not have a wiki, describe the standards here.
16 Template for hardening. Modify as needed.
17 Delete if N/A
18 ISO 27017Servers 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.
Where possible, use Amazon Linux as the base operating system and configure automatic updates and minor version patching.
In addition to the requirements to secure systems to the baseline outlined above, all physical and virtual systems must adhere to the following technical requirements:
All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, Simple Network Management Protocol (SNMP) community strings, etc.) must be changed before a system is installed on the network.
Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, SNMP, etc.) must be removed or disabled before a system is installed on the network.
Only one primary function may be implemented per server or virtual machine to prevent functions that require different security levels from coexisting on the same system.
Only necessary services, protocols, daemons, etc., may be enabled, and only as required for the function of the system. All unnecessary functionality (such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers) must be disabled
Additional security features for any required services, protocols or daemons that are considered to be insecure must be documented in Appendix B of this document, justified, and tested to ensure that they do not introduce unnecessary risk or vulnerabilities.
All security patches identified as critical, high, or medium must be applied to systems within SLAs established in this policy.
Network Standards
Management of network rules and settings may only be performed by authorized members of the Engineering team and all changes must comply with change Management procedures defined in the Operations Security Policy.
Network diagrams must be created and kept current. Significant changes (additions or deletions to VPCs and subnets, new external connections, etc.) must be documented in the diagrams; even if no changes occurred, the diagrams will be reviewed at least annually for completeness and accuracy, and approved/acknowledged in version number by the Principal Engineer.
In the Production environment, defined rules and configurations must be enforced to control traffic from untrusted networks (e.g. publicly available services) to internal production networks; additionally, rules must be in place to restrict traffic to and from production networks to untrusted networks, and all inbound and outbound traffic must be evaluated by the the traffic management configuration.
Mobile devices connecting to production networks must employ an endpoint protection with network filtering enabled and an approved configuration. Disabling or bypassing endpoint protection while connected to CloudCard systems is prohibited.
All network control systems must be configured with default antispoofing rules to block or deny inbound internal addresses originating from the Internet
Network control systems may only allow established connections into the internal network and must deny any inbound connections not associated with a previously established session.
External configurations must limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
Port and IP ranges are prohibited unless specifically reviewed and justified; all available services must be justified, and support secure configurations, all other ports, services, and network traffic must be specifically denied.
Use of insecure services and protocols without justification and documentation of additional security features implemented to mitigate risk is prohibited.
Remote access sessions must be configured to enforce timeout after a specified period of 8 hours.
Remote-access technologies for vendors and business partners used to access production systems must be enabled only when needed for business purposes and immediately deactivated after use.
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.