coderio Technical Security Policy
Table of contents
1. Scope, Exceptions, and Sanctions 4
2. Application design and development 5
2.1. Initiation and Planning 6
2.2. Requirements and Analysis 6
Data storage and transmission 6
Confidentiality, integrity, and availability 6
Identity and access management 7
2.5. Third-Party Products and Development Services 8
3.2. Hosting and infrastructure 8
Prohibited Hosting Activities: 9
Environment separation and capacity 9
3.6. Monitoring and Detection 11
3.7. Vulnerability Management 12
Vulnerability scanning, assessment, and remediation 12
4.6. Connections and Timeout 14
7.1. Network Infrastructure Devices 16
8.2. Managed Cloud Service Engagements 18
The purpose of this document is to provide a comprehensive set of technical security requirements to protect confidential Company, client and other third-party information.
This Policy applies to all Personnel who participate in the design, development, testing, and/or operation of applications, hardware, networks, or other technology Systems.
Personnel who lead projects and/or operations of Systems are responsible for the application of this Policy in their areas of responsibility.
1. Scope, Exceptions, and Sanctions
This policy identifies the requirements for Company Systems and In-Scope Client Systems to be developed and operated in a secure manner. The term "System(s)" refers to Company Systems and In-Scope Client Systems.
1.1 In Scope
This policy applies to Systems as described below.
Unless otherwise stated in this Policy, this Policy applies to the security of all Company Systems. The Policy addresses the following security principles:
- Identification (e.g. user ID) and authentication (e.g. passwords and/or PINs) Authorization (e.g. access roles and access control)
- Confidentiality (e.g. encryption), integrity (including system, data, and message integrity, e.g. accuracy of data storage and transmission), and availability (e.g. accessible when needed)
- Accountability (e.g. tracking and audit)
The engagement delivery lead is accountable for delivering to any client contractual requirements and specifications regarding Information Security.
In-Scope Client Systems must be designed and managed in accordance with this Policy, excluding section 2 which does not apply to infrastructure. The exceptions process set out in section 1.2 must be used to manage any risk resulting from differences between client requirements for In-Scope Client Systems and this policy, including associated standards found in this Policy and the Supporting Documentation section.
For clarity, any client system work that is not an In-Scope Client System, for example, application design and development, is out of scope, and the requirements in this Policy do not apply to it.
This policy applies to the infrastructure in all Company offices, including both Company-owned and leased facilities.
On rare occasions, it may be appropriate to grant an exception to certain requirements of this Policy. Authorized Personnel may request an exception through IT Service Desk, as a non-conformity. It’s important that in the description of the request, you ask for an exception, clarifying as much as possible the reason why. It must be approved by the competent authority.
Any Personnel who violate this Policy may, as circumstances merit, be referred to as HR and/or Legal and may face disciplinary measures, including but not limited to:
- A note placed in Personnel file;
- Consideration during total rewards decision-making, and performance achievement talent actions meetings;
- Removal from an engagement; and/or
- Other sanctions, up to and including termination.
2. Application design and development
Secure application design and development is an integral part of the development process. This section identifies the security requirements for the application development lifecycle for Company Systems. This section does not apply to In-Scope Client Systems because this section does not apply to infrastructure.
2.1. Initiation and Planning
All applications must be developed, deployed, and maintained securely in accordance with the applicable Application Security Standard. The development process must follow the security content identified within the corresponding _coderio Delivery Methodology. Existing applications must be remediated if they cannot function on Systems that have been hardened in accordance with this Policy.
2.2. Requirements and Analysis
Personnel developing or maintaining applications are responsible for identifying, documenting, and implementing the appropriate security controls in order to protect the confidentiality, integrity, and availability of the application and its data in accordance with _coderio's Standard. The application must have Role-Based Access Control (RBAC) functionality and must respect the Least Privilege Principle. Refer to section 4. Access Control for more information.
During the Analysis phase data privacy considerations should be appropriately determined and explicitly documented so that they are addressed during the project.
2.3. Design and Build
Data storage and transmission
- Application interfaces must be designed to exchange the minimum required data with other systems. The design must include an audit trail of data exchanges. For complex exchanges (as determined on a project-specific basis by the technical architect or lead developer), integrity and authenticity of the data must be maintained, and there must be an acknowledgment of receipt of data.
- Encrypted data must not be decrypted unnecessarily (i.e. unless the application needs to use it), not transmitted in the clear and adhere to requirements detailed in the Encryption Standard. The need for the use of Confidential data must be verified and approved in writing by the CISO or client.
Confidentiality, integrity, and availability
- Data categorized as Highly Confidential or Restricted (refer to the Data Classification & Protection Standard) must not be recorded into trace or log files.
- An Application Security Assessment must be requested for any application that contains Highly Confidential or Restricted data.
- Developers must follow the coding standards and testing guidelines defined for the System to comply with applicable security requirements.
- Source code must be secured in a manner that prevents unauthorized access. Automated source control tools must be used to help ensure the reliability of developed applications and data used in the application. This software must track all versions of every development artifact, including change comments as necessary.
Identity and access management
- Passwords that are used by Systems (e.g. via application code or tool) must be protected (e.g. hashed or encrypted) and/or access to any configuration files holding passwords must be limited to those who need to know in order to perform their jobs.
- User access must be logged and be inclusive of all users and administrators. Refer to section 3.5 Monitoring and Detection for more information.
- User documentation must include security features within the System, as well as the procedures necessary to use the application in a production environment.
- Web-based applications that request the Company's user ID and password must have a URL in the format of a subdomain of the specified domain of the requester.
Applications must comply with the applicable application security standard before being introduced into a production environment.
- Applications must be tested for security before being put into production. Test plans must be created and executed to validate the effective operation of security controls identified in the design documents.
- New applications must be tested on production-like hardened Systems, and testers must use permissions similar to those that the application users will have.
- Production data must not be used in development or test environments without explicit written approval and instruction from the Data Governor. If a client instructs _coderio to use production data that is Client Data in non-production environments, then the project team must include appropriate compensating controls in the solution as approved by the Accountable _coderio Leader and obtain written client approval of such risk. Where practical, such data should be masked/anonymized.
- Vulnerability, penetration, and integrity scans must be conducted as determined by the security plan (i.e. MG138 in BDM. Refer section 3.7 Vulnerability Management for more information.
- Development, test, and production environments must be separated to reduce the risk of unauthorized access or changes to the Production System. Refer also to the Environment Separation and Capacity section of this policy.
2.5. Third-Party Products and Development Services
Where an application is licensed from a vendor or is developed by a third party, the project lead must develop security requirements as if the application was an internally developed application and apply those requirements as part of the selection and contracting process.
If the third-party product cannot meet those requirements, then, pursuant to section 1.2, an exception must be requested and if the exception is not approved, then the application may not be used.
3. Secure Operations
This section details the Company's requirements for operating Systems securely.
3.1. Operational Procedures
All technology support functions (e.g. operations, technical support, etc.) must maintain documented operational procedures for their Systems that are reviewed and updated at least annually or upon the occurrence of a major change (e.g. implementing a new product) in the System.
3.2. Hosting and infrastructure
The infrastructure providing production and project services must conform to the following requirements:
- All Systems managed by _coderio, including Systems providing cloud services internally or to clients, must be housed only at the client- provided data center (for services serving only that client), or approved third-party hosting providers and cloud service providers. See the Hosting Services Catalog for an inventory of approved internal and third-party services and guidance on how to select appropriate service.
- All servers and network infrastructure managed by the Company must be configured, secured, and hardened in compliance with this Policy and the Infrastructure Security Standards. See section 5. Hardware Assets for controls related to physical security and offsite equipment.
- All the systems supporting High Availability must be configured in that way to provide redundancy against failures and keep the service working.
Prohibited Hosting Activities:
- Local Server Rooms in the offices are not permitted to be used for local hosting for any new servers.
- Users are not permitted to directly source cloud-based hosting services. All hosting services sourcing must be done and brokered through the _coderio Cloud Platform or the client’s approved Cloud Platform.
- Physical or virtual machines running server images used to provide ongoing project or operational services must be in _coderio's data center.
- Exceptions are permitted without section 1.2 approval only in the following limited cases: A regulatory requirement (as discussed and confirmed with Legal) for hosting in a country where the Company does not have an approved data center location and offering, or for demonstration exercises where connectivity to approved data centers cannot be reasonably established.
- Virtualization layers must receive the same level of operational care as physical assets, for example for change control, patching, configuration management, etc.
- Where third-party hosting solutions are used to process Highly Confidential or Restricted data, a security assessment must be conducted.
- Where third-party hosting solutions are proposed to be used to process Personal Data, the Legal team must be consulted in advance of any commitment to use such a solution to ensure that data privacy concerns are appropriately addressed.
- Cloud services must be used in accordance with the applicable Cloud Configuration Standards. Refer to section 8. Cloud Services for additional details.
Environment separation and capacity
- Production Systems must be either physically separated or logically separated (e.g. using a firewall, etc.) from test and development Systems. Virtual machines running on the same physical machine must be hosted in separate virtual LANs.
- Application developers must not have write access to the application's production servers. They must also not have read access unless there is a documented business need approved by the CTO of _coderio or (ii) the accountable leader or client for In-Scope Client Systems.
- Technology capacity levels must be monitored, and a process put in place to estimate and implement capacity changes to adequately meet business performance requirements.
- There may be situations when Systems must be hosted in a dedicated computer environment (contractual requirements, regulatory restrictions, etc.). If that is the case, the engagement legal professional or data privacy team will provide direction relating to the contractual requirements, regulatory restrictions, or similar issues.
3.4. Change Management
To prevent security vulnerabilities, any changes to a production environment must go through a formal change management and approval process. This process must include written proof that the changes have gone through the appropriate test phases to assess any potential security impact and documented contingency plans to roll back the changes if necessary.
Critical applications and security controls must be tested as part of the process for changing or upgrading operating systems. Any modifications to the Software Package must be controlled and documented.
Refer to the BDM for Service Delivery for specific change management processes that must be followed.
3.5. Backup and Recovery
- The backup process must be documented per the organization's procedures, including a retention schedule, and be periodically tested to confirm that the backed-up data can be restored.
- Backup copies must be taken of essential data, programs, and configuration files on a regular basis. The data must be encrypted with a minimum of AES 256-bit encryption when stored on portable media (e.g. tapes) or when transmitted/transported outside of a Company managed data center/server room to a non-Company managed data center/server room as part of the backup process
- Security controls for both physical and logical access must be in place to allow only Authorized Personnel to create backup copies and to access backed up data.
- Backup media which contains data that has expired and that will no longer be used in the backup process must be sanitized or destroyed. No media can be sanitized or destroyed where it contains data that is part of a Legal Hold Notice without the consent of the Legal group.
- Portable media (e.g. USB Flash "Thumb" drives, DVDs/CDs, etc.) must be encrypted with a minimum of AES 256-bit encryption when used to store data.
- System owners are responsible for identifying their requirements for maintaining the availability of their Systems and considering the business impact of service downtime. The System owners must also identify the components necessary to recover and restore their Systems. These requirements must be implemented and included in the Business Continuity/Disaster Recovery (BC/DR) plans.
- The restoration of the security controls at production levels must be part of the BC/DR plan, and the plan must be tested periodically, with frequency depending upon the criticality of the System. The Recovery Time Objective (RTO) and the Recovery Point Objective (RPO) must be documented in the BC/DR plan.
- Any backup copies that are needed for disaster recovery purposes must be stored at a secure alternate location.
3.6. Monitoring and Detection
- Monitoring and logging activities must be compliant with all relevant local laws and regulations.
- All Systems must have logging enabled and must record security events and other important events necessary for the function of the System as requested by the System owner, in accordance with the Logging and Auditing Standard.
- Processes must be developed and deployed to protect the audit logs from unauthorized access, alterations, overwriting, or not being processed altogether.
- The activities of Personnel with privileged user accounts must be monitored and logged.
- Systems must be configured with time synchronization to allow for cross-System correlation of events recorded in the logs. Portable devices plug can be controlled and limited on systems.
3.7. Vulnerability Management
Vulnerability scanning, assessment, and remediation
- Vulnerability assessments must be performed on Systems that contain Highly Confidential or Restricted data, or similar levels of sensitivity of client data, when the System is first deployed and then periodically thereafter as determined by the IS Assessment & Compliance team. Refer to the Security Assessments site for more detail.
- Vulnerabilities must be repaired in a timely manner as determined by the level of risk that the vulnerability poses, or alternatively, the System must be made unavailable.
- Exception requests must go through the exception process as described in section 1.2 Exceptions.
- Only Authorized Personnel may have access to the tools used to scan Systems. Before conducting a scan, Information Security approval must be obtained via an email request.
Antivirus and patching
- An Information Security approved anti-virus Software Package must be installed, configured to automatically retrieve new definitions daily, and used on all Workstations and Windows servers that are connected to the network.
- The anti-virus software must be configured to scan files accessed in real-time and to perform regularly scheduled scans of all files on the System unless excluded in the Infrastructure Security Standards.
- All Workstations and servers must be enrolled in the Company's approved patch management tool.
- Critical security patches and fixes must be applied to Systems in a timely manner. Security supersedes availability in critical security situations, as determined by the System owner.
The data contained within, accessed by, or transmitted through Systems must be encrypted. Cryptographic keys and digital certificates must be securely created, distributed, maintained, stored, and disposed of when no longer needed and must be set to expire.
4. Access Control
This section describes the access control requirements necessary for managing access to systems and information and supports the Company's objective of restricting access according to business needs and job function.
4.1. Access Management
- A request to access a System is to be initiated, approved, and processed by Authorized Personnel. Within each System, RBAC must be implemented to help ensure the segregation of duties.
- A list of current access roles must be maintained by each application or System owner and all users/administrators of the application or System will be assigned one or more access roles, based on their job function(s). The Least Privilege Principle must be applied when provisioning access. Each administrator, application, and user that can access a System (e.g. server, website, database, etc.) must have a business need to access the System.
- If an administrator, application, or user requires access to an application or system that cannot be accommodated by an existing access role (i.e., the role contains too many or too few permissions), a new access role must be created to accommodate the need.
- To ensure that access is properly assigned, only Authorized Personnel or an automated system may enable, disable, or change permissions.
- User access rights and privileged user IDs must be audited regularly.
4.2. User Identification
- Only Authorized Personnel is permitted to create/disable user IDs and provision/suspend access.
- Each administrator and user must be assigned his or her own unique ID, which must be linked to the administrator or user's name, personnel number, or other unique, Company-approved identifier.
- Each unique application ID must clearly identify the application to which it is assigned. Application team(s) are responsible for managing the lifecycle of their application IDs from creation to decommissioning. If the application is decommissioned the application team is responsible for ensuring appropriate application IDs are removed from all systems and domains.
- The use of shared IDs are prohibited on Systems.
4.3. User Authentication
Multi-factor authentication is required for all applications and services that contain Confidential, Highly Confidential, or Restricted data as defined in the Data Classification & Protection Standard.
When an unsuccessful login attempt occurs, every system has to limit it and lock the compromised account.
4.4. Password Management
The passwords must be 9 characters at least, with at least one number and one special character. Passwords must not be displayed online during the login process or on reports.
User identity must be verified before passwords are reset or user IDs unlocked.
All passwords must be compliant with the _coderio Password Policy.
4.5. Temporary IDs
- Test IDs (created for the purpose of testing) that do not access production data, might be reused and reassigned to users. If the Test ID is created for use in performance testing, then the password must be loaded into the tool that will perform the test and distributed to a limited set of Personnel.
- Demo IDs (created for demonstrations) must be created as local accounts. They must have access only to specific applications for a predetermined duration.
- Firefighter IDs must be disabled until they are needed and only temporarily enabled for the time required to resolve an incident. The use of a Firefighter ID must be documented in writing. A supervisor (code_rio Leadership or higher) of the individual who requested its use must be notified in writing. The ID must be enabled by a person other than the individual requesting use of the ID. The name of the user and the activities performed under the Firefighter ID must be logged and recorded in accordance with the Logging and Auditing. The password must be changed after the pre-allocated time period to use the password has expired.
4.6. Connections and Timeout
Session timeouts due to inactivity must be enabled on Company devices. Workstations that access Systems must require user re-authentication after a predetermined amount of inactivity time. Application/System owners must include session timeouts as part of their requirements and design. The owners must also consider the length of time before the session is inactivated (i.e. timed-out) based upon the sensitivity and use cases of the application/service.
5. Hardware Assets
This section outlines the security requirements for the Company's equipment and for removable media protection, regardless of the location of the asset.
- Every Company hardware asset will have an identified owner who is responsible for establishing the requisite security for that asset.
- Company network infrastructure must be configured to support open communication and reporting on a regular basis between the Asset Management Console and the Asset Inventory Agent.
- All Company locations that house servers or data will have, at a minimum, basic physical security measures to protect Systems.
6. Technical Platform
This section covers security requirements for the Company's technical platforms, including operating systems and device configuration.
6.1. Platform Security
- The Company shall not use platforms for which the vendor no longer provides security updates and patches. Security updates and patches shall be tested and applied to all platforms in accordance with vendors’ schedules.
- Operating systems must use an automated security patching and compliance reporting tool. Operating consoles should be used if available.
- Any changes to a platform that would result in the platform no longer adhering to the Company's security requirements must go through the security exception process as described in section 1.2 Exceptions.
- Local accounts (i.e. user/system/admin accounts that are local to a computer or server) must be created only when necessary. Any accounts used on a regular basis must be in a central authentication service.
- System servers will provide only the essential services to run the required software needs. It includes software services, network ports, and credentials.
6.2. Malicious Code
Systems must have all applicable security software and configurations (e.g. antivirus, encryption, domain membership, firewall, etc.). The intentional download or creation of Malicious Code is prohibited.
6.3. Clock Synchronization
All Systems must synchronize their time from an approved time server.
This section covers the Company's security requirements for network infrastructure and services managed by the Company. Refer to section 3.2 Hosting and 3.3 Virtualization for requirements for infrastructure and services managed by third parties.
7.1. Network Infrastructure Devices
All network infrastructure devices, including routers, switches, firewalls, etc., must follow the Least Privilege Principle for access and must be hardened to prevent unauthorized access.
Network infrastructure device passwords must be encrypted in transit.
All Company wireless Systems (e.g. wireless network, mobile hotspot, etc.) transmitting Company or client data must adhere to these standards.
7.2. Network Services
The network services that are not used must be disabled on every System.
7.3. Network Segmentation
Externally facing System components (e.g. web servers) must be isolated from other application components (e.g. database servers) through a protected network zone that adheres to the Networking Components Standards.
7.4. Remote Access
Any data transmitted to a remote location, and administrative functions conducted by Personnel from outside the Company network, must be done through the use of a VPN or via an approved transmission encryption protocol in compliance with the Encryption Standard.
Company machines must not be connected simultaneously to a Company network and non-Company network (network bridging). This restriction includes but is not limited to:
- Dual wired LAN NICs,
- Connecting to a wired network and Wireless network at the same time,
- Connecting to a Company network and cellular network at the same time, and
- Connecting to a wired LAN along with a client VPN with split-tunneling enabled.
- (This restriction does not include Bastion or VPN access from one Company controlled network to another, as long as it is compliant with client contractual obligations.)
7.5. External Connections
Systems with external connections must be protected by hardening and firewalls. (Refer to sections 6.1 Platform security.
Externally facing Systems must be placed in a demilitarized zone or other similar configuration to protect internal Systems. (Refer to section 7.3 Network Segmentation for more information).
Devices (e.g. servers, routers) on the Company network must not be accessible from the Internet for administrative purposes unless a secure connection is used in compliance with the Remote Access Standard. (Refer to section7.4 Remote access for more information).
8. Cloud Services
This section covers the Company's security requirements for cloud services. This includes internal company use of cloud services, cloud services delivered to clients through managed services engagements, and defines requirements applicable to the following cloud service models: software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS).
8.1. Internal Company Use
- Only approved cloud solutions and services can be used.
- When sourcing Cloud Services from a supplier, the account manager for the project must ensure that the Supplier Management Process is followed to manage supplier risk. As part of this process, a Supplier Risk Profile questionnaire must be completed early in the sourcing process, and action taken to address the risk profile requirements. Additionally, the account manager for the project is responsible for managing non-compliance remediation activities.
- Cloud Consumers are not permitted to directly source cloud-based hosting service.
8.2. Cloud Services Roles
The primary roles involved with Cloud Services are defined below. Common responsibilities associated with these roles are listed below.
- AWS: Brokers cloud accounts, develops secure images and service templates for cloud deployment, and monitors compliance to standards
- Account Manager: Initiates the sourcing process for selected vendor or solution, completes the supplier risk assessment, manages remediation efforts, and verifies ongoing compliance with _coderio Standards.
- Cloud Consumer: Overall responsibility for the compliance and remediation of non-compliance for operated cloud environments. Responsible for the use and confirmation of the cloud solution in compliance with _coderio Security, Data Protection, Data Classification, and Client standards.
- Information Security: Defines and maintains Security Policy and Standards; performs security assessments, and manages the client data protection, and the security exception management process.