AL Refs: PMN05, PMN12, CON01, PMN04, GOV16, ACL21
Purpose
The information security policies set out the roles, responsibilities and requirements for managing information security. These are usually broken down by functional area like Access Control or Asset Management, and include the overall control and compliance requirements for protecting critical systems and data from unauthorized access. These should be used in conjunction with the Acceptable Use Policy that sets out the security requirements of employees specifically.
Example Information Security Policies
Responsibilities
Head of Security
Responsible for the review and update of this policy, communication to employees and third parties (as applicable), and enforcement of this policy including initiating disciplinary or other corrective action where requirements are breached. Approval of any exemptions from this policy requirements.
Security Manager
Responsible for daily oversight of the implementation of this policy, security awareness training, and raising instances of non-compliance or failures to the Head of Security.
System/Vendor Owners
The assigned owners of each third-party vendor or system used by AssuranceLab are responsible for approving, revoking, and periodically reviewing all user access to those systems.
All Employees
All employees are responsible for adhering to the requirements of this policy and reporting any observed instances of non-compliance with this policy to the Security Manager or Head of Security. All employees should encourage others to abide by this policy and remind them of the requirements when necessary.
Access Control Policy
Refs: GOV16, ACL21
Access to systems and data follows the concept of least privilege. Access should only be granted to employees or other third parties, when there is a legitimate business need. That access should be restricted to the minimum level possible without unnecessarily restricting the required business role.
Authentication and identity management
All user access is to be signed to individual employees or other third-parties that require access with a clearly labelled full name of the user. Access should be authenticated on all systems using strong password settings, multi-factor authentication, and/or single sign-on where possible.
Access approval
All access requests should be logged in JIRA and approved by the system or third-party vendor owner of that system. The request should set out the required access level and purpose or need for that access. Where access is required for new joiners, the access requirements are documented on the New Joiner Checklist.
Access revocation
Upon termination or when access is no longer required, the access should be removed by the system or third-party vendor owner as soon as it is possible to do so without adversely impacting the business requirements of the access. The revocation should be documented on the Exit Checklist in Confluence.
Periodic access review
The access to all systems should be reviewed on at least a quarterly basis to ensure there is a legitimate continued business need for the access, and to identify if there have been any failures in the access provisioning or revocation.
Privileged Access
Privileged access includes user access roles that allow the user to create or modify other user accounts, modify system or security settings, or perform other important functions that could have a major impact on AssuranceLab or its customers if the access were not handled appropriately. Privileged access should be restricted to the fewest number of employees possible, whilst maintaining business continuity in the event of key personnel being unavailable.
Segregation of Duties
Segregation of incompatible duties is applied to avoid conflicts of interest and ensure the appropriate processes are followed. The primary segregation of duties is with the software development and approval roles. It is important to ensure that all software changes are independently reviewed and approved, and no changes can be released into production without systematically requiring a second independent person to be involved. This ensures the correct change management processes are followed, mitigates the risk of a rogue employee or errors, and ensures all changes are appropriate to be migrated to production.
Network Security Policy
Refs: PMN05, GOV20
The network security policy ensures information is protected across AssuranceLab’s networks and systems. This includes the secure and reliable use of wired and wireless, public and internal networks, remote connections, and monitoring activities to detect suspicious activity and vulnerabilities.
Network Controls
- All devices are required to be registered;
- Event logging is performed to identify and enable retrospective investigation of suspicious or inappropriate network activity;
- AWS Guard Duty is used to identify and alert for potential threats;
- Strong password settings and multi-factor authentication are required for all access;
- Encryption is enforced for all connections to protect data-in-transit;
- Network access is restricted to the minimum that allows the services to run and be used as required;
- Firewalls are used at all connectivity points and limit inbound and outbound traffic to what is appropriate by design; and
- Network components including the firewall configurations, event logs, and other security configurations above, are reviewed at least quarterly to ensure compliance with this policy and corrective actions or improvements where applicable.