Policies & Processes

Information security policies and processes form the backbone of ACL's information security program. ACL's security policies set the tone and direction for the organization, assign and delegate roles and responsibilities for information security, establish control objectives, and demonstrate commitment and accountability to all constituents, including employees, business partners, and customers.

Our solution is supported by various operational and security policies, standards, and procedures related to:

  • Access control
  • Employee on-boarding and off-boarding
  • Information classification
  • Logging and monitoring
  • Change control
  • Secure development
  • Vulnerability management
  • Customer service
  • Problem management
  • Incident response
  • Third-party management

Shared responsibility model

ACL manages the overall application infrastructure and our customers manage the end-user security and access control to their individual system. This is known as the Shared Responsibility Model, which is comprised of:

  • Customer responsibility
  • ACL Services Ltd. responsibility
  • Amazon Web Service (AWS) responsibility

Shared Responsibility Model

Customer responsibility

Customers share the responsibility of not only keeping their data secure, but also complying with applicable regulatory or privacy laws. Our customers have full ownership of their user access controls and manage their entire data lifecycle from deciding what data goes into the system, how long it should be retained, what data should be deleted, and whom can access the data.

ACL Services Ltd. responsibility

In addition to the physical and hardware security that Amazon provides, ACL also has a robust information security environment to ensure that the confidentiality, integrity and availability of customer data meets our high standards and our customers' high expectations.

Amazon Web Services (AWS) responsibility

Amazon is the largest vendor of data storage and computing on the planet, and they are responsible for the physical facility as well as the physical infrastructure of server hardware, networking, and related services for the ACL GRC service and hosting customer data.

Physical and environmental security

ACL's corporate headquarters building is located in a shared physical facility. The building's entrance is kept locked during non-business hours, and is further protected by a security guard service. Security cameras are visibly placed in high traffic or sensitive locations.

ACL's doors require badge access prior to granting entry. All employees, contractors, and visitors must wear a visible badge at all time. All doors are alarmed and will alert our vendor and the police if a disturbance is detected. Physical access is audited every quarter, however, no customer data is stored at our facility.

Logical security

ACL uses a principle of least privilege for internal administration. Employees who require administrative access must be requested via a ticketing system. The request requires the approval of senior management before access is granted.

Administrative access to all applications is granted to ACL employees only based on user job responsibilities. Access to all production system and internal applications is removed immediately upon employee termination or contractor contract termination.

On a quarterly basis, the Director of Information Technology, acting with the Chief Technology Officer and ACL's Information Security Specialist, are responsible for reviewing the access rights and responding with any changes necessary and associated approval.

Customer environment access

ACL customers should have controls in place to restrict access to the individuals to whom account access is required. Controls should include approving individuals for access to accounts prior to setting up users in the system and revoking users' log-in credentials when user access is no longer required or if user authentication credentials or other sensitive information has been compromised.

Our platform includes several capabilities to assist customers in their responsibility to manage end-user system access, including the ability to:

  • Enforce strong passwords
  • Configure password expiry
  • Configure session timeout
  • Configure SSO (Single-Sign On) via SAML 2.0
  • Lock user accounts after multiple failed log-ins
  • Easily delete or suspend user accounts
  • Specifically identify permissible user IP addresses
  • Use activity tracking to log access and system use

Systems layer user access

Production databases are on Amazon RDS. RDS does not allow access to the database servers beyond the standard database protocol interface.

RDS database creation and configuration is done by our DevOps team through coded infrastructure and the AWS management interface.

Incident management

ACL has a robust Incident Response Plan to promptly and effectively manage incidents that impact the system environment. This plan is in place to both minimize potential damages that could result from a data breach and to ensure that parties affected by the data breach are properly informed and educated how to protect themselves.

The Security Incident Response Team (SIRT) is responsible for responding to, managing, and conducting security investigations, including all aspects of communication such as deciding how, when, and to whom the findings shall be reported. Remediation of identified security incidents remains the responsibility of the business or system owner for the affected asset.

Breach notifications

In the case of an incident, notifications are made in a timely manner to affected parties.

The notification will include:

  • A brief description of the incident, including the nature of the breach and the date it occurred
  • A description of the general type(s) of data that were involved in the breach (not an individual's specific information)
  • An explanation of what ACL is doing to investigate the breach, mitigate its negative effects, and prevent future incidences

Incident management workflow

The lifecycle for a security breach incident at ACL contains the four phases identified in the following diagram. Within each of these phases, specific actions are taken to address issues and ensure customers and employees are provided with appropriate notification and guidance.

Incident management phases

Preparation

ACL has taken the following key steps to prepare for incident response:

  • Developed security policies and procedures - ACL has implemented a security policy framework based on ISO 27001/2 to define minimum security requirements and expecations for security across the organization.
  • Established incident response roles and responsibilities - The SIRT is responsible for verifying that an incident has occurred, taking action as appropriate, and escalating the matter to ACL's Senior Leadership Team, as needed.
  • Established a SIRT that includes subject matter experts from all teams - The SIRT includes primary and alternate members from various operational groups that form a Virtual SIRT (VSIRT). VSIRT members are subject matter experts that are formally appointed points of contact for security incidents.
  • Evaluated key systems security - ACL conducts routine vulnerability assessments against pre-defined assets and drive remediation efforts across the organization.
  • Investigated applicable legal requirements for breach response - ACL maintains a list of relevant external contacts such as law enforcement and subject matter experts that can assist during an investigation.
  • Conduct regular appropriate training - SIRT members participate in routine simulations and drills, attending specialized training, and monitoring industry news and trends to improve their responsiveness and readiness.

Identification & Analysis

ACL monitors and investigates all events and reports of suspicious or unexpected activity, and tracks them in an internal ticketing system.

If an incident is confirmed, analysis begins, a severity is assigned and the ticket is escalated accordingly.

Depending on the severity and incident type, the SIRT gathers and analyzes information, involving forensic specialists as required, to determine the causes, impact, type and any other relevant information regarding the incident.

Containment & Remediation

In order to limit the impact of the incident, prevent any further damage from happening, and recover the affected systems, the SIRT can take many actions during this phase:

  • Short term containment - To stop an attack/incident from escalating further.
  • Evidence preservation - To capture data that could be used in the investigation, lessons learned, and/or prosecution.
  • Threat mitigation - To mitigate the threat in order to temporarily bring affected systems back online.
  • Remediation - To the ensure the affected system is secure prior to being reintroduced into a production environment.
  • Recovery - To test, validate, re-introduce, and closely monitor affected systems once reintroduced.

Post-Incident Activities

After an incident has been resolved, the SIRT will conduct the following activities to ensure continuous improvement:

  • Ongoing monitoring - To monitor the affected systems to ensure the threat is eradicated and does not return.
  • Root cause analysis - To ensure corrective actions focused on the true root cause of the problem.
  • Lessons learned review - To identify and document areas of improvement in the incident response process.
  • Incident close - To ensure all required documentation is completed and packaged with the case, and the incident tracking case is closed.

Secure Software Development Life Cycle (SSDLC)

At all phases in the application development process, security is a top priority.

At ACL, we build security into our software. Secure coding best practices are strictly followed. Common application layer vulnerabilities, including all OWASP Top 10 vulnerabilities, are explicitly addressed at all stages of the SDLC using industry standard counter-measures, such as explicit sanitization of all user input, use of parameterized queries, and use of secure libraries.

All code changes are controlled and approved, and must go through strict peer review and Quality Assurance (QA) testing prior to production deployment.

Development and testing

ACL employs industry-leading development practices such as pair programming and code review, as well as continuous integration tools to perform automated testing, including static code analysis for security.

Multiple staging environments have been established to facilitate manual and automated testing. Additionally, a formalized and independent QA function has been established to perform structured testing when a feature, bug fix, or higher risk change is to be introduced into our environment.

As an agile development shop, ACL maintains processes and tools to roll back changes in case problems arise from a production deployment.

Program management and DevOps

Program management is the responsibility of our DevOps team in ACL's Canadian headquarters. This group maintains the servers (provisioning, backups, OS updates and patches, logging, and monitoring) and oversees the deployment of all changes from our Research and Development (R&D) team into production, ensuring that our change management process has been followed.

DevOps and R&D work closely together to ensure the quality of our software service, but separate responsibilities.

Segregation of duties

ACL has procedures, controls, and monitoring in place to ensure that a separation of duties exist between the define, design, built, test, and deploy phases of the software lifecycle.

ACL also utilizes 3rd party monitoring for development, test, and production to detect run-time errors, and monitor performance so multiple stakeholders are informed on deploy or error.

Workstation and laptop security controls

To maintain the security and integrity of our endpoints and data, the following key controls are implemented for all laptops and workstations in the R&D environment:

  • Full-disk encryption
  • Restricted privileged accounts
  • Continually updated virus and malware detection
  • Standardized password authentication requirements
  • VPN access
  • Remote backups

Application code repository

ACL maintains a source code repository exclusively for source code management. The source code repository is a complete copy of the source code (including all version history).

The redundant nature of our source code repository significantly reduces risk to system availability from loss of source code. This repository is backed up on a regular basis.

Change management

Management has developed policies and procedures to control and manage changes to production systems.

ACL uses segregated development, test, and production environments. All program changes are tested in a development environment, a continuous integration environment, and then formally accepted in a staging environment prior to being deployed in the production environment.

The deployment system has the capability to roll back any deployed changes so that even in the event an issue is encountered after deployment, the production application may be returned to a stable state quickly and efficiently.

Emergency change management

Emergency changes require the same testing and approval process as a standard change request. However, these activities may be performed and documented retroactive to the migration of the change to production, in order to make sure the production issue is resolved as quickly as possible.

Customer issues

Customer issues may be reported to ACL Customer Service via support ticket.

The person receiving the request will attempt to immediately address the issue or route the issue to the appropriate person and document the resolution procedures.

Customer experience issues may also be identified automatically through application layer errors. When an error occurs in an application, a programmatic notification is made which automatically generates an e-mail notification. Once the notification is received, the ticket is used to track resolution to the error.

Penetration testing

In addition to internal security testing, ACL uses 3rd party independent penetration testing to check ACL GRC for security vulnerabilities.

These tests are performed by an organization specializing in software security, and are used to probe the ACL GRC environment for vulnerabilities, such as cross-site scripting, SQL Injection, session and cookie management.

ACL ensures exploitable vulnerabilities are resolved in a timely basis based on severity and impact. A copy of the most recent penetration test report can be provided, subject to a non-disclosure agreement (NDA).

Web scans and testing

ACL utilizes an independent 3rd party security provider to perform web application scanning and automated security testing.

Weekly vulnerability scans are performed on all production applications for security flaws.

Any findings are escalated immediately and resolved timely. In the event a high risk vulnerability is identified, all other operational duties will be dropped immediately and resolution of the vulnerability will be considered the entire company's top priority.

Description of security areas tested for vulnerabilities

Security area

Description

Port discovery

Identifies and maps open ports across the production network.

Network services vulnerability scan

Discovers, identifies, and monitors network devices, finds rogue devices, or identifies unauthorized services.

Network discovery

Interrogates each service on every available port to determine exactly what software is running and how it is configured matching to the vulnerability knowledgebase for launching of service-specific tests.

Web applications vulnerability scan

Checks all HTTP services and virtual domains for the existence of potentially dangerous modules, configuration settings, CGIs, and other scripts, as well as default-installed files.

The website is then "deep crawled" including flash-embedded links and password-protected pages, to find forms and other potentially dangerous interactive elements.

These are then exercised in specific ways to disclose any application-level vulnerabilities, such as code revelation, cross-site scripting, and SQL injection.

Terminating subscriptions

When you choose to terminate your subscription, ACL will extend access to the system for an additional 30 days to copy or extract any data you wish to retain. Once you have extracted your data, you have the full ability and responsibility to delete any or all of your remaining data in the system.

Upon written request, ACL will destroy the customer system and all data content after the extract process. If 90 days has passed without written request to destroy the customer system, ACL reserves the right to destroy the customer system to regain system resources.