Restrictions must be placed on access to the program’s source code. Access to program source code and associated items (such as designs, specifications, verification plans and validation plans) should be strictly controlled. There should be strong controls on who has access to program source code and related materials (such as designs, specifications, verification plans, and validation plans). If a program’s source code is not appropriately safeguarded, an attacker has a strong opportunity to gain access to the system in a covert manner. This is especially true if the source code is critical to the company’s success. Program source code can be vulnerable to attack if not adequately protected and can provide an attacker with a good means to compromise systems in an often covert manner. If the source code is central to the business success it’s loss can also destroy the business value quickly too.

Control

Read and write access to source code, development tools and software libraries should be appropriately managed.

Purpose

To prevent the introduction of unauthorized functionality, avoid unintentional or malicious changes and to maintain the confidentiality of valuable intellectual property.

ISO 27002 Implementation Guidance

Access to source code and associated items (such as designs, specifications, verification plans and validation plans) and development tools (e.g. compilers, builders, integration tools, test platforms and environments) should be strictly controlled. For source code, this can be achieved by controlling central storage of such code, preferably in source code management system. Read access and write access to source code can differ based on the personnel’s role. For example, read access to source code can be broadly provided inside the organization, but write access to source code is only made available to privileged personnel or designated owners. Where code components are used by several developers within an organization, read access to a centralized code repository should be implemented. Furthermore, if open-source code or third-party code components are used inside an organization, read access to such external code repositories can be broadly provided. However, write access should still be restricted. The following guidelines should be considered to control access to program source libraries in order to reduce the potential for corruption of computer programs:

1. managing the access to program source code and the program source libraries according to established procedures;
2. granting read and write access to source code based on business needs and managed to address risks of alteration or misuse and according to established procedures;
3. updating of source code and associated items and granting of access to source code in accordance with change control procedures and only performing it after appropriate authorization has been received;
4. not granting developers direct access to the source code repository, but through developer tools that control activities and authorizations on the source code;
5. holding program listings in a secure environment, where read and write access should be appropriately managed and assigned;
6. maintaining an audit log of all accesses and of all changes to source code.

If the program source code is intended to be published, additional controls to provide assurance on its integrity (e.g. digital signature) should be considered.

Other information

If access to source code is not properly controlled, source code can be modified or some data in the development environment (e.g. copies of production data, configuration details) can be retrieved by unauthorized persons.

Organizations must confirm that there is appropriate segregation of duties between the staff responsible for moving a program into production and the staff responsible for developing a program. In addition, organizations must consider whether or not changes are performed in a segregated and controlled environment. To fulfill this requirement, administrators must ensure that logins to source code repositories and the permissions assigned to these users are appropriate for the tasks that they are allowed to perform. Users with overlapping permission sets should indicate a compromise in the segregation of duties control consideration. Administrators should also review the process to request and grant access to systems and data and confirm that the same person does not perform these functions.To prevent the introduction of unauthorized functionality and to avoid unintended changes, and to maintain the confidentiality of valuable intellectual property, it is necessary to strictly control access to source code and related items (such as designs, specifications, verification plans, and validation plans). For program source code, this can be achieved by controlling the central storage of such code, preferably in program source libraries. In order to minimize the potential for misuse of computer applications, the following guidelines will then be considered to control access to these source libraries:

• Where appropriate, software source libraries should not be kept in operating systems;
• The source code of the program and the source library of the program should be administered according to procedures;
• Support staff should have restricted access to program source libraries;
• The updating of program source libraries and related objects, and therefore the issuing of software sources to programmers, should be carried out only after sufficient authorization has been received;
• The program listings should be stored in a safe environment;
• The audit log of all accesses to program source libraries should be maintained;
• Strict change control procedures may refer to the management and copying of software source libraries.

A source code management system that allows organisations to centrally administer access to and their amendment of source code across its ICT estate. It asks organisations to consider access to source code along a set of strict read and/or write privileges, based on the nature of the source code, where it’s being accessed from, and who is accessing it. When seeking to control access to source code, organisations should:

• Control access to source code in line with published procedures.
• Provide read and/or write access to source code in conjunction with a set of clearly defined business requirements on a case-by-case or user-by-user basis.
• Adhere to a clear set of change management procedures  when administering access to source code, including proper authorization based on a range of access variables (user type, business case etc).
• Prevent the direct access of source code by developers, and instead provision access through a series of development tools that provide a top-down view of access rights and read/write privileges.
• Provision a secure space to store program listings and read/write privileges.
• Maintain a concurrent audit trail of all source code related activities, including user access timestamps and change-related activities.
• Ensure that digital signatures are used for any piece of code that is to be published outside of the organisation.

Securing Source Code

1. Create a source code protection policy
Set up a source code protection policy by defining a set of rules, requirements, and procedures for handling and protecting code. This policy will help safeguard software and devices from threats such as reverse engineering and code tampering. It should also cover source code development processes and personnel involved in code development. Include secure access and use of source code repositories. Your source code protection policy should also involve documentation and training on secure coding practices and the incorporation of secure development methodologies into the software development lifecycle (SDLC).

2. Prevent the use of insecure source code
Use source code security analysis tools, such as Static Application Security Testing (SAST), to detect security flaws and other issues during development.

3. Access control
Define who’s allowed to access source code, code base and source code repositories. There’s little to no reason that anyone other than hands-on employees work with your source code, but even for those that do, set up two-factor authentication. In this way, you can ensure that no suspicious characters find their way into your source code. Through authentication and authorization, access control policies ensure that users are who they say they are and that they have appropriate access to company data.

4. Use encryption and monitoring
Make sure you have the ability to encrypt sensitive data both in transit and at rest. It’s also important to monitor your data at all times and be alerted when any suspicious activity comes to light. In this way, you can be ready to act swiftly, whether it is about tracking, limiting, or reversing the damage. You can also prevent it before any actual harm happens.

4. Deploy network security tools
Implementing network security solutions such as firewalls, Virtual Private Networks (VPN), anti-virus, and anti-malware software count as basic protection. These solutions safeguard your source code from external exploits of hackers and ensure secure data sharing between employees and data sources.

5. Don’t forget about endpoint security
Secure your endpoints or entry points of end-user devices such as desktops and laptops from risky activities and malicious attacks with endpoint security software. Data Loss Prevention (DLP) solutions can efficiently prevent your source code from leaving the endpoint and stop source code ex filtration. These tools can protect sensitive information both in physical and virtual environments, regardless of the endpoint’s physical location and whether it’s connected to the internet or not.

7 Pay attention to patents & copyright
Make sure that all your concepts and inventions related to software are protected by copyright law and necessary patents. A major difference between these two is that while patents protect the idea, copyright safeguards the written code. As software-related inventions are increasingly popular, you should treat this proprietary information just like other intellectual property.

Access to information and application system functions shall be restricted in accordance with the access control policy. There should be a complete description of the restriction applied to certain authorities under control access policies.Control on access should be applied complying to the stated access control policy and based on business application requirements. The organization can be controlling access to application system functionalities through menus and be limiting the data that a specific user has access to. User access privileges, such as read, write, delete, and execute control needs to be applied and also controlling other applications’ access rights. It must reduce the amount of data in outputs and there must be physical or logical access control to isolate sensitive applications, application data, and systems from the rest of the network.

Control

Access to information and other associated assets should be restricted in accordance with the established topic-specific policy on access control.

Purpose

To ensure only authorized access and to prevent unauthorized access to information and other associated assets.

ISO 270012 Implementation Guidance

Access to information and other associated assets should be restricted in accordance with the established topic-specific policies. The following should be considered in order to support access restriction requirements:

1. not allowing access to sensitive information by unknown user identities or anonymously. Public or anonymous access should only be granted to storage locations that do not contain any sensitive information;
2. providing configuration mechanisms to control access to information in systems, applications and services;
3. controlling which data can be accessed by a particular user;
4. controlling which identities or group of identities have which access, such as read, write, delete and execute;
5. providing physical or logical access controls for the isolation of sensitive applications, application data, or systems.

Further, dynamic access management techniques and processes to protect sensitive information that has high value to the organization should be considered when the organization:

1. needs granular control over who can access such information during what period and in what way;
2. wants to share such information with people outside the organization and maintain control over who can access it;
3. wants to dynamically manage, in real-time, the use and distribution of such information;
4. wants to protect such information against unauthorized changes, copying and distribution (including printing);
5. wants to monitor the use of the information;
6. wants to record any changes to such information that take place in case a future investigation is required.

Dynamic access management techniques should protect information throughout its life cycle (i.e. creation, processing, storage, transmission and disposal), including:
a) establishing rules on the management of dynamic access based on specific use cases considering:

1. granting access permissions based on identity, device, location or application;
2. leveraging the classification scheme in order to determine what information needs to be protected with dynamic access management techniques;

b) establishing operational, monitoring and reporting processes and supporting technical infrastructure.

Dynamic access management systems should protect information by:

1. requiring authentication, appropriate credentials or a certificate to access information;
2. restricting access, for example to a specified time frame (e.g. after a given date or until a particular date);
3. using encryption to protect information;
4. defining the printing permissions for the information;
5. recording who accesses the information and how the information is used;
6. raising alerts if attempts to misuse the information are detected.

Other information

Dynamic access management techniques and other dynamic information protection technologies can support the protection of information even when data is shared beyond the originating organization, where traditional access controls cannot be enforced. It can be applied to documents, emails or other files containing information to limit who can access the content and in what way. It can be at a granular level and be adapted over the life cycle of the information. Dynamic access management techniques do not replace classical access management [e.g. using access control lists (ACLs)], but can add more factors for conditionality, real-time evaluation, just-in-time data reduction and other enhancements that can be useful for the most sensitive information. It offers a way to control access outside the organization’s environment. Incident response can be supported by dynamic access management techniques as permissions can be modified or revoked at any time. Additional information on a framework for access management is provided in ISO 29146.

In order to maintain effective control over information and ICT assets, and in support of access restriction measures, organisations should ensure the following in line with a topic-specific approach to information access:

1. Prevent anonymous access to information, including far-reaching public access. Where public or third-party access is granted, organisations should ensure that access does not extend to sensitive or business critical data.
2. Operate with adequate maintenance measures that control systems access, and any associated business applications or processes.
3. Dictate data access on a user-by-user basis.
4. Specify data access rights between groups that validate specific data operations, such as read, write, delete and execute.
5. Retain the ability to partition off business critical processes and applications using a range of physical and digital access controls.

Dynamic Access Control enables administrators to apply access-control permissions and restrictions based on well-defined rules that can include the sensitivity of the resources, the job or role of the user, and the configuration of the device that is used to access these resources. For example, a user might have different permissions when they access a resource from their office computer versus when they are using a portable computer over a virtual private network. Or access may be allowed only if a device meets the security requirements that are defined by the network administrators. When Dynamic Access Control is used, a user’s permissions change dynamically without additional administrator intervention if the user’s job or role changes

Dynamic access management has numerous residual benefits for organisational processes that feature the need to share or use internal data with external users, including faster incident resolution times. Dynamic access management techniques protect a broad range of information types, from standard documents to emails and database information, and have the ability to be applied on a granular file-by-file basis, enabling tight control of data on an organisational level. Organisation’s should consider such an approach when:

1. Requiring granular control over what human and non-human users are able to access such information at any given time.
2. The need arises to share information with external parties (such as suppliers or regulatory bodies).
3. Considering a “real-time” approach to data management and distribution that involves monitoring and managing data use as it occurs.
4. Safeguarding information against unauthorised amendments, sharing or output (printing etc).
5. Monitoring the access to and changing of information, particularly when the information in question is of a sensitive nature.

Dynamic access management is of particular use for organisations that need to monitor and protect data from creation through to deletion, including:

1. Outlining a use case (or series of use cases) that apply data access rules based on the following variables:
   • Identity
   • Device
   • Location
   • Application
2. Outlining a process that covers off the operation and monitoring of data, and establishing a thorough reporting process which is in turn informed by a sound technical infrastructure.

All efforts to formulate a dynamic access management approach should result in data being protected by:

1. Ensuring that access to data is the end result of a successful authentication process.
2. A degree of restricted access, based on the data type and its ability impact business continuity.
3. Encryption.
4. Printing permissions.
5. Thorough audit logs that record who access data, and how that data is being used.
6. An alerts procedure that flags up inappropriate data use, including (but not limited to) unauthorized access and distribution, and attempted deletion.

Features and concepts associated with Dynamic Access Management include:

1. Central access rules
A central access rule is an expression of authorization rules that can include one or more conditions involving user groups, user claims, device claims, and resource properties. Multiple central access rules can be combined into a central access policy. If one or more central access rules have been defined , administrators can match specific rules to specific resources and business requirements.

2. Central access policies
Central access policies are authorization policies that include conditional expressions. For example, let’s say an organization has a business requirement to restrict access to personally identifiable information (PII) in files to only the file owner and members of the human resources (HR) department who are allowed to view PII information. This represents an organization-wide policy that applies to PII files wherever they are located on file servers across the organization. To implement this policy, an organization needs to be able to:

• Identify and mark the files that contain the PII.
• Identify the group of HR members who are allowed to view the PII information.
• Add the central access policy to a central access rule, and apply the central access rule to all files that contain the PII, wherever they are located amongst the file servers across the organization.

Central access policies act as security umbrellas that an organization applies across its servers. These policies are in addition to (but do not replace) the local access policies or discretionary access control lists (DACLs) that are applied to files and folders.

3. Claims
A claim is a unique piece of information about a user, device, or resource that has been published by a domain controller. The user’s title, the department classification of a file, or the health state of a computer are valid examples of a claim. An entity can involve more than one claim, and any combination of claims can be used to authorize access to resources.Claims make it possible for administrators to make precise organization- or enterprise-wide statements about users, devices, and resources that can be incorporated in expressions, rules, and policies.

4. Expressions
Conditional expressions are an enhancement to access control management that allow or deny access to resources only when certain conditions are met, for example, group membership, location, or the security state of the device. Expressions help administrators manage access to sensitive resources with flexible conditions in increasingly complex business environments.

5. Proposed permissions
Proposed permissions enable an administrator to more accurately model the impact of potential changes to access control settings without actually changing them. Predicting the effective access to a resource helps you plan and configure permissions for those resources before implementing those changes.

Privileged access allows organizations to secure their infrastructure and applications, run business efficiently and maintain the confidentiality of sensitive data and critical infrastructure.Privilege can be defined as the authority a given account or process has within a computing system or network. Privilege provides the authorization to override, or bypass, certain security restraints, and may include permissions to perform such actions as shutting down systems, loading device drivers, configuring networks or systems, provisioning and configuring accounts and cloud instances, etc.Privileges serve an important operational purpose by enabling users, applications, and other system processes elevated rights to access certain resources and complete work-related tasks. Privileged access can be associated with human users as well as non-human users such as applications and machine identities. Privileges for various user accounts and processes are built into operating systems, file systems, applications, databases, hypervisors, cloud management platforms, etc. Privileges can be also assigned by certain types of privileged users, such as by a system or network administrator.Depending on the system, some privilege assignment, or delegation, to people may be based on attributes that are role-based, such as business unit, (e.g., marketing, HR, or IT) as well as a variety of other parameters (e.g., seniority, time of day, special circumstance, etc.).Malicious or incorrect use of elevated system administrator privileges is one of the major causes of ICT disruption across commercial networks all over the world. Privileged access rights allows organisations to control access to their infrastructure, applications, assets and maintain the integrity of all stored data and systems. Special access to data and systems requires strict controls on who gets it and how it’s used because of the additional power it gives the person who has it. System by system clarity on privileged access permissions (which can be modified within the program) could fall under this category, as well as allocation based on actual usage rather than a blanket policy. All privileges issued to users should be documented, and the competency of those users granted the permissions must be constantly evaluated to ensure that they are able to perform their assigned responsibilities. It’s also a good idea to keep separate identities for system administrators and regular users, especially if they’re doing various jobs on the same platform.

Control

The allocation and use of privileged access rights should be restricted and managed.

Purpose

To ensure only authorized users, software components and services are provided with privileged access rights.

ISO 27002 Implementation Guidance

The allocation of privileged access rights should be controlled through an authorization process in accordance with the relevant topic-specific policy on access control. The following should be considered:

• identifying users who need privileged access rights for each system or process (e.g. operating systems, database management systems and applications);
• allocating privileged access rights to users as needed and on an event-by-event basis in line with the topic-specific policy on access control (i.e. only to individuals with the necessary competence to carry out activities that require privileged access and based on the minimum requirement for their functional roles);
• maintaining an authorization process (i.e. determining who can approve privileged access rights, or not granting privileged access rights until the authorization process is complete) and a record of all privileges allocated;
• defining and implementing requirements for expiry of privileged access rights;
• taking measures to ensure that users are aware of their privileged access rights and when they are in privileged access mode. Possible measures include using specific user identities, user interface settings or even specific equipment;
• authentication requirements for privileged access rights can be higher than the requirements for normal access rights. Re-authentication or authentication step-up can be necessary before doing work with privileged access rights;
• regularly, and after any organizational change, reviewing users working with privileged access rights in order to verify if their duties, roles, responsibilities and competence still qualify them for working with privileged access rights;
• establishing specific rules in order to avoid the use of generic administration user IDs (such as “root”), depending on systems’ configuration capabilities. Managing and protecting authentication information of such identities ;
• granting temporary privileged access just for the time window necessary to implement approved changes or activities (e.g. for maintenance activities or some critical changes), rather than permanently granting privileged access rights. This is often referred as break glass procedure, and often automated by privilege access management technologies;
• logging all privileged access to systems for audit purposes;
• not sharing or linking identities with privileged access rights to multiple persons, assigning each person a separate identity which allows assigning specific privileged access rights. Identities can be grouped (e.g. by defining an administrator group) in order to simplify the management of privileged access rights;
• only using identities with privileged access rights for undertaking administrative tasks and not for day-to-day general tasks [i.e. checking email, accessing the web (users should have a separate normal network identity for these activities)].

Other information

Privileged access rights are access rights provided to an identity, a role or a process that allows the performance of activities that typical users or processes cannot perform. System administrator roles typically require privileged access rights. Inappropriate use of system administrator privileges (any feature or facility of an information system that enables the user to override system or application controls) is a major contributory factor to failures or breaches of systems. More information related to access management and the secure management of access to information and information and communications technologies resources can be found in ISO 29146.

The allocation and use of privileged access rights has to be tightly controlled given the extra rights usually conveyed over information assets and the systems controlling them. For example the ability to delete work or fundamentally affect the integrity of the information. It should align with the formal authorization processes alongside the access control policy. That could include; system by system clarity on privileged access rights (which can be managed inside the application); allocation on a need-to-use basis not a blanket approach; A process and record of all privileges allocated should be maintained (alongside the information asset inventory or as part of the evidence and the competence of users granted the rights must be reviewed regularly to align with their duties. This is another good area to include in the internal audit to demonstrate control. One of the biggest contributory factors to failures or breaches of systems is inappropriate and blanket use of system administration privileges with human error leading to more damage or loss than if a ‘least access’ approach were taken. Other good practice relating to this area includes the separation of the systems administrator role from the day to day user role and having a user with two accounts if they perform different jobs on the same platform. Organisations should:

• Identify a list of users who require any degree of privileged access – either for an individual system – such as a database – application, or underlying OS.
• Maintain a policy that allocates privileged access rights to users on what is known as an “event by event basis” – users should be granted levels of access based on the bare minimum that is required for them to carry out their role.
• Outlining a clear authorization process that deals with all requests for privileged access, including keeping a record of all access rights that have been implemented.
• Ensure that access rights are subject to relevant expiry dates.
• Take steps to ensure that users are explicitly aware of any period of time where they are operating with privileged access to a system.
• Where relevant, users are asked to re-authenticate prior to using privileged access rights, in order to affect greater information/data security.
• Carry out periodic audits of privileged access rights, especially following a period of organisational change. Users’ access rights should be reviewed based upon their “duties, roles, responsibilities and competence” (see Control 5.18).
• Consider operating with what’s known as a “break glass” procedure – i.e. ensuring that privileged access rights are granted within tightly-controlled time windows that meet the minimum requirements for an operation to be carried out (critical changes, system administration etc).
• Ensure that all privileged access activities are logged accordingly.
• Prevent the use of generic system login information (especially standardized usernames and passwords)
• Keep to a policy of assigning users with a separate identity, that allows for tighter control of privileged access rights. Such identities can then be grouped together, with the associated group being provided differing levels of access rights.
• Ensure that privileged access rights are reserved for critical tasks only, that relate to the continued operation of a functioning ICT network – such as system administration and network maintenance.

Management of Privileged access right involves a combination of tools and technology used to secure, control and monitor access to an organization’s critical information and resources.It is one of the best ways for an organization to protect against external threats by preventing malicious parties from accessing sensitive corporate data through internal accounts. It helps organizations effectively monitor the entire network and provides insight into which users have access to what data. is critical because privileged accounts can pose major security risks to businesses. For example, a cyber criminal who compromises a standard user account will only have access to that specific user’s information. But a hacker who compromises a privileged user account will have far greater access and possibly the power to destroy systems. In addition to combating external attacks, It can help companies combat threats — either malicious or inadvertent — originating from employees and other internal people with access to corporate data. It is also key to achieve compliance with industry and government regulations. As a part of a complete security program, enterprises can record and log every activity related to their critical information technology (IT) infrastructures and sensitive corporate data, helping to simplify audit and compliance requirements.

Some of the top privilege-related risks and challenges include:

1. Lack of visibility and awareness of of privileged users, accounts, assets, and credentials. Long-forgotten privileged accounts are commonly sprawled across organizations. These may number in the millions, and provide dangerous backdoors for attackers, including, former employees who have left the company but retain access.
2. Over-provisioning of privileges. If privileged access controls are overly restrictive, they can disrupt user workflows, causing frustration and hindering productivity. Since end users rarely complain about possessing too many privileges, IT admins traditionally provision end users with broad sets of privileges. Additionally, an employee’s role is often fluid and can evolve such that they accumulate new responsibilities and corresponding privileges—while still retaining privileges that they no longer use or require. All this privilege excess adds up to a bloated attack surface. Routine computing for employees on personal PC users might entail internet browsing, watching streaming video, use of MS Office and other basic applications, including SaaS (e.g., Salesforce.com, GoogleDocs, Slack, etc.). In the case of Windows PCs, users often log in with administrative account privileges—far broader than what is needed. These excessive privileges massively increase the risk that malware or hackers may steal passwords or install malicious code that could be delivered via web surfing or email attachments. The malware or hacker could then leverage the entire set of privileges of the account, accessing data of the infected computer, and even launching an attack against other networked computers or servers.
3. Shared accounts and passwords. IT teams commonly share root, Windows Administrator, and many other privileged credentials for convenience so workloads and duties can be seamlessly shared as needed. However, with multiple people sharing an account password, it may be impossible to tie actions performed with an account to a single individual. This creates security, audit, and compliance issues.
4. Hard-coded / embedded credentials. Privileged credentials are needed to needed facilitate authentication for app-to-app (A2A) and application-to-database (A2D) communications and access. Applications, systems, network devices, and IoT devices may be shipped and o deployed with embedded, default credentials that are easily guessable and pose substantial risk. Additionally, employees will often hardcode secrets in plain text—such as within a script, code, or a file, so it is easily accessible when they need it.
5. Manual and/or decentralized credential management. Privilege security controls are often immature. Privileged accounts and credentials may be managed differently across various organizational silos, leading to inconsistent enforcement of best practices. Human privilege management processes cannot possibly scale in most IT environments where thousands—or even millions—of privileged accounts, credentials, and assets can exist. With so many systems and accounts to manage, humans invariably take shortcuts, such as re-using credentials across multiple accounts and assets. One compromised account can therefore jeopardize the security of other accounts sharing the same credentials.
6. Lack of visibility into application and service account privileges. Applications and service accounts often automatically execute privileged processes to perform actions, as well as to communicate with other applications, services, resources, etc. Applications and service accounts frequently possess excessive privileged access rights by default, and also suffer from other serious security deficiencies.
7. Multiple identity management tools and processes. Modern IT environments typically run across multiple platforms (e.g., Windows, Mac, Unix, Linux) and environments (on-premises, Azure, AWS, Google Cloud)—each separately maintained and managed. This practice equates to inconsistent administration for IT, added complexity for end users, and increased cyber risk.

Privileged Access Right Best Practices

1. Establish and enforce a comprehensive privilege management policy: The policy should govern how privileged access and accounts are provisioned/de-provisioned; address the inventory and classification of privileged identities and accounts; and enforce best practices for security and management.
2. Identify and bring under management all privileged accounts and credentials: Privileged account discovery should include all user and local accounts; application and service accounts database accounts; cloud and social media accounts; SSH keys; default and hard-coded passwords; and other privileged credentials – including those used by third parties/vendors. Discovery should also include platforms (e.g., Windows, Unix, Linux, Cloud, on-prem, etc.), directories, hardware devices, applications, services / daemons, firewalls, routers, etc.The privilege discovery process should illuminate where and how privileged passwords are being used, and help reveal security blind spots and malpractice.
3. Enforce least privilege over end users, endpoints, accounts, applications, services, systems, etc.: A key piece of a successful least privilege implementation involves wholesale elimination of privileges everywhere they exist across your environment. Then, apply rules-based technology to elevate privileges as needed to perform specific actions, revoking privileges upon completion of the privileged activity. Ensuring true least privilege is not just about enforcing constraints on the breadth of access, but also on the duration of access. In IT security terms, this means implementing controls that provide just enough access (JEA) and just-in-time (JIT) access.

Every employee within your organisation will need to have access to certain computers, databases, information systems, and applications to perform their tasks. While human resources personnel may need access to sensitive health data of employees, your finance department may rely on accessing and using databases containing employee salary details. However, these access rights should be provided, modified, and revoked in line with your organisation’s access control policy and its access controls so that you can prevent unauthorized access to, modification of, and destruction of information assets. For instance, if you fail to revoke the access rights of a former employee, that employee may steal sensitive information. This control deals with how organisations should assign, modify and revoke access rights taking into account business requirements. While provisioning of access rights to critical information seems to be the first of a user stepping into the system, it is recommended to review, modify, and if necessary, delete the access right of the user in a long run. This is a common mistake of organisations that do not or forget to review and modify users’ access rights, which facilitates the ground for numerous information security incidents to happen. For instance, disgruntled employees degrading from a higher position to a lower position in an organisation could cause damage to critical information that they have access to using their escalated access rights. Similarly, an attacker might target sensitive information of the organisation utilizing a person with a lower position but escalated access rights within the organisation. Therefore, access rights provisioning, reviewing, modifying, and deleting within the access control policy is a considerable aspect of the organisation.

Control

Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.

Purpose

To ensure access to information and other associated assets is defined and authorized according to the business requirements.

ISO 27002 Implementation Guidance

Provision and revocation of access rights

The provisioning process for assigning or revoking physical and logical access rights granted to an entity’s authenticated identity should include:
a) obtaining authorization from the owner of the information and other associated assets for the use of the information and other associated assets. Separate approval for access rights by management can also be appropriate;
b) considering the business requirements and the organization’s topic-specific policy and rules on access control;
c) considering segregation of duties, including segregating the roles of approval and implementation of the access rights and separation of conflicting roles;
d) ensuring access rights are removed when someone does not need to access the information and other associated assets, in particular ensuring access rights of users who have left the organization are removed in a timely fashion;
e) considering giving temporary access rights for a limited time period and revoking them at the expiration date, in particular for temporary personnel or temporary access required by personnel;
f) verifying that the level of access granted is in accordance with the topic-specific policies on access control and is consistent with other information security requirements such as segregation of duties;
g) ensuring that access rights are activated (e.g. by service providers) only after authorization procedures are successfully completed;
h) maintaining a central record of access rights granted to a user identifier (ID, logical or physical) to access information and other associated assets;
i) modifying access rights of users who have changed roles or jobs;
j) removing or adjusting physical and logical access rights, which can be done by removal, revocation or replacement of keys, authentication information, identification cards or subscriptions;
k) maintaining a record of changes to users’ logical and physical access rights.

Review of access rights

Regular reviews of physical and logical access rights should consider the following:
a) users’ access rights after any change within the same organization (e.g. job change, promotion, demotion) or termination of employment ;
b) authorizations for privileged access rights.

Consideration before change or termination of employment

A user’s access rights to information and other associated assets should be reviewed and adjusted or removed before any change or termination of employment based on the evaluation of risk factors such as:
a) whether the termination or change is initiated by the user or by management and the reason for termination;
b) the current responsibilities of the user;
c) the value of the assets currently accessible.

Other information

Consideration should be given to establishing user access roles based on business requirements that summarize a number of access rights into typical user access profiles. Access requests and reviews of access rights are easier managed at the level of such roles than at the level of particular rights. Consideration should be given to including clauses in personnel contracts and service contracts that specify sanctions if unauthorized access is attempted by personnel. In cases of management-initiated termination, disgruntled personnel or external party users can deliberately corrupt information or sabotage information processing facilities. In cases of persons resigning or being dismissed, they can be tempted to collect information for future use. Cloning is an efficient way for organizations to assign access to users. However, it should be done with care based on distinct roles identified by the organization rather than just cloning an identity with all associated access rights. Cloning has an inherent risk of resulting in excessive access rights to information and other associated assets.

All staff has a broad constituency with varying degrees of affiliation with the organization. One thing in common among all staff is that all require access to some type of organizational information for a determined period of time – they all become Users. At a high level, organizations can divide Users into two groups based on their type of affiliation with the organization:

• Formal Affiliation: These are Users whose affiliation to the organization is established by some kind of contract or agreement. Users in this group include staff members, employees, vendors, clients, and Management.
• Casual Affiliation: These are Users whose affiliation to the organization is transitory, periodic, mostly informational and not established by a contract or agreement. Users in this group include guests, retirees, the relative of employees, visitors for the website, etc.

Organisation must establish and implement appropriate procedures and controls to assign, modify and revoke access rights to information systems in compliance with the organisation’s access control policy and its access controls. An Information security officer should be responsible to establish, implement and review appropriate rules, processes, and controls for provision, modification and revocation of access rights to information systems. When assigning, modifying, and revoking access rights, the information security officer should consider business needs and should closely work with information asset owners to ensure that rules and processes are adhered to.

Provision and revocation of access rights

A process (however simple and documented) must be implemented to assign or revoke access rights for all user types to all systems and services. It s the set of processes for managing user attributes and policies that determine a user’s access rights to an information resource. In other words, what user attributes, job functions, and organizational affiliations can serve as the basis for access authorization decisions. Users should be granted the least privilege – the most restrictive set of permissions or access rights – needed to perform assigned work tasks. Two common problems are an excessive privilege and creeping privilege. The former happens when a user has more access or permissions than the assigned work tasks and/or role requires. The latter happens when a user account accumulates privileges over time as roles and assigned work tasks to change. Both problems are addressed by periodic review of user access rights. Management of Administrative privileges is particularly important since very common cyber-attack techniques take advantage of unmanaged administrative privileges. An attacker can trick a user into downloading an application from a malicious website or opening a malicious email attachment which contains executable code that installs and runs on the user’s device. In cases where users have administrative rights to their devices, the attacker can take over the device and install keystroke loggers, sniffers, etc. to find administrator passwords and other confidential data. Another common attack involves domain administration privileges in Windows environments potentially giving an attacker significant control over numerous devices and access to the data they contain.Provisioning and revoking process should include:

• Authorization from the owner of the information system or service for the use of the information system or service;
• Verifying that the access granted is relevant to the role being done;
• protecting against provisioning being done before authorization is complete.

User access should always be business led and access based around the requirements of the business. This might sound bureaucratic but it doesn’t need to be and effective simple procedures with role based access by systems and services can address it. Organisations should incorporate the following rules and controls into the process for assignment and revocation of access rights to an authenticated individual:

• Information asset owner should provide its authorization for access to and use of relevant information assets. Furthermore, organisations should also consider seeking separate approval from the management for granting access rights.
• Business needs of the organisation and its policy on access control should be taken into account.
• Organisations should consider segregating duties. For instance, the approval task and the implementation of access rights can be performed by separate individuals.
• When an individual no longer needs access to information assets, particularly when they are no longer part of the organisation, their access rights should be revoked immediately.
• Personnel or other staff working for the organisation temporarily can be provided with temporary access rights. These rights should be revoked when they no longer work for the organisation.
• Level of access provided to an individual should be in line with the organisation’s access control policy and should be reviewed and verified regularly. Furthermore, it should also be in accordance with other information security requirements such as segregation of duties as set out in Control 5.3.
• Organisations should ensure that access rights are not activated until the appropriate authorization procedure is completed.
• Access rights provided to each individual identifier, such as ID or physical, should be logged onto a central access control management system and this system should be maintained.
• If an individual’s role or duties change, their level of access rights should be updated.
• Removal or modification of physical or logical access rights can be carried out via the following methods: Removal or replacement of keys, ID cards, or authentication information.
• Changes to a user’s physical and logical access rights should be logged onto a system and should be maintained.

Review of Access Rights

Some data, due to its nature or confidentiality requirements, may be restricted from general access by users and may require additional levels of formal approval before being made available. Users are granted access to these data on a need-to-know basis – when there are justified work-related reasons for access or need to know. An important characteristic of need-to-know access is the access is granted for a limited period of time. When the reasons for access are no longer valid, access to the data is (or should be) revoked. Least privilege and need-to-know access underscore the importance of the periodic review of user accounts and their corresponding access rights. Dormant user accounts – active user accounts that show no activity for very long periods of time – poses an unnecessary risk for unauthorized access to confidential data. The periodic review of user accounts and corresponding access rights with system owners, disabling user accounts after a preset period of inactivity, purging them after a longer period of inactivity are all good practices to ensure that a system does not contain old, unused user accounts and to mitigate risk. Asset owners must review users’ access rights at regular intervals, both around individual change (on-boarding, change of role and exit) as well broader audits of the systems access. Authorizations for privileged access rights should be reviewed at more frequent intervals given their higher risk nature. This ties in with for internal audits and should be done at least annually or when major changes take place. Physical and logical access rights should go through periodic reviews taking into account:

• Changes in each user’s access rights after they are promoted or demoted within the same organisation, or after their employment is terminated.
• Authorization procedure for granting privileged access rights.

Change or Termination of Employment
Before an employee is promoted or demoted within the same organisation or when his/her employment is terminated, his/her access rights to information processing systems should be evaluated and modified by taking into account the following risk factors:

• Whether the termination process is initiated by the employee or by the organisation and the reason for termination.
• Current responsibilities of the employee within the organisation.
• Criticality and value of information assets accessible to the employee.

All access rights to information and information processing facilities must be revoked following termination of employment, contract, or agreement, as specified in the preceding paragraph (or adjusted upon change of role if required).

Supplementary Guidance
Organisations should consider establishing user access roles based on their business requirements. These roles should include the types and number of access rights to be granted to each user group. Creating such roles will make it easier to manage and review access requests and rights. Organisations should include contractual provisions for unauthorized access and sanctions for such access in their employment/service contracts with their staff. Organisations should be cautious against disgruntled employees who are laid off by the management because they may damage information systems on purpose. If organisations decide to use the cloning techniques to grant access rights, they should perform it on the basis of distinct roles established by the organisation. It should be noted that cloning comes with the inherent risk of granting excessive access rights.

Authentication information such as passwords, encryption keys, and card chips are the gateway to information systems that host sensitive information assets.Poor management or improper allocation of authentication information may result in unauthorized access to information systems and in loss of confidentiality, availability, and integrity of sensitive information assets.Research shows that 30% of all data breaches occur as a result of weak passwords or poor password management practices.Therefore, organisations should have a robust authentication information management process in place to allocate, manage and protect authentication information. Organisations must properly allocate and manage authentication information, eliminate risks of failure in the authentication process and prevent security risks that may arise due to compromise of authentication information.Authentication management is an important practice for an organisation. One of the most effective methods of information security breaches is the circumvention of the authentication process. Therefore, it is crucial that organisation considers aspects such as:

• Non Guessable, Unique Password and Personal Identification number (PINS) generated automatically.
• Procedure to identify and verify the temporary and permanent Authentication Methods
• Authentication Information Transferred to a secure location using a secure manner.
• Dodgy Authentication Devices and methods to be removed from the system.

It is beneficial for the organization to record the details of authentication methods in a well-structured document. Identifying the responsibilities of the users and all relevant authentication methods.

Control

Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information.

Purpose

To ensure proper entity authentication and prevent failures of authentication processes.

ISO 27001 Implementation Guidance

Allocation of authentication information

The allocation and management process should ensure that:
a) personal passwords or personal identification numbers (PINs) generated automatically during enrollment processes as temporary secret authentication information are non-guessable and unique for each person, and that users are required to change them after the first use;
b) procedures are established to verify the identity of a user prior to providing new, replacement or temporary authentication information;
c) authentication information, including temporary authentication information, is transmitted to users in a secure manner (e.g. over an authenticated and protected channel) and the use of unprotected (clear text) electronic mail messages for this purpose is avoided;
d) users acknowledge receipt of authentication information;
e) default authentication information as predefined or provided by vendors is changed immediately following installation of systems or software;
f) records of significant events concerning allocation and management of authentication information are kept and their confidentiality is granted, and that the record-keeping method is approved (e.g. by using an approved password vault tool).

User responsibilities

Any person having access to or using authentication information should be advised to ensure that:
a) secret authentication information such as passwords are kept confidential. Personal secret authentication information is not to be shared with anyone. Secret authentication information used in the context of identities linked to multiple users or linked to non-personal entities are solely shared with authorized persons;
b) affected or compromised authentication information is changed immediately upon notification of or any other indication of a compromise;
c) when passwords are used as authentication information, strong passwords according to best practice recommendations are selected, for example:

• passwords are not based on anything somebody else can easily guess or obtain using person- related information (e.g. names, telephone numbers and dates of birth);
• passwords are not based on dictionary words or combinations thereof;
• use easy to remember passphrases and try to include alphanumerical and special characters;
• passwords have a minimum length;

d) the same passwords are not used across distinct services and systems;
e) the obligation to follow these rules is also included in terms and conditions of employment .

Password management system

When passwords are used as authentication information, the password management system should:
a) allow users to select and change their own passwords and include a confirmation procedure to address input errors;
b) enforce strong passwords according to good practice recommendations of “User responsibilities;
c) force users to change their passwords at first login;
d) enforce password changes as necessary, for example after a security incident, or upon termination or change of employment when a user has known passwords for identities that remain active (e.g. shared identities);
e) prevent re-use of previous passwords;
f) prevent the use of commonly-used passwords and compromised usernames, password combinations from hacked systems;
g) not display passwords on the screen when being entered;
h) store and transmit passwords in protected form.Password encryption and hashing should be performed according to approved cryptographic techniques for passwords

Other information

Passwords or passphrases are a commonly used type of authentication information and are a common means of verifying a user’s identity. Other types of authentication information are cryptographic keys,data stored on hardware tokens (e.g. smart cards) that produce authentication codes and bio metric data such as iris scans or fingerprints. Additional information can be found in the ISO series. Requiring frequent change of passwords can be problematic because users can get annoyed by the frequent changes, forget new passwords, note them down in unsafe places, or choose unsafe passwords. Provision of Single Sign On (SSO) or other authentication management tools (e.g. password vaults) reduces the amount of authentication information that users are required to protect and can thereby increase the effectiveness of this control. However, these tools can also increase the impact of disclosure of authentication information. Some applications require user passwords to be assigned by an independent authority. In such cases, a), c) and d) of “Password management system” do not apply.

Guidance on Allocation of Authentication Information

Secret authentication information is a gateway to access valuable assets. It typically includes passwords, encryption keys etc. so needs to be controlled through a formal management process and needs to be kept confidential to the user. This is usually tied into employment contracts , disciplinary processes and supplier obligations if sharing with external parties. Procedures should be established to verify the identity of a user prior to providing new, replacement or temporary secret authentication information. Any default secret authentication information provided as part of a new system use should be changed as soon as possible. Organisations should comply with the following six requirements for allocation and management of authentication information:

• When personal passwords or personal identification numbers are generated automatically for enrollment of new users, they should be non-guessable. Furthermore, passwords should be unique to each user and it must be mandatory to change passwords after the first use.
• Organisations should establish robust procedures to authenticate the identity of a user before he/she is granted a new or replacement authentication information or he/she is provided with temporary information.
• Organisations should ensure the secure transmission of authentication information to individuals via secure channels and they should not send this information over insecure electronic messages (e.g clear text).
• Users should confirm the receipt of the authentication information.
• After new IT systems and software programs are installed, organisations should change the default authentication information immediately.
• Organisations should establish and maintain records of all important events related to management and allocation of authentication information. Furthermore, these records should be kept confidential and record-keeping methods should be authorized such as through the use of an approved password tool.

Guidance on User Responsibilities

This is simply about making sure that users follow the policies and will therefore tie in with Human Resource Security for contracts, user education for awareness and compliance, as well as common sense practices.These include: Keep any secret authentication information confidential; Avoid keeping a record of it that can be accessed by unauthorized parties; Change it whenever there is any suggestion of possible compromise; select quality passwords with sufficient minimum length and strength to follow broader password policy controls.Users who can access to and use authentication information should be instructed to comply with the following:

1. Users must maintain the confidentiality of secret authentication information such as passwords and should not share such secret information with anyone else. When multiple users are involved in the use of authentication information or the information is linked to non-personal entities, the authentication information should not be disclosed to unauthorized persons.
2. Users must change their passwords immediately if the confidentiality of their passwords are compromised.
3. Users should select hard-to-guess strong passwords by following industry best practices. For instance:
4. Passwords should not be selected based on personal information that is easy to obtain, such as names or dates of birth.
5. Passwords should not be created based on anything that can be easily guessed.
6. Passwords should not include dictionary words or combinations of these words.
7. Alphanumeric and special characters should be used in the password.
8. There should be a minimum length for passwords.
9. Users should not use the same password for different services.
10. Organisations should include the requirements for creation and use of passwords in their employment contracts with their employees.

Users should be made aware of their responsibilities towards protecting their issued credentials, choosing strong passwords and keeping them confidential, and preventing the unauthorized disclosure of sensitive information under their care. The following can be included in the institution’s Acceptable Use of Information Security Policy. Systems should be locked when left unattended Users shall

• Access data in order to comply with the duties of their role or job duties on a need to know basis.
• Not attempt to access data or programs contained on systems for which they do not have authorization or consent.
• Not share their computer/network account, password, personal identification number (PIN), digital certificate, security token (i.e. Smartcard), or any other device used for identification and authorization purposes.
• Not share digital certificate passwords used for digital signatures.
• Not circumvent password entry through the use of auto logon, application “remember password” features, embedded scripts or hard-coded passwords in client software.
• Password-protect their desktops/laptops when left unattended

Guidance on Password Management Systems

The purpose of a password management system is to ensure quality passwords meet the required level and are consistently applied. Password generation and management systems provide a good way of centralizing the provisioning of access and they serve to reduce the risk of people using the same login for everything, as illustrated in this little story of what happens when a customer contacts our team about a forgotten password. As with any control mechanism, password generation and management systems need to be carefully implemented to ensure adequate and proportionate levels of protection. Wherever possible users should be able to choose their own passwords as this makes them easier to remember than machine-generated ones, however, it needs to be up to a certain level of strength. There are lots of conflicting views on password management systems and password policies so we encourage organisations to look at the frequently changing best practices and adopt approaches based on the risk appetite and culture of the organisation. Organisations should comply with the following when establishing a password management system:

• Users should be allowed to create and change their passwords and there should be a confirmation procedure in place to ensure that input errors are identified and resolved.
• Organisations should implement a strong password selection process, taking into account industry best practices for password selection.
• Users should be forced to change their default passwords after they first access a system.
• Password changes should be implemented when it is necessary. For example, password change will be necessary after a security incident or following the termination of an employment with a user if that user has access to passwords.
• Previous passwords should not be reused.
• Use of highly common passwords or compromised passwords or usernames used for access to hacked systems should be prohibited.
• When passwords are entered, they should be visible on the screen in plain text.
• Passwords should be stored and transferred via protected channels and in a secure format.

Furthermore, organisations should perform hashing and encryption techniques in accordance with the authorized cryptography methods for passwords.

It is important to realize that people will share their passwords unless you provide them with some other method of allowing specific individuals to access information in their accounts. For instance, individuals in upper management often ask an administrative assistant to check their e-mail. Also, when people go on vacation, they may need to give someone temporary access to data on their computers, in the e-mail, and on other systems. Password sharing policies should be put in place along with solutions that provide needed functionality with accountability for the shared resource.

Good Password Practices:

• Use strong passwords or long passphrases
• Do NOT write passwords down
• Do NOT share passwords
• Use different passwords for different applications (e.g., work vs personal; shopping, and banking vs casual email and Facebook; applications that contain confidential information vs those that do not, etc.)

What is a Strong Password?

The strength of a password is determined by some restrictions – like minimum length, password age, use of multiple types and special characters, and reuse restrictions – which determines the average number of guesses an attacker must try to guess the password and ease with which the attacker can test the validity of the guessed password. Password entropy is a mathematical way to measure the difficulty of guessing or determining a password. As applied to passwords, guessing entropy is the estimate of the average amount of work needed to guess a password. Min-entropy is the measure of the difficulty of guessing the easiest single password to guess in the population. Password entropy is expressed in bits. If a password of k bits is chosen at random there are 2 to the k exponential possible values and the password is said to have k bits of entropy. If a password of length l characters is chosen at random from an alphabet of b characters (e.g., the 94 printable characters on a typical keyboard) then the entropy of the password is b to the l exponential. See the following InCommon Assurance link for Password Entropy. An example of a reasonably strong password is:

• An attack targeted against the password should have a probability of success of less than 2 to the -14 exponential (i.e., 1 chance in 16,384) over the life of the password.
• Has at least 10 bits of min-entropy
• Has a minimum length of 10 characters
• Does not contain a username, personal name, or organizational name
• Avoids repetition or dictionary words
• Contains a mix of upper and lower case alpha characters
• Has at least 2 non-alpha characters (i.e., numerals and/or special characters)
• Has a password life of 90 days
• Has not been used before (i.e., no password reuse)

To Change or Not to Change Passport ? How Often?

Again, there are as many answers to these questions as there are information security professionals. The argument for changing passwords regularly is that the longer a password remains the same and the more often the same password is used, then it is more likely that the password will be discovered or compromised. Also, the benefit of an “expiration date” on a password is that it limits the amount of time a lost or compromised password can be used by an unauthorized party. The more secure or sensitive information resources, the more frequently passwords should be changed. Conversely, the argument against changing passwords regularly is that strong passwords are reasonably secure and they take longer time and more effort to guess thus making them less likely to be discovered or compromised. Also, it may not be as easy to come up with easy to remember a strong password every 30 or 60 days. Even though there is no “right” or “perfect” answer, the following points are worth considering:

• Password policy should be based on risk, vulnerabilities, and deployed safeguards
• The period of time between changes should be determined by the required strength of the passwords being used
• Password changes make it harder for users to use the same password for multiple services (i.e., forces password “diversity”)
• Periodic password changes, especially when done as a routine, could limit successful phishing attempts since users would know when it is time to change passwords and when it is not.

Password Management Problems: By no means a comprehensive list

• Need (and failure) to remember multiple passwords
• Need (and failure) to remember strong passwords
• The frequency of password change
• Coming up with easy to remember but difficult to hack passwords multiple times per year
• Need to replicate password change to multiple devices or applications
• The sophistication of social engineering and “phishing” attacks

Passphrases

A passphrase is just a different way of thinking about a “secret” or “something you know”. The main difference is that a passphrase is longer. While a usual password is 8 to 10 characters long, a passphrase can be twice as long. Compared to passwords, a passphrase is generally stronger because it is more memorable than passwords thus reducing the need to write them down, they make some types of brute force attacks impractical since they are much longer than passwords, and they make phrase or quote dictionary attacks almost impossible if the passphrase is well constructed.

Guidance on Control 5.17

In addition to passwords, there are other types of authentication information such as cryptographic keys, smart cards and bio metric data such as fingerprints. Organisations are advised to refer to ISO Series for more detailed guidance on authentication information. Considering that frequent change of passwords might be cumbersome and annoying for users, organisations may consider implementing alternative methods such as single sign-on or password vaults. However, it should be noted that these alternative methods may expose authentication information to higher risk of unauthorized disclosure.

Identity management is the organizational process for ensuring individuals have the appropriate access to technology resources. This includes the identification, authentication and authorization of a person, or persons, to have access to applications, systems or networks. This is done by associating user rights and restrictions with established identities. Identities are used by computer networks to identify an entity’s (a user, group of users, device or IT asset) underlying ability to access a predetermined set of hardware and software resources. IT deals with the approval, registration and administration – defined as the ‘full life cycle’ – of human and non-human identities on any given network. The purpose is to  to identify who (users, groups of users) or what (applications, systems and devices) is accessing data or IT assets at any given time, and how those identities are granted access rights across the network. It maintains risk by maintains risk by acting as the main perimeter for all associated information security and cyber security operations, as well as the primary mode governance that dictates an organization’s Identity and Access Management framework. Identity management includes authenticating users and determining whether they’re allowed access to particular systems. Identity management is focused on authentication, while access management is aimed at authorization.

Control

The full life cycle of identities should be managed.

Purpose

To allow for the unique identification of individuals and systems accessing the organization’s information and other associated assets and to enable appropriate assignment of access rights.

ISO 27001 Implementation Guidance

The processes used in the context of identity management should ensure that:

1. for identities assigned to persons, a specific identity is only linked to a single person to be able to hold the person accountable for actions performed with this specific identity;
2. identities assigned to multiple persons (e.g. shared identities) are only permitted where they are necessary for business or operational reasons and are subject to dedicated approval and documentation;
3. identities assigned to non-human entities are subject to appropriately segregated approval and independent ongoing oversight;
4. identities are disabled or removed in a timely fashion if they are no longer required (e.g. if their associated entities are deleted or no longer used, or if the person linked to an identity has left the organization or changed the role);
5. in a specific domain, a single identity is mapped to a single entity, [i.e. mapping of multiple identities to the same entity within the same context (duplicate identities) is avoided];
6. records of all significant events concerning the use and management of user identities and of authentication information are kept.

The organization should have a supporting process in place to handle changes to information related to user identities. These processes can include re-verification of trusted documents related to a person. When using identities provided or issued by third parties (e.g. social media credentials), the organization should ensure the third-party identities provide the required trust level and any associated risks are known and sufficiently treated. This can include controls related to the third parties as well as controls related to associated authentication information .

Other information

Providing or revoking access to information and other associated assets is usually a multi-step procedure:

1. confirming the business requirements for an identity to be established;
2. verifying the identity of an entity before allocating them a logical identity;
3. establishing an identity;
4. configuring and activating the identity. This also includes configuration and initial setup of related authentication services;
5. providing or revoking specific access rights to the identity, based on appropriate authorization or entitlement decisions

Identities are the things that identify users, systems, services and are their virtual representation allowing access to data and resources. They can be managed, allocated and used to control, monitor and report on what people and systems do and are doing.The control is achieved through a combination of ensuring that identity-based procedures are clearly articulated in policy documents, and monitoring day-to-day adherence among staff. The ownership should be directed towards IT staff who have been assigned Global Administrator rights (or equivalent for non-Windows based infrastructure). Whilst there are other built-in roles that allow users to administer identities (e.g. Domain Administrator), ownership should rest with the individual who has ultimate responsibility for an organisation’s entire network, including all subdomains and Active Directory tenants.

• Where identities are assigned to a person, only that specific person is allowed to authenticate with and/or use that identity, when accessing network resources. IT policies need to clearly stipulate that users are not to share login information, or allow other users to roam the network using any identity other than the one they’ve been assigned.
• Sometimes it may be necessary to assign an identity to multiple people – also known as a ‘shared identity’. This approach should be used sparingly, and only to satisfy an explicit set of operational requirements. Organisations should treat the registration of shared identities as a separate procedure to single user identities, with a dedicated approval workflow.
• So-called ‘non-human’ entities (as the name suggests, any identity that isn’t attached to an actual user) should be considered differently to user-based identities at the point of registration. As with shared identities, non-human identities should in turn have their own approval and registration process that acknowledges the underlying difference between assigning an identity to a person, and granting one to an asset, application or device.
• Identities that are no longer required (leavers, redundant assets etc.) should be disabled by a network administrator, or removed entirely, as is required. IT staff should carry out regular audits that list identities in order of use, and identify which entities (human or non-human) are able to be suspended or deleted. HR staff should include identity management in their off boarding procedures, and inform IT staff of leavers in a timely manner.
• Duplicate identities should be avoided at all costs. Firms should adhere to a ‘one entity, one identity’ rule across the board. IT staff should remain vigilant when assigning roles across a network, and ensure that entities aren’t granted access rights based on multiple identities.
• Adequate records should be kept of all ‘significant events’ regarding identity management and authentication information. The term ‘significant event’ can be interpreted in various ways, but on a basic level organisations need to ensure that their governance procedures include identity registration documentation, robust change request protocols with an appropriate approvals procedure, and the ability to produce a comprehensive list of assigned identities at any given time.

The main goal of identity management is to ensure only authenticated users are granted access to the specific applications, systems or IT environments for which they are authorized. This includes control over user provisioning and the process of on boarding new users such as employees, partners, clients and other stakeholders. Identity management also includes control over the process of authorizing system or network permissions for existing users and the off boarding of users who are no longer authorized to access organization systems. ID management determines whether a user has access to systems and sets the level of access and permissions a user has on a particular system. For instance, a user may be authorized to access a system but be restricted from some of its components. Identity governance, the policies and processes that guide how roles and user access should be administered across a business environment, is an important aspect of identity management. Identity governance is key to successfully managing role-based access management systems. Identity management is an important part of the Information security, as it is linked to both the security and productivity of the organization. In many organizations, users are granted more access privileges than they need to perform their functions. Attackers can take advantage of compromised user credentials to gain access to organizations’ network and data. Using identity management, organizations can safeguard their corporate assets against many threats including hacking, ransomware, phishing and other malware attacks. Identity management systems add an additional layer of protection by ensuring user access policies and rules are applied consistently across an organization.

The step involved in Identify Management is

• Implement an approval process for creating or revoking identities. You will want a process that covers the approval for the creating, revoking and deletion of identities. Think in terms of user accounts and system accounts. Your process can be simple but the driving principle is the person making the request cannot be the person that approves it. This is part of segregation of duty . What ever the process is in terms of the technology that implements it, you should maintain and audit trail of the approvals. An example would be keeping copies of the email exchange, or the tickets that were raised in a ticketing system.Consider perhaps that your processes may vary slightly or be tightened up a little in certain circumstances. Examples of this would be where third parties require accounts or identities to be created. Also an example would be super user and administrative identities.
• Confirm the business requirement for creating an identity. It is important to understand why you are creating an account or an identity. It will allow the person approving it to understand what and why they are approving as well as allow you to maintain some level of control . Particular attention should be given to admin accounts or accounts that have special powers.
• Verify the identity of an entity before creating the virtual representation. The standard doesn’t give much guidance on this and clearly it is going to be hard if not impossible to do for non human identities. It is a hang over from when they only worried about user accounts so they kept it. It does make sense for users and people so as part of the approval process, or for the human that requires the identity, verifying who they are and that they are who they say they are makes senses. There is a lot of phishing attempts made to get people to do things they would not normally do, including creating accounts, that bad guys then use to do you harm. I am not saying check passports and photo id but I am saying be sensible and do some level of check to satisfy yourself the person is who they say they are. Use common sense. If you get a request and it doesn’t feel right no one minds if you pick up the phone to check or ask their boss / others for extra verification.
• Create the identity. This really should be done by someone that knows what they are doing. The identity is going to be used to access ‘stuff’ so it is probably a good idea at this stage to create the record of the identity and who it was assigned to.
• Configure the identity and activate it. Again, this should be done by someone that knows what they are doing. It is easy to create accounts and identities but you really should have experience to understand what you have created and how to configure in a way that meets the approved request and the needs of the business rather than what ever the default system identity. Defaults are defaults and not designed to meet your specific needs.

Considerations when implementing identity management

1.One person one id. Where an identity is assigned to a human then it should be unique to that human so we know what that human did if things go wrong and we can control what the human has access to and can do.

2. Many persons one ID The standard and common sense wants one human to one ID but it does allow for many people using one ID where they are required for business, operational needs and have appropriate documentation. Which makes one person one ID redundant as a rule really, as if you need it this way then you can have it. I guess that is why we are calling it guidance. Have one human to one ID where you can. Thanks.

3. Non Human IDs As in the implementation guide above you will want an approval process for system and non human identities. You will also want some level of oversight of them. There is no guidance in the standard on what this means so I recommend having a periodic ( monthly perhaps ) review of all service accounts to make sure they are needed still and perhaps alternating with a check on the configuration of the ID and what it can do.

4. Remove old IDs You have a starter, leaver, mover process hopefully where HR will inform your process that someone has left so you can remove the ID. If you haven’t then you should. You will also have regular access reviews where you are checking who and what has access to what so you can mop up where the HR process has failed.

5. You can only call something one name. The standard doesn’t want you calling entities by different names with different names mapped. If your entity / server / laptop or what ever is called Brian then it is called Brian. It isn’t called Brian by IT but Anna by HR.

Log Stuff
The standard wants records of significant events on the use and management of identities and for that to be kept. This is actually a powerful statement and was a clause in its own right but logging and monitoring of identities and administrative actions is a must. It is just up to you to decide what ‘significant’ means. I would not get carried away logging everything as you will never look at it but consult the norm for the systems you are using and think about things like

• failed log on attempts
• account creating
• account deletion

Access control is the process of granting authorized users the right to use a service while preventing access to non-authorized users. Access control is a security technique that regulates who or what can view or use resources in a computing environment. It is a fundamental concept in security that minimizes risk to the business or organization.The Access Control addresses requirements to control access to information assets and information processing facilities. The controls are focused on the protection against accidental damage or loss, overheating, threats, etc. This requires a documented control policy and procedures, registration, removal, and review of user access rights, including here physical access, network access, and the control over privileged utilities and restriction of access to program source code. It provides the following value:

• Controlled access to services ensures that the organization is able to maintain more effectively the confidentiality of its information.
• Employees have the right level of access to execute their jobs effectively.
• There is less likelihood of errors being made in data entry or in the use of a critical service by an unskilled user.
• The ability to audit the use of services and to trace the abuse of services.
• The ability more easily revoke access rights when needed – an important security consideration.
• Maybe needed for regulatory compliance

There are two types of access control: physical and logical. Physical access control limits access to campuses, buildings, rooms and physical IT assets. Logical access control limits connections to computer networks, system files and data. To secure a facility, organizations use electronic access control systems that rely on user credentials, access card readers, auditing and reports to track employee access to restricted business locations and proprietary areas, such as data centers. Some of these systems incorporate access control panels to restrict entry to rooms and buildings, as well as alarms and lockdown capabilities, to prevent unauthorized access or operations. Logical access control systems perform identification authentication and authorization of users and entities by evaluating required login credentials that can include passwords, personal identification numbers, biometric scans, security tokens or other authentication factors. Multifactor authentication (MFA), which requires two or more authentication factors, is often an important part of a layered defense to protect access control systems.

Control

Rules to control physical and logical access to information and other associated assets should be established and implemented based on business and information security requirements.

Purpose

To ensure authorized access and to prevent unauthorized access to information and other associated assets.

ISO 27002 Implementation Guidance

Owners of information and other associated assets should determine information security and business requirements related to access control. A topic-specific policy on access control should be defined which takes account of these requirements and should be communicated to all relevant interested parties. These requirements and the topic-specific policy should consider the following:

1. determining which entities require which type of access to the information and other associated assets;
2. security of applications;
3. physical access, which needs to be supported by appropriate physical entry controls;
4. information dissemination and authorization (e.g. the need-to-know principle) and information security levels and classification of information;
5. restrictions to privileged access;
6. segregation of duties ;
7. relevant legislation, regulations and any contractual obligations regarding limitation of access to data or services
8. segregation of access control functions (e.g. access request, access authorization, access administration);
9. formal authorization of access requests;
10. the management of access rights ;
11. logging

Access control rules should be implemented by defining and mapping appropriate access rights and restrictions to the relevant entities. An entity can represent a human user as well as a technical or logical item (e.g. a machine, device or a service). To simplify the access control management, specific roles can be assigned to entity groups. The following should be taken into account when defining and implementing access control rules:

1. consistency between the access rights and information classification;
2. consistency between the access rights and the physical perimeter security needs and requirements;
3. considering all types of available connections in distributed environments so entities are only provided with access to information and other associated assets, including networks and network services, that they are authorized to use;
4. considering how elements or factors relevant to dynamic access control can be reflected.

Other information

There are often overarching principles used in the context of access control. Two of the most frequently used principles are:

1. need-to-know: an entity is only granted access to the information which that entity requires in order to perform its tasks (different tasks or roles mean different need-to-know information and hence different access profiles);
2. need-to-use: an entity is only assigned access to information technology infrastructure where a clear need is present.

Care should be taken when specifying access control rules to consider:

1. establishing rules based on the premise of least privilege, “Everything is generally forbidden unless expressly permitted”, rather than the weaker rule, “Everything is generally permitted unless expressly forbidden”;
2. changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user;
3. changes in user permissions that are initiated automatically by the information system and those initiated by an administrator;
4. when to define and regularly review the approval. Access control rules should be supported by documented procedures and defined responsibilities.

There are several ways to implement access control, such as MAC (mandatory access control), DAC (discretionary access control), RBAC (role-based access control) and ABAC (attribute-based access control). Access control rules can also contain dynamic elements (e.g. a function that evaluates past accesses or specific environment values). Access control rules can be implemented in different granularity, ranging from covering whole networks or systems to specific data fields and can also consider properties such as user location or the type of network connection that is used for access. These principles and how granular access control is defined can have a significant cost impact. Stronger rules and more granularity typically lead to higher cost. Business requirements and risk considerations should be used to define which access control rules are applied and which granularity is required.

Access Control governs the ways in which human and non-human entities on any given network are granted access to data, IT resources and applications. It relies upon managerial staff from various parts of an organisation maintaining a thorough understanding of who needs access to what resources (i.e. HR informing on an employees job role, which in turn dictates their RBAC parameters), access rights are ultimately a maintenance function that are controlled by staff with administrative rights over any given network. The ownership should rest with a member senior management with overarching technical authority across an organisation’s domains, subdomains, applications, resources and assets, such as a Head of IT. This control mentions (but does not limit itself to) four different types of access control, which can be broadly classified as follows:

• Mandatory Access Control (MAC) – Access is centrally managed by a sole security authority.This is a security model in which the system administrator defines the rules that govern access to resource objects. These rules are often based on conditions, such as time of day or location. It is not uncommon to use some form of both rule-based access control and RBAC to enforce access policies and procedures.
• Discretionary Access Control (DAC) – The opposite method to MAC, where object owners are able to pass on privileges to other users.This is an access control method in which owners or administrators of the protected system, data or resource set the policies defining who or what is authorized to access the resource. Many of these systems enable administrators to limit the propagation of access rights. A common criticism of DAC systems is a lack of centralized control.
• Role-based Access Control (RBAC) – The most common type of commercial access control, based around predefined job functions and privileges.This is a widely used access control mechanism that restricts access to computer resources based on individuals or groups with defined business functions — e.g., executive level, engineer level 1, etc. — rather than the identities of individual users. The role-based security model relies on a complex structure of role assignments, role authorizations and role permissions developed using role engineering to regulate employee access to systems. RBAC systems can be used to enforce MAC and DAC frameworks.
• Attribute-based Access Control (ABAC) – Access rights are granted to users through the use of policies which combine attributes together.This is a methodology that manages access rights by evaluating a set of rules, policies and relationships using the attributes of users, systems and environmental conditions.

Topic-specific approaches encourage organisations to create Access Control policies that are tailored towards individual business functions, rather than adhering to a blanket Access Control policy that applies to data and resource access across the board. This control requires Access Control policies across all topic-specific areas to take the following guidance points into consideration.

• Determine what entities require access to certain pieces of information and/or assets. This can achieved by keeping an accurate record of job roles and data access requirements, that is in line with your organisational structure.
• The integrity and security of all relevant applications . A formal risk assessment could be carried out to examine the security characteristics of individual applications.
• Physical (site) access controls. This can be demonstrated by a robust set of building and room access controls, including managed entry systems, security perimeters and visitor procedures, where appropriate.
• A company-wide “need to know” principle, when it comes to information distribution, security and categorization by adhering to strict best-practice policies that do not offer blanket access to data across an organisational chart.
• Ensure restrictions to privileged access rights. Data access privileges above and beyond that of a standard user need to be closely monitored and audited.
• Adherence to any prevailing pieces of legislation, sector-specific regulatory guidelines or contractual obligations related to data access by tailoring Access Control policies in accordance with any external obligations they have with regards to data, asset and resource access.
• Oversight of potential conflicts of duty. Policies should include controls that eliminate an individual’s ability to compromise a broader Access Control function, based on their own levels of access (i.e an employee who has the ability to request, authorize and implement changes to a network).
• The three main functions of an Access Control Policy – requests, authorizations and administration – should be addressed in isolation. Access Control policies need to acknowledge that whilst Access Control is a self-contained function, it’s made up of a number of individual steps that carry their own set of requirements on a topic-by-topic basis.
• Access requests should be conducted in a structured, formal manner.Organisations should implement an authorization process that requires formal, documented approval from an appropriate member of staff.
• Ongoing management of access rights. Data integrity and security perimeters need to be maintained through a continual cycle of periodic audits, HR oversight (leavers etc.) and job-specific changes (e.g. departmental moves and role amendments).
• Maintaining adequate logs, and controlling access to them. Organisation should collect and store data on access events (e.g. file activity) alongside safeguarding against unauthorized access to security event logs, and operate with a comprehensive set of incident management procedures.

Access Control Policy

Access Control policies should clearly communicate the organization’s business requirements regarding the identification of users, access to organizational information resources, user access rights, and special access privileges and restrictions.  The following could comprise the core of an organizational access control policy framework.

• Roles and responsibilities
  • Need-to-Know:  Access only to information needed to perform assigned tasks.
  • Need-to-Use:  Access only to information resources needed to perform assigned tasks
  • Access levels and privileges by role
  • Periodic review and removal of access levels and privileges
  • Segregation of duties for requesting, authorizing, and reviewing access levels and privileges
• What is required to identify users?
  • The requirement for vetting users in person
  • A requirement to archive records concerning user identification and credentialing
• What criteria are used to determine the types of credentials used?
• What criteria are used to determine the level of access to applications and services?
  • Identification of roles with privileged access
  • Contractual obligations for limiting access granted to vendors and partners
• What is required from identity providers and from service providers?
  • The requirement to identify the security requirements of applications – both, purchased and developed internally
  • The requirement to determine the Level of Authentication (LOA) required to access a service based on risk

Data owners shall determine, approve and assign the level of access to organizational systems and data based on the responsibilities, job functions, reporting or outreach requirements based on the confidentiality of the data and to the restrictions imposed by federal, state and organizational rules and regulations.

Access Control Program

As data, access, and networks continue to expand, organizations have an ever-increasing need to manage identities and access. The optimum solution for this function may be a well-planned and organization-wide Access Management program. In its simplest form, Access Management ensures that only the right people can access the right services at the right time. However, within a complex organization, establishing an Access Management program is not an easy task. Many stakeholders, technology areas, policies, and processes must work together for a scalable and robust  Program. In addition, governance plays a key role in the success of any Acess Management Program and implementation.

Activities of access control

Access control is integrated into an organization’s IT environment. It can involve identity management and access management systems. These systems provide access control software, a user database and management tools for access control policies, auditing and enforcement. When a user is added to an access management system, system administrators use an automated provisioning system to set up permissions based on access control frameworks, job responsibilities and workflows. The best practice of least privilege restricts access to only resources that employees require to perform their immediate job functions. The steps for access control can be

1. Requesting access – Access can be requested using one or any number of mechanisms, e.g.
   • A standard request
   • A request for change
   • A service request (submitted via the request fulfillment system)
   • Executing a pre-authorized script or option
   • Rules for requesting access are normally documented as part of the service catalogue
2. Verification – It needs to verify every request for access to a service from two perspectives:
   • That the user requesting access is who they say they are
   • That they have a legitimate requirement for that service
3. Providing rights – It does not decide who has access to which services. It only executes the policies and regulations defined. It enforces decisions to restrict to provide access, rather than making the decision. As soon as a user is verified, it will provide that user with the rights to use the requested service. In most cases, this will result in a request to every team or department involved in supporting that service to take the necessary action. Ideally, these tasks should be automated.
4. Monitoring identity status – As users work in the organization, their roles change as do their needs to access services, e.g. job changes, promotions/demotions, resignation or death, etc. It should understand and document the typical user lifecycle for each type of user and use it to automate the process. Access controls tools should provide features that enable a user to be moved from one state to another or from one group to another, easily and with an audit trail.
   • Job changes – In this case, the user will possibly need access to different or additional services.
   • Promotions or demotions – The user will probably use the same set of services, but will need access to different levels of functionality or data.
   • Transfers – In this situation, the user may need access to exactly the same set of services, but in a different region with different working practices and different sets of data.
   • Resignation – Access needs to be completely removed.
   • Death – Access needs to be completely removed.
   • Retirement – In many organizations, an employee who retires may still have access to a limited set of services, including benefits systems or systems that allow them to purchase company products at a reduced rate, alumni information, etc.
   • Disciplinary action – In some cases, the organization will require a temporary restriction to prevent the user from accessing some or all of the services that they would normally have access to. There should be a feature in the process and tools to do this, rather than having to delete and reinstate the user’s access rights.
   • Dismissals – Where an employee or contractor is dismissed, or where legal action is taken against a customer (for example, for defaulting on payment for products purchased on the internet), access should be revoked immediately. In addition, access management, working together with information security management, should take active measures to prevent and detect malicious action against the organization from that user.
5. Logging and tracking access – Access management should not only respond to requests. It is also responsible for ensuring that the rights that they have provided are being properly used. Information security management plays a vital role in detecting unauthorized access and comparing it with the rights that were provided by access management. Access management may also be required to provide a record of access for specific services during forensic investigations. If a user is suspected of breaches of policy, inappropriate use of resources, or fraudulent use of data, access management may be required to provide evidence of dates, times and even content of that user’s access to specific services.
6. Removing or restricting rights – Just as access management provides rights to use a service, it is also responsible for revoking those rights. Again, this is not a decision that it makes on its own. Access management will execute the decisions and policies made during service strategy and design and also decisions made by managers within the organization. Removing access is usually done in the following circumstances:
   • Death
   • Resignation
   • Dismissal
   • The user has changed roles etc.

Challenges of access control

Many of the challenges of access control stem from the highly distributed nature of modern IT. It is difficult to keep track of constantly evolving assets because they are spread out both physically and logically. Specific examples of challenges include the following:

• dynamically managing distributed IT environments;
• password fatigue;
• compliance visibility through consistent reporting;
• centralizing user directories and avoiding application-specific silos; and
• data governance and visibility through consistent reporting.

Many traditional access control strategies — which worked well in static environments where a company’s computing assets were help on premises — are ineffective in today’s dispersed IT environments. Modern IT environments consist of multiple cloud-based and hybrid implementations, which spreads assets out over physical locations and over a variety of unique devices, and require dynamic access control strategies. Organizations often struggle to understand the difference between authentication and authorization. Authentication is the process of verifying individuals are who they say they are using biometric identification and MFA. The distributed nature of assets gives organizations many avenues for authenticating an individual. Authorization is the act of giving individuals the correct data access based on their authenticated identity. One example of where authorization often falls short is if an individual leaves a job but still has access to that company’s assets. This creates security holes because the asset the individual used for work — a smartphone with company software on it, for example — is still connected to the company’s internal infrastructure but is no longer monitored because the individual is no longer with the company. Left unchecked, this can cause major security problems for an organization. If the ex-employee’s device were to be hacked, for example, the attacker could gain access to sensitive company data, change passwords or sell the employee’s credentials or the company’s data. One solution to this problem is strict monitoring and reporting on who has access to protected resources so, when a change occurs, it can be immediately identified and access control lists and permissions can be updated to reflect the change. Another often overlooked challenge of access control is user experience. If an access management technology is difficult to use, employees may use it incorrectly or circumvent it entirely, creating security holes and compliance gaps. If a reporting or monitoring application is difficult to use, the reporting may be compromised due to an employee mistake, which would result in a security gap because an important permissions change or security vulnerability went unreported.

This control requires organizations to put in place appropriate rules, procedures, and/or agreements to maintain the security of data when it is shared within an organization or when transmitted to third parties. When information is transferred to internal or external parties, it creates a heightened risk to the confidentiality, integrity, availability, and security of information transmitted. This control gives requirements that organizations must satisfy to maintain the security of data when it is shared internally or when it flows out of the organization to third parties. Information Transfer control suggests that the organization should have controls in place to ensure that incidents such as interception, unauthorized access, misrouting, modification, and destruction are avoided. It further includes the concept of non-repudiation, which simply means that a person(s) doing something wrong should not be able to walk away by neglecting their actions; therefore, it is recommended that organizations should have proper rules, procedures and agreements in place while transferring any type of information both in physical and digital form. This control considers three types of information transfer, namely, Physical, Electronic and Verbal. It further provides details regarding how each of these methods should be handled, and the required steps to take.

Control

Information transfer rules, procedures, or agreements should be in place for all types of transfer facilities within the organization and between the organization and other parties.

Purpose

To maintain the security of information transferred within an organization and with any external interested party.

ISO 27002 Implementation Guidance

General

The organization should establish and communicate a topic-specific policy on information transfer to all relevant interested parties. Rules, procedures and agreements to protect information in transit should reflect the classification of the information involved. Where information is transferred between the organization and third parties, transfer agreements (including recipient authentication) should be established and maintained to protect information in all forms in transit. Information transfer can happen through electronic transfer, physical storage media transfer and verbal transfer. For all types of information transfer, rules, procedures and agreements should include:

1. controls designed to protect transferred information from interception, unauthorized access, copying, modification, misrouting, destruction and denial of service, including levels of access control commensurate with the classification of the information involved and any special controls that are required to protect sensitive information, such as use of cryptographic techniques
2. controls to ensure traceability and non-repudiation, including maintaining a chain of custody for information while in transit;
3. identification of appropriate contacts related to the transfer including information owners, risk owners, security officers and information custodians, as applicable;
4. responsibilities and liabilities in the event of information security incidents, such as loss of physical storage media or data;
5. use of an agreed labeling system for sensitive or critical information, ensuring that the meaning of the labels is immediately understood and that the information is appropriately protected
6. reliability and availability of the transfer service;
7. the topic-specific policy or guidelines on acceptable use of information transfer facilities
8. retention and disposal guidelines for all business records, including messages; NOTE Local legislation and regulations can exist regarding retention and disposal of business records.
9. the consideration of any other relevant legal, statutory, regulatory and contractual requirements related to transfer of information (e.g. requirements for electronic signatures).

Electronic transfer

Rules, procedures and agreements should also consider the following items when using electronic communication facilities for information transfer:

1. detection of and protection against malware that can be transmitted through the use of electronic communications
2. protection of communicated sensitive electronic information that is in the form of an attachment;
3. prevention against sending documents and messages in communications to the wrong address or number;
4. obtaining approval prior to using external public services such as instant messaging, social networking, file sharing or cloud storage;
5. stronger levels of authentication when transferring information via publicly accessible networks;
6. restrictions associated with electronic communication facilities (e.g. preventing automatic forwarding of electronic mail to external mail addresses);
7. advising personnel and other interested parties not to send short message service (SMS) or instant messages with critical information since these can be read in public places (and therefore by unauthorized persons) or stored in devices not adequately protected;
8. advising personnel and other interested parties about the problems of using fax machines or services, namely:

1) unauthorized access to built-in message stores to retrieve messages;

2) deliberate or accidental programming of machines to send messages to specific numbers.

Physical storage media transfer

When transferring physical storage media (including paper), rules, procedures and agreements should also include:

1. responsibilities for controlling and notifying transmission, dispatch and receipt;
2. ensuring correct addressing and transportation of the message;
3. packaging that protects the contents from any physical damage likely to arise during transit and in accordance with any manufacturers’ specifications, for example protecting against any environmental factors that can reduce the effectiveness of restoring storage media such as exposure to heat, moisture or electromagnetic fields; using minimum technical standards for packaging and transmission (e.g. the use of opaque envelopes);
4. a list of authorized reliable couriers agreed by management;
5. courier identification standards;
6. depending on the classification level of the information in the storage media to be transported, use tamper evident or tamper-resistant controls (e.g. bags, containers);
7. procedures to verify the identification of couriers;
8. approved list of third parties providing transportation or courier services depending on the classification of the information;
9. keeping logs for identifying the content of the storage media, the protection applied as well as recording the list of authorised recipients, the times of transfer to the transit custodians and receipt at the destination.

Verbal transfer

To protect verbal transfer of information, personnel and other interested parties should be reminded that they should:

1. not have confidential verbal conversations in public places or over insecure communication channels since these can be overheard by unauthorized persons;
2. not leave messages containing confidential information on answering machines or voice messages since these can be replayed by unauthorized persons, stored on communal systems or stored incorrectly as a result of misdialling;
3. be screened to the appropriate level to listen to the conversation;
4. ensure that appropriate room controls are implemented (e.g. sound-proofing, closed door);
5. begin any sensitive conversations with a disclaimer so those present know the classification level and any handling requirements of what they are about to hear.

The control’s main objective to maintain the security of any information received or sent on the networks. In order to protect the transferees by using all types of communication facilities, official transfer policies, procedures and controls should be developed. So, any entity could not alter,detect or manipulate the originality of the information. The information transfer aspect includes the following controls:

• Information transfer can happen using different communication channels (for example, e-mail, instant messaging tools, telephones, faxes, etc). For that purpose, companies should define the acceptable use of all these communication tools, what kind of information should be transferred, and how these communication channels will be protected. These policies and procedures should be communicated to the relevant personnel.
• Agreements on information transfer – in some cases, when your company transfers sensitive information to third parties, formal agreements should be signed. These agreements can include elements such as rules for labelling the information, usage of cryptography, defining access controls, defining responsibilities for managing security incidents, etc.
• Electronic messaging – meaning protection of the information involved in electronic messaging, by defining which public services are allowed to be used (for example, social networks, file sharing, etc.), using electronic signatures, etc.
• Confidentiality and non-disclosure agreements – one way of protecting sensitive company data is by using legal means through confidentiality statements and non- disclosure agreements. These should be signed by both employees and external parties.
• This section is significant because it covers the controls for communicating information inside and outside the organization, which is an essential activity of all organizations operating in today’s information age. Communications security is also critical because the confidentiality, availability, and integrity of the information might be endangered during transit.

Clear policies and procedures that govern the transfer of information between individuals both within and outside your organization should be established. Be sure to consider all possible methods of communication, including face-to-face, e-mail, voice, fax, and video, when drafting your policies. General policies about information transfer should include guidelines for acceptable use, and more specific procedures can be established to ensure secure transfer using approved methods. Make sure your users are aware of the limitations of each system (e.g., transferring information via fax machine is only a secure option if physical access to the machine on the other end is restricted). In addition to establishing policies, technical controls should be implemented, when feasible, to protect the confidentiality, integrity, and availability of the information being transferred. Most anti-virus and anti-malware solutions have tools that can scan e-mails in real-time, and encrypting important e-mails can be done for free (using PGP, for instance) or implemented enterprise-wide. These controls can provide the first line of defense against infection and/or compromise. It is still important, however, to discuss information transfer as a part of your organization’s information security awareness program. Educating your users about not communicating confidential information over insecure channels, state and organizational retention guidelines, and the dangers of e-mail auto-forwarding, among other topics, can go a long way toward ensuring that your systems and data remain secure. Formal transfer policies, procedures, and controls must be in place to protect the transfer of information through the use of all types of communication facilities. Whatever type of communication facility is in use, it is important to understand the security risks involved in relation to the confidentiality, integrity, and availability of the information and this will need to take into account the type, nature, amount, and sensitivity or classification of the information being transferred. It is especially important to implement such policies and procedures when information is being transferred out of or into the organization from third parties. Different but complementary controls may be required to protect information being transferred from interception, copying, modification, misrouting, and destruction and should be considered holistically when identifying which controls are to be selected.

Information may be transferred digitally or physically and agreements must address the secure transfer of business information between the organization and any external parties. Formal transfer policies procedures and technical controls should be selected, implemented, operated, monitored, audited, and reviewed to ensure ongoing effective security protection. Often, communications and transfer systems and procedures are put in place, without a real understanding of the risks involved which therefore creates vulnerabilities and possible compromise. ISO 27002 touches on implementation considerations including consideration of notifications, traceability, escrow, identification standards, the chain of custody, cryptography, access control, and others. If your organization has a business that needs to transfer information to a third party, then you should (and, in some cases, are legally required) enter into an official agreement with them in order to preserve the security of that information. These agreements generally set minimum standards for protecting your data, and may also establish the limits of liability for both parties in the event of a breach or other unauthorized disclosure of data. If the data being transferred is considered HIPAA-protected then the two parties must enter into a Business Associate Agreement (BAA). BAA’s are required to include clauses covering data security data disclosure, and data destruction, among others. Similarly, if the data is considered highly sensitive (e.g., social security numbers, bank account numbers), then your organization may require additional data security provisions, similar to those found in a BAA, for such a contract. Information transfer agreements may also include the following: agreed-upon cryptographic standards for encrypting data in transit and at rest, and chain of custody for physical transfer. For example, any agreement between your organization and a company that provides off-site backup storage for your critical systems and data should include clauses that cover minimum standards for the protection of your data in transit from one location to the other (e.g., are the tapes secured in a locked box? Who has the key?), and procedures for identifying and authorizing individuals from one organization or the other (since neither company can reasonably be expected to know all the other’s employees).

The organization must develop rules, procedures, and agreements, including a topic-specific information transfer policy, that provides data in transit with a level of protection appropriate to the classification assigned to that information.The level of protection should match the level of criticality and sensitivity of information transmitted.The organisations must sign transfer agreements with recipient third parties to guarantee secure transmission of data. It lists the elements that must be included in all rules, procedures, and agreements for all three types of transfers in general:

• Organisations must define controls appropriate to the level of classification of the information to protect the information in transit from unauthorised access, modification, interception, copying, destruction, and denial-of-service attacks.
• An organisation must keep control over the chain of custody while it is in transit and must define and implement controls to ensure traceability of information.
• Relevant parties involved in the transfer of information should be defined and their contact details should be provided. This may include information owners and security officers.
• Allocation of liabilities in case a data breach occurs.
• Using a labeling system.
• Ensuring the availability of the transfer service.
• Creating topic-specific guidelines on the information transfer methods.
• Guidelines for storage and deletion of all business records, including messages.
• Analysis of the impact any applicable laws, regulations, or other obligations may have over the transfer.

Electronic messaging includes e-mail, peer-to-peer file transfer, social network-based communications (e.g., Twitter, Facebook chats, LinkedIn, Skype, etc.) and more. Your organization should consider introducing a policy that governs the authorized use of these mediums; at a minimum, such a policy should establish the authority to represent your organization in an official capacity on the Internet. Also, because your organization is unable to apply technical controls to third-party electronic messaging mediums – Twitter, Facebook, et. al. – there is no way for you to quantify or improve their level of security in order to effectively secure a confidential message travelling across one of these mediums. The solution to this problem is to clearly state in your policy that organization-related business is only to be communicated and/or conducted using approved, secured methods (e.g., e-mail). Any information that is involved in any form of electronic messaging needs to be appropriately protected. Put in simple terms, when using electronic messaging, it should be protected to ensure no unauthorized access can be gained The organization should create a policy which sets out which forms of electronic messaging should be used for the different types of information being transferred, e.g. depending on how secure they are. Considerations will also need to be made for voice & fax communications transfer, and physical transfer (e.g. via postal systems). This should align with access controls and other secure authentication policies and log-on procedures.Rules, agreements, and procedures should address the following issues when information is transferred electronically:

• Detection and prevention of malware attacks.
• Protecting sensitive information contained in the attachments transferred.
• Ensuring that all communications are sent to the correct recipients and the risk of sending communications to wrong email addresses, addresses, or phone numbers is eliminated.
• Obtaining prior authorization before starting to use any public communication services.
• Implementing stricter authentication methods when data is transmitted via public networks.
• Imposing restrictions on the use of e-communication services such as banning automatic forwarding.
• Advise personnel on not using short message or instant message services to share sensitive data because this content may be seen by unauthorized individuals in public spaces.
• Advising staff and other relevant parties on the security risks presented by fax machines such as the risk of unauthorized access or re-routing of messages to specific numbers.

When information is shared via physical means such as papers, the rules, procedures, and agreements should cover the following:

• Assignment of responsibilities for notification of transmission, dispatch, and receipt.
• Ensuring correct addressing and transportation of the message.
• Packaging eliminates the risk of damage to the contents that may arise when the content is in transit. For instance, packaging should be good enough to not be affected by heat or moisture.
• A list of reliable couriers agreed and authorised by the management.
• Description of courier identification standards.
• Use of tamper-resistant controls such as bags if the level of sensitivity and criticality of information demands it.
• Procedures to verify IDs of couriers.
• Approved list of third parties providing transportation or courier services depending on the level of classification.
• Keeping log records of the time of delivery, list of authorised recipients, protections applied, and receipt at the destination.

When personnel exchange information within the organisation or when they transmit data to external parties, they should be informed of the following risks:

• They should avoid having confidential conversations over insecure public channels or in public spaces.
• They should not leave voice messages that contain confidential information considering the risk of replay by unauthorised persons and the risk of re-routing of the message to third parties.
• Each individual, whether employees or other relevant third parties, should be screened before being allowed in to listen to conversations.
• Rooms, where confidential conversations take place, should be equipped with appropriate controls such as sound-proofing.
• They should give a disclaimer before having any sensitive conversation

Information classification is a process in which organisations assess the data that they hold and the level of protection it should be given. Organisations usually classify information in terms of confidentiality – i.e. who is granted access to view it.Data Classification or Information Classification is the process of classifying corporate information into significant categories to ensure critical data is protected. For example, financial files within an organization should not be kept together with files from the public relations department. Instead, they should be maintained in separate folders, which are accessible only by individuals who are entitled to working with each kind of data. Thus, the stored information stays safe and can be easily accessed when needed. A typical system contains four levels of confidentiality:

• Confidential (only senior management have access)
• Restricted (most employees have access)
• Internal (all employees have access)
• Public information (everyone has access)

The levels shouldn’t be based on employees’ seniority but on the information that’s necessary to perform certain job functions. For example. Doctors and nurses need access to patients’ personal data, including their medical histories, which is highly sensitive. However, they shouldn’t have access to other types of sensitive information, such as financial records. You just need to follow simple steps.

1. Enter your assets into an inventory
   The first step is to collate all your information into an inventory (or asset register). You should also note who is responsible for it (who owns it) and what format it’s in (electronic documents, databases, paper documents, storage media, etc.).
2. Classification
   Next, you need to classify the information. Asset owners are responsible for this, but it’s a good idea for senior management to provide guidelines based on the results of the organisation’s ISMS risk assessment. Information that would be affected by more significant risks should usually be given a higher level of confidentiality. But be careful, because this isn’t always the case. There will be instances where sensitive information must be made available to a broader set of employees for them to do their job. The information may well pose a threat if it’s confidentiality is compromised, but the organisation must make it widely available in order to function.
3. Labeling
   Once you’ve classified your information, the asset owner must create a system for labeling it. You’ll need different processes for information that’s stored digitally and physically, but it should be consistent and clear. For example, you might decide that paper documents will be labelled on the cover page, the top-right corner of each subsequent page and the folder containing the document. For digital files, you might list the classification in a column on your databases, on the front page of the document and the header of each subsequent page.

A 5.12 Classification of information

Control

Information should be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements.

Purpose

To ensure identification and understanding of protection needs of information in accordance with its importance to the organization.

ISO 27002 Implementation Guidance

The organization should establish a topic-specific policy on information classification and communicate it to all relevant interested parties. The organization should take into account requirements for confidentiality, integrity and availability in the classification scheme. Classifications and associated protective controls for information should take account of business needs for sharing or restricting information, for protecting integrity of information and for assuring
availability, as well as legal requirements concerning the confidentiality, integrity or availability of the information. Assets other than information can also be classified in compliance with classification of information, which is stored in, processed by or otherwise handled or protected by the asset. Owners of information should be accountable for their classification. The classification scheme should include conventions for classification and criteria for review of the classification over time. Results of classification should be updated in accordance with changes of the value, sensitivity and criticality of information through their life cycle. The scheme should be aligned to the topic-specific policy on access control and should be able to address specific business needs of the organization. The classification can be determined by the level of impact that the information’s compromise would have for the organization. Each level defined in the scheme should be given a name that makes sense in the context of the classification scheme’s application.
The scheme should be consistent across the whole organization and included in its procedures so that everyone classifies information and applicable other associated assets in the same way. In this manner, everyone has a common understanding of protection requirements and applies appropriate protection. The classification scheme used within the organization can be different from the schemes used by other organizations, even if the names for levels are similar. In addition, information moving between organizations can vary in classification depending on its context in each organization, even if their classification schemes are identical. Therefore, agreements with other organizations that include information sharing should include procedures to identify the classification of that information and to interpret the classification levels from other organizations. Correspondence between different schemes can be determined by looking for equivalence in the associated handling and protection methods.

Other information

Classification provides people who deal with information with a concise indication of how to handle and protect it. Creating groups of information with similar protection needs and specifying information security procedures that apply to all the information in each group facilitates this. This approach reduces the need for case-by-case risk assessment and custom design of controls. Information can cease to be sensitive or critical after a certain period of time. For example, when the information has been made public, it no longer has confidentiality requirements but can still require protection for its integrity and availability properties. These aspects should be taken into account, as over-classification can lead to the implementation of unnecessary controls resulting in additional expense or, on the contrary, under-classification can lead to insufficient controls to protect the information from compromise. As an example, an information confidentiality classification scheme can be based on four levels as follows:

a) disclosure causes no harm;
b) disclosure causes minor reputation damage or minor operational impact;
c) disclosure has a significant short-term impact on operations or business objectives;
d) disclosure has a serious impact on long term business objectives or puts the survival of the organization at risk.

A 5.13 Labeling of information

Control

An appropriate set of procedures for information labeling should be developed and implemented in accordance with the information classification scheme adopted by the organization.

Purpose

To facilitate the communication of classification of information and support automation of information processing and management.

ISO 27002 Implementation Guidance

Procedures for information labeling should cover information and other associated assets in all formats. The labeling should reflect the classification scheme established in 5.12. The labels should be easily recognizable. The procedures should give guidance on where and how labels are attached in consideration of how the information is accessed or the assets are handled depending on the types of storage media. The procedures can define:

1. cases where labeling is omitted (e.g. labeling of non-confidential information to reduce workloads);
2. how to label information sent by or stored on electronic or physical means, or any other format;
3. how to handle cases where labeling is not possible (e.g. due to technical restrictions).

Examples of labeling techniques include:

1. physical labels;
2. headers and footers;
3. metadata;
4. watermarking;
5. rubber-stamps.

Digital information should utilize metadata in order to identify, manage and control information, especially with regard to confidentiality. Metadata should also enable efficient and correct searching for information. Metadata should facilitate systems to interact and make decisions based on the associated classification labels. The procedures should describe how to attach metadata to information, what labels to use and how data should be handled, in line with the organization’s information model and ICT architecture. Relevant additional metadata should be added by systems when they process information depending on its information security properties. Personnel and other interested parties should be made aware of labeling procedures. All personnel should be provided with the necessary training to ensure that information is correctly labelled and handled accordingly. Output from systems containing information that is classified as being sensitive or critical should carry an appropriate classification label.

Other information

Labeling of classified information is a key requirement for information sharing. Other useful metadata that can be attached to the information is which organizational process created the information and at what time. Labeling of information and other associated assets can sometimes have negative effects. Classified assets can be easier to identify by malicious actors for potential misuse. Some systems do not label individual files or database records with their classification but protect all information at the highest level of classification of any of the information that it contains or is permitted to contain. It is usual in such systems to determine and then label information when it is exported.

Businesses handle vast amounts of data every day – customer information, invoice records, order history, email lists, user data in software — the list goes on. However, not all data is equally important, and some pieces will require more protection than others. Such sensitive and important information needs to be protected from vulnerabilities to security threats. That is why information classification is so important. It helps to determine which information needs special protection and how to label and classify your data.A well-planned data classification system makes important information easy to manipulate and track, besides making data easier to locate and retrieve. The most common reasons why information classification is of particular importance are:

1. Efficiency – on a basic level, businesses that have their information classified are able to manage and deliver day-to-day operations more efficiently. Data can be easily located and retrieved; changes easily traced.
2. Security – protecting sensitive information is the main idea behind information classification. It is a useful tactic to classify information in order to facilitate appropriate security responses according to the type of information being retrieved, transmitted, or copied. Data encryption, data storage in safe servers with strong firewalls, and compliance with data protection standards can help immensely to protect against outside threats. Besides, there can be inside threats that are equally dangerous – like intentional data theft, accidental data breaches. Hence it is very important to restrict information and prevent threats.
3. Safety – information classification helps create security awareness throughout the organization. The responsibility of protection of information lies with everyone handling the information. The system ensures that employees understand the value of the information they work with and safeguard that information.
4. Compliance – information classification in information security helps organizations label information as sensitive, protect it against threats, and help comply with regulations . Organizations can easily implement standards to classify information.

To implement a robust classification of information scheme, organisations should adopt a topic-specific approach, understand each business unit’s needs for information, and determine the level of sensitivity and criticality of information. The organisations must take into account the the following seven criteria when implementing a classification scheme:

• Establish a topic-specific policy and address the specific business needs. The classification scheme and levels should take specific business needs into account.
• Take into account business needs for sharing and use of information and the need for availability. If you assign an information asset to a classification category that is unnecessarily higher, this may bring the risk of disruption to your critical business functions by restricting access to and use of information. Therefore, you should strive to find a balance between your specific business needs for availability and use of information and the requirements for confidentiality and integrity of that information.
• Consider legal obligations. Some laws may impose stricter obligations on you to ensure confidentiality, integrity and availability of information. When assigning information assets to categories, legal obligations should take priority over your own classification.
• Take a risk-based approach and consider the potential impact of a compromise. Each type of information has a different level of criticality to each business’s operations and has a different level of sensitivity depending on the context. In implementing classification of information scheme, organisations should ask what impact would the compromise of integrity, availability and confidentiality of this information have on the organisation? For instance, databases of professional email addresses of qualified leads and health records of employees widely differ in terms of the level of sensitivity and the potential impact.
• Regularly review and update the classification. The value, criticality and sensitivity of information is not static and can change throughout the life cycle of the information. Therefore, you need to regularly review each classification and make necessary updates. As an example of such change, the disclosure of information to the public, which greatly reduces the value and sensitivity of information.
• Consult with other organisations you share information with and address any differences.There is no one way to classify information and each organisation can have different names, levels and criteria when it comes to classification of information schemes. These differences may lead to risks when the two organisations exchange information assets with each other. Therefore, you need to put in place an agreement with your counterpart to ensure that there is consistency in classification of information and interpretation of classification levels.
• Organisational-level consistency. Each department within the organisation should have a common understanding of classification levels and procedures so that classifications are consistent across the entire organisation.

The valuable data every organization needs to be protected commensurate with how it is classified. Customers, employees, and vendors entrust the organization with a given data set and there is an implied bargain that the data so entrusted will be protected from any use or disclosure other than as agreed to when the data was given. To do this, each organization has to govern the data it uses so that it will be received, made, used, stored, shared, or destroyed in a purposeful manner that recognizes the pact to protect data in its’s daily mission. Areas to consider in a data governance program include:

• Sensitivity Level. An Organization should be classifying data as to sensitivity to assure that proper security protection is in place appropriate with the given data set.
• Retention Period. Consistent with records management practices, an organization needs to be aware of the period in which data is to be retained, to assure that data’s availability and integrity for that retention period.
• Data Utilization. In every part of an organization that controls a given data set, appropriate procedures for how that data is utilized must be established. This includes access restrictions, proper handling, logging, and auditing.
• Data Back-up. How an Organization creates back-up copies of data and software is a critical element. Procedures need to be in the place that memorializes and verify the implementation and inventory of back-up copies.
• Management of Storage Media. Processes to ensure proper management of storage media, including restrictions of types of media, audit trails for movement of media, secure disposal of media no longer in use, and redundant storage.
• Electronic Data Transfers.
• Disposal of Media.

Information assets may not be equally important, nor equally sensitive or confidential in nature, nor require the same care in handling. One common method of ascertaining the importance of assets is data classification. Information assets should be classified according to their need for security protection and labeled accordingly. To begin to start with federal or state laws, regulations, rules, or institutional policies that require certain information assets to be protected. Pick a classification metric. Keep it simple. You may want to use something like (lowest to highest)

Public,Internal, Restricted, Confidential

Different assets have different impacts on the continuity and reputation of the organization. Once you have determined the importance of your various organizational assets, you can begin the process of determining how best to protect them. Many methods are employed to protect assets, ranging from policies to technical security controls. Additionally, assets must be protected throughout their life cycle, from creation or purchase through final disposal or long-term storage. Protection measures range from addressing purchasing controls to managing access by appropriate personnel to ensuring adequate physical security for assets throughout their lifetime.Some organization has established Data Stewardship policies to help ensure responsibilities for protecting data are effectively accomplished. Other organizations conduct regular security assessments of assets considered to be critical for the functioning of an organization. They may also address asset protection through physical security measures, or through background checks for newly hired and continuing personnel.

Labeling of information

Labeling of Information is a procedure that enables organisations to put their information classification scheme into practice by attaching classification labels to relevant information assets. Once you have your classification scheme in place you are going to then label information and assets accordingly. You are going to have to

• Implement procedures for information labelling
• Cover information and other associated assets in all formats

It is good practice to consider where labeling is omitted such as the case of non confidential information so that we can reduce the workload on people. The procedures that you write should give guidance on where and how labels are attached and the different types of storage media. You will look at how to label information sent by or stored on physical, electronic and because the standard likes to catch everything, on what it helpfully calls ‘any other format’. Nothing like future proofing for the unknowns. Of course there may be situations where labeling is not possible, and this is fine, as long as you have covered how to handle those cases. How you handle it may be to tag it with meta data or put in place some other compensating controls such as having an exception list and managing it via risk management. When you have your labeling processes and procedures you are going to train staff on how to use and follow them and be able to evidence that you did so.

Control 5.13 addresses how organisations should develop, implement and manage a robust information labeling procedure based on the classification scheme adopted through Control 5.12. It identifies four specific steps that organisations should implement to carry out labeling of information..

1) Develop and implement an Information Labeling Procedure
Organisations should develop an organisation-wide Information Labeling Procedure that adheres to the information classification scheme created in accordance with Control 5.12. Furthermore, 5.13 requires that this Procedure be extended to all information assets, regardless of whether it is in digital or paper format and that the labels must be easy to recognize. While there is no limit to what this Procedure document can contain, the Control 5.13 states that the Procedures should at least include the following:

• Description of the methods to attach labels to information assets depending on the storage medium and how the data is accessed.
• Where the labels are to be attached for each type of information asset.
• Which information assets will not be labelled, if any. For instance, an organisation may omit labelling public data to streamline the information labeling process.
• Description of measures for cases where it is not possible to label certain types of information due to technical, legal or contractual limitations.
• The rules on how the labeling of information transmitted to internal or external parties should be handled.
• For digital assets, the Procedure must explain how the metadata should be inserted.
• Names of labels to be used for all assets.

2) Provide Adequate Training to Staff on How to Adhere to the Labeling Procedure
The Procedure for labeling of Information can be effective only to the extent that Personnel and other relevant stakeholders are well-informed about how to correctly label information and how to deal with labelled information assets.Therefore, organisations should provide staff and other relevant parties with training on the Procedure.

3)Use Metadata for Labeling of Digital Information Assets
Control 5.13 requires the use of metadata for labeling of digital information assets.Furthermore, it notes that the metadata should be deployed in a way that makes it easy and efficient to identify and search for information and also in a way that streamlines the decision-making process between systems related to labelled information.

4) Take Extra Measures to Label Sensitive Data That May Outflow of the System
Considering the risks involved in outward transfer of sensitive data from systems, 5.13 recommends organisations to label these information assets with those most appropriate to the level of criticality and sensitivity of the information concerned.

Examples of labelling techniques can include:

• Headers and footers
• Physical Labels
• Watermarks
• Rubber Stamps
• Metadata

Now the standard starts to stray into implementation territory with its guidance on metadata. Metadata has its place but we have to look at the appropriateness of the control to our risk and our organisation. Remember that the annex controls are guidance for consideration and you do not HAVE to implement them, only consider them, so if metadata is not appropriate for you that is fine, just note it down and manage it via your risk management process, accepting the risk. Where it does apply and makes sense then you are looking at metadata to identify, manage and control information, especially in relation to confidentiality. It can help if it also makes it more efficient for searching for information but you can see here how the standard starts to tell you what to do not what is expected of you. Metadata searching for example is going to be reliant on specific technologies and implementations. If you are using metadata then your procedures are going to describe how to attach metadata to information, what labels to use and how data should be handled.

Your Organization may already have property control of assets where items over a certain dollar amount are automatically tagged with a unique, usually numeric, identifier by Property Control. If not, create one yourself. Use your newly created inventory of assets to assign a unique identifier to each one. Prepare labels that are easy to recognize and sturdy, and attach them to a visible place on the equipment. Make sure you clarify when labels should not be used on equipment. This could be based on the dollar amount or the level of risk you’ve assigned to the asset. Information needs labeling as well. Develop your information labeling procedures based on the data classification schema you developed previously. Metadata is a common type of information label. Do be careful how you manage the information you may have labeled as restricted or confidential. Because of the labeling, be careful how you manage restricted/sensitive or confidential information. It is much easier to steal or misuse when the assets are easy to identify.

Information classifications and labeling help prioritize data protection efforts to increase data security and regulatory compliance. Among its benefits are improved user productivity and decision making and reduced costs by eliminating data that’s not needed.

• Rediscovery of business – Identification of information is the beginning step in Information classification. Organizations, therefore, need to actively discover information that is generated, stored, and accessed by departments within the organization. This information discovery basically leads to rediscovering the business. This allows decision-makers to review how information is empowering the business or possibly functioning ineffectively.
• Raises awareness of cyber risk – Information security teams connect face to face with business owners to discuss information security and how it could impact their business. Thus, owners have a direct contact point where to reach if they have questions or need help regarding managing cyber risks or incidents. Awareness of cyber threats and information security management rises to realistic levels, prompting the issue to be discussed and accepted at all levels throughout the organization.
• Optimize risk and resources – defining information classification improves risk and information classification resources, leading to efficient and effective protection of information. By classifying data based on sensitivity and level of business impact, businesses are informing which information must be protected with high priority, thereby deciding where to spend the information security budgets.
• Limit dissemination – well-defined information classification is controlled by laws and regulations, thereby allowing businesses to restrict their dissemination on a need-to-know basis. This reduces the chances of data theft or loss, which helps to minimize penalties charged due to non-compliance.

Both workers and external stakeholders must return all of the organizational assets in their possession upon termination of their job, contract or agreement. This control states that personnel and other interested parties as appropriate should return all the organisation’s assets in their possession upon change or termination of their employment, contract or agreement. An information asset is any kind of data or information that has value to an organisation. Information assets can include physical documents, digital files and databases, software programs, and even intangible items like trade secrets and intellectual property. Information assets can have value in a variety of ways. They may contain personally identifying information (PII) about customers, employees or other stakeholders that could be used by bad actors for financial gain or identity theft. They could contain sensitive information about your organisation’s finances, research or operations that would provide a competitive advantage to your competitors if they were able to get their hands on it.This is why it is important that staff and contractors whose business are terminated with an organisation are compelled to return all such assets in their possession.

The termination process must be legally concluded with the return of all tangible and electronic assets previously assigned owned or entrusted to the organization.This means that the organisation must have a written policy that defines clear rules for returning assets upon termination. Organisations must also have personnel that will confirm receipt of returned assets, and ensure that assets are properly inventoried and accounted for. When an employee or external user buys the equipment of the company or uses his / her own personal equipment, it is important to follow protocols to ensure that all relevant information is transmitted to the company and safely removed from the equipment. In situations where an employee or external user is aware that this information is necessary for ongoing operations, it should be reported and transmitted to the organization. During the notice period of termination, unauthorized copying of sensitive information ( e.g. intellectual property) by terminated workers and contractors should be monitored by the company.

Control

Personnel and other interested parties as appropriate should return all the organization’s assets in their possession upon change or termination of their employment, contract or agreement.

Purpose

To protect the organization’s assets as part of the process of changing or terminating employment, contract or agreement.

ISO 27002 Implementation Guidance

The change or termination process should be formalized to include the return of all previously issued physical and electronic assets owned by or entrusted to the organization. In cases where personnel and other interested parties purchase the organization’s equipment or use their own personal equipment, procedures should be followed to ensure that all relevant information is traced and transferred to the organization and securely deleted from the equipment. In cases where personnel and other interested parties have knowledge that is important to ongoing operations, that information should be documented and transferred to the organization. During the notice period and thereafter, the organization should prevent unauthorized copying of relevant information (e.g. intellectual property) by personnel under notice of termination. The organization should clearly identify and document all information and other associated assets to be returned which can include:

1. user endpoint devices
2. portable storage devices
3. specialist equipment
4. authentication hardware (e.g. mechanical keys, physical tokens and smart cards) for information systems, sites and physical archives
5. physical copies of information.

Other information

It can be difficult to return information held on assets which are not owned by the organization. In such cases, it is necessary to restrict the use of information using other information security controls such as access rights management or use of cryptography.

This is designed to protect the organisation’s assets as part of the process of changing or terminating employment, contract or agreement. The intent of this control is to prevent authorized individuals from retaining assets (e.g., equipment, information, software, etc.) that belong to the organisation. When employees and contractors leave your organisation, you have to make sure that they don’t take any sensitive data with them. You do that by identifying any potential threats and monitoring the user’s activities before their departure. This control is to ensure that the individual does not have access to the IT systems and networks when they are terminated. Organisations should establish a formal termination process which ensures that individuals are not able to gain access to any IT systems after their departure from the organisation. This can be done by revoking all permissions, disabling accounts and removing access from building premises. Procedures should be in place to ensure that employees, contractors, and other relevant parties return all organisational assets that are no longer required for business purposes or are due for replacement. Organisations may also want to perform a final check of the individual’s work area to ensure that all sensitive information has been returned.

For example:

• Upon separation, organisation-owned equipment is collected (e.g., removable media, laptops).
• Contractors return equipment and information at the end of their contract.

All employees and external party users are expected to return any organisational and information assets upon termination of their employment, contract or agreement. As such it must be an obligation for employees and external users to return all the assets and these obligations would be expected in the relevant agreements with staff, contractors and others. A solid, documented process is also required to ensure that the return of assets is appropriately managed and can be evidenced for each person or supplier that goes through it. Where assets are not returned according to the process, unless otherwise agreed and documented as part of the exit process, the non-return should be logged as a security incident and followed-up. The return of assets procedure is never fool proof and this also underlines the need for periodic audit of assets to ensure their continued protection. In order to meet the requirements, the change or termination process should be formalized to include the return of all previously issued physical and electronic assets owned by or entrusted to the organisation. The process should also ensure that any and all access rights, accounts, digital certificates and passwords are removed. This formalization is especially important in cases where a change or termination occurs unexpectedly, such as death or resignation, in order to prevent unauthorized access to organisation assets which could lead to a data breach. The process should ensure that all assets are accounted for, and that they have all been returned/disposed of in a secure manner. The organisation should clearly identify and document all information and other associated assets to be returned which can include:

1. user endpoint devices;
2. portable storage devices;
3. specialist equipment;
4. authentication hardware (e.g. mechanical keys, physical tokens and smart cards) for information systems, sites and physical archives;
5. physical copies of information.

This can be achieved through a formal checklist containing all necessary items to be returned/disposed of and completed by the user upon termination, along with any necessary signatures confirming that the assets have been returned/disposed of successfully.It is critical that organizations protect their information on the equipment of employees when their employment is terminated. Make sure all relevant information that will be needed by the institution is preserved, but all information on the asset is erased. Develop an employee exit checklist that addresses the return of all institutional assets, physical or information, before the employee’s last day. There are, of course, emergency situations dealing with immediate termination that may not lend themselves to a measured checklist. Create a simple checklist for those instances as well. Get to know a resource in your HR area and work with that resource to incorporate physical and electronic assets at termination. As stated before, assets can be a variety of items. Employee knowledge is also an information asset to the organization. Preserve their relevant knowledge, document, before the individual leaves the institution, and ensure that knowledge is in the organization’s possession. Once again, use the checklist to incorporate this aspect of asset return. A sample may include:

• The employee has returned all computing equipment to IT.
• IT will preserve the information on the equipment by copying to an external drive or employee group shared file server. Preserved information will be given to the employee’s supervisor.
• The employee has transferred all institutional information from his/her personal equipment and given that to their supervisor.
• Employee rights to information assets have been terminated as of this date.
• Employee knowledge transfer has occurred.

Don’t forget about the contractors, consultants, or any other external third party upon termination of contract or agreement. The same rules apply. You may wish to have a separate asset security checklist for all external agents and ensure this information is part of their contract or agreement.