Home » ISMS: Access control

ISMS: Access control

Access control is the process of granting authorised users the right to use a service while preventing access to non-authorised users. Access control can also be referred to as  Access management, rights management or identity management. The Access controls clause 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 to revoke access rights when needed – an important security consideration.
  • Maybe needed for regulatory compliance

The terminology of access control:

  1. Access – refers to the level and the extent of a service’s functionality or data that a user is entitled to use.
  2. Identity – refers to the information about the user that distinguishes them as an individual and which verifies their status within the organization. By definition, the identity of a user is unique to that user.
  3. Rights – (also called privileges) refer to the actual settings whereby a user is provided access to a service or group of services. Typical rights, or level of access, include read, write, execute, change and delete.
  4. Service or service groups – Most users do not use only one service, and users performing a similar set of activities will use a similar set of services. Instead of providing access to each service for each user separately, it is more efficient to be able to grant each user, access to the whole set of services that they are entitled to use at the same time.
  5. Directory services – refers to a specific type of tool that is used to manage access and rights.

Access control provides the right for users to be able to use a service or group of services. It is, therefore, the execution of policies and actions defined in information security management.

  1. It is the process of granting authorised users the right to use a service while restricting access to non-authorised users
    • Grant access to services, service groups, data or functions
    • Only if they are entitled to that access
  2. Protecting Confidentiality, Integrity and Availability (CIA). Sometimes known as rights management or identity management
    • Remove access when people change roles or jobs
    • Regularly audit access permissions to ensure they are correct
  3. Security incidents and problems related to access management will be discreetly recorded

Activities of access control

  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 fulfilment system)
    • Executing a pre-authorised 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 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 organisation, 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 organisations, 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 organisation 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 organisation 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 organisation. Removing access is usually done in the following circumstances:
    • Death
    • Resignation
    • Dismissal
    • The user has changed roles etc.

A. 9 Access control

A.9.1 Business requirements of access control


To limit access to information and information processing facilities.

A.9.1.1 Access control policy


An access control policy should be established, documented and reviewed based on business and information security requirements.

Implementation guidance

Asset owners should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls reflecting the associated information security risks. Access controls are both logical and physical and these should be considered together. Users and service providers should be given a clear statement of the business requirements to be met by access controls. The policy should take account of the following:

  1. security requirements of business applications.
  2. policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information.
  3. consistency between the access rights and information classification policies of systems and networks.
  4. relevant legislation and any contractual obligations regarding limitation of access to data or services.
  5. management of access rights in a distributed and networked environment which recognizes all types of connections available.
  6. segregation of access control roles, e.g. access request, access authorization, access administration.
  7. requirements for formal authorization of access requests.
  8. requirements for periodic review of access rights.
  9. removal of access rights.
  10. archiving of records of all significant events concerning the use and management of user identities and secret authentication information
  11. roles with privileged access

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

  1. establishing rules based on the premise “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. rules which require specific approval before enactment and those which do not. Access control rules should be supported by formal procedures and defined responsibilities.

Role-based access control is an approach used successfully by many organisations to link access rights with business roles. Two of the frequent principles directing the access control policy are:

  1. Need-to-know: you are only granted access to the information you need to perform your tasks (different tasks/roles mean different need-to-know and hence different access profile).
  2. Need-to-use: you are only granted access to the information processing facilities (IT equipment, applications, procedures, rooms) you need to perform your task/job/role.

9.1.2 Access to networks and network services


Users should only be provided with access to the network and network services that they have been specifically authorized to use.

Implementation guidance

A policy should be formulated concerning the use of networks and network services. This policy should cover:

  1. the networks and network services which are allowed to be accessed.
  2. authorization procedures for determining who is allowed to access which networks and networked services.
  3. management controls and procedures to protect access to network connections and network services.
  4. the means used to access networks and network services (e.g. use of VPN or wireless network).
  5. user authentication requirements for accessing various network services.
  6. monitoring of the use of network services.

The policy on the use of network services should be consistent with the organization’s access control policy.
Unauthorized and insecure connections to network services can affect the whole organization. This control is particularly important for network connections to sensitive or critical business applications or to users in high-risk locations, e.g. public or external areas that are outside the organization’s information security management and control

Organization create, collect, maintain, and makes available large amounts of information in support of their missions. This information is an organizational asset that must be administered and protected in accordance with their value and in conformance with federal, state, and organizational rules and regulations.

The staff, the workers, management, vendors retirees, customers, prospective customers, and members of the community access and utilize different types of information stored on and accessible via organizational systems to perform the numerous tasks required by their respective roles or seek information about products and services provided by the organization. Examples include:

  • Top management
    •  Management resources (Management Information systems, library, etc.)
    • Online ERP systems
  • Staff
    • Employee directory
    • Online human resources systems (timesheets, payroll, benefits, etc.)
  • Purchase
    • Inventory management
    • ERP System
  • All
    • Employee directory
    • Emergency notification systems

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 institutional rules and regulations.

Type of Access Control

  1. Centralized Access Control: Rather than maintaining separate accounts on each system, some organizations use a central account database that all systems can authenticate against. In some environments, a Novell server or Windows domain controller functions as the central authentication system. These systems can also be used to enforce policies, limiting users to specifically authorized actions and data. With the increasing number of Web-based services, many organizations are implementing mechanisms to integrate their central authentication systems with their Web-based applications. The JA-SIG Central Authentication Service (CAS) can be used to securely integrate Web authentication in addition to providing single sign-on capabilities where appropriate. Other organizations use Kerberos because it supports a broader range of applications and operating systems. However, because Windows systems work best in a Windows domain, even organizations that use Kerberos generally maintain a Windows domain controller that is synchronized with the accounts in their Kerberos domain. Lastly, Lightweight Directory Access Protocol (LDAP) is another approach to centralized authentication and authorization that is increasingly used in many of the organization.
  2. Decentralized Access Control: It is also not uncommon to find many organizations opting for a decentralized or distributed user account databases where the verification of authorization is performed by various entities located throughout the organization. Common disadvantages of decentralized access control systems are that many times are duplicative, require the coordinated work of several teams, and the administrative overhead is high since changes may need to be implemented throughout numerous locations. Often times each location develops into a silo that is maintained by local administrators without the input/coordination of the other teams. Decentralized access control implementations do have benefits. A well implemented and coordinated distributed system does not have a single point of failure. If one access control point fails, others can balance the load until the problem is resolved

Access Control Policy

Access Control policies should clearly communicate the organization’s business requirements regarding 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 is used to determine the types of credentials used?
  • What criteria is 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

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.

Example of IT Access policy template

1 Policy Statement
[Organization Name] will establish specific requirements for protecting information and information systems against unauthorised access
[Organization Name] will effectively communicate the need for information and information system access control.

2 Purpose

Information security is the protection of information against accidental or malicious disclosure, modification or destruction. Information is an important, valuable asset of [Organization Name] which must be managed with care. All information has a value to the Organization. However, not all of this information has an equal value or requires the same level of protection.
Access controls are put in place to protect information by controlling who has the rights to use different information resources and by guarding against unauthorised use.
Formal procedures must control how access to information is granted and how such access is changed.
This policy also mandates a standard for the creation of strong passwords, their protection and frequency of change.

3 Scope

This policy applies to all [Organization Name] Organizationlors, Committees, Departments, Partners, Employees of the Organization (including system support staff with access to privileged administrative passwords), contractual third parties and agents of the Organization with any form of access to [Organization Name’s] information and information systems.

4 Definition

Access control rules and procedures are required to regulate who can access [Organization Name] information resources or systems and the associated access privileges. This policy applies at all times and should be adhered to whenever accessing [Organization Name] information in any format, and on any device.

5 Risks

On occasion business information may be disclosed or accessed prematurely, accidentally or unlawfully. Individuals or companies, without the correct authorisation and clearance, may intentionally or accidentally gain unauthorised access to business information which may adversely affect day to day business. This policy is intended to mitigate that risk.

Non-compliance with this policy could have a significant effect on the efficient operation of the Organization and may result in financial loss and an inability to provide necessary services to our customers.

6 Applying the Policy – Passwords
6.1 Choosing Passwords

Passwords are the first line of defence for our ICT systems and together with the user ID helps to establish that people are who they claim to be.

A poorly chosen or misused password is a security risk and may impact upon the confidentiality, integrity or availability of our computers and systems.

6.1.1 Weak and strong passwords

A weak password is one which is easily discovered, or detected, by people who are not supposed to know it. Examples of weak passwords include words picked out of a dictionary, names of children and pets, car registration numbers and simple patterns of letters from a computer keyboard.
A strong password is a password that is designed in such a way that it is unlikely to be detected by people who are not supposed to know it, and difficult to work out even with the help of a computer.

Everyone must use strong passwords with a minimum standard of:

  • At least seven characters.
  • Contain a mix of alpha and numeric, with at least one digit
  • More complex than a single word (such passwords are easier for hackers to crack).
  • [Amend the above as required for your local needs]

The Government advises using Environ passwords with the following format: consonant, vowel, consonant, consonant, vowel, consonant, number, number. An example for illustration purposes is provided below:

  • pinray45

6.2 Protecting Passwords

It is of utmost importance that the password remains protected at all times. The following guidelines must be adhered to at all times [amend the list as appropriate]:

  • Never reveal your passwords to anyone.
  • Never use the ‘remember password’ function.
  • Never write your passwords down or store them where they are open to theft.
  • Never store your passwords in a computer system without encryption.
  • Do not use any part of your username within the password.
  • Do not use the same password to access different [Organization Name] systems.
  • Do not use the same password for systems inside and outside of work.

6.3 Changing Passwords

All user-level passwords must be changed at a maximum of every 90 days, or whenever a system prompts you to change it. Default passwords must also be changed immediately. If you become aware or suspect, that your password has become known to someone else, you must change it immediately and report your concern to [Name a department – e.g. IT Helpdesk]. Users must not reuse the same password within 20 password changes [amend as appropriate].

6.4 System Administration Standards

The password administration process for individual [Organization Name] systems is well-documented and available to designated individuals.
All [Organization Name] IT systems will be configured to enforce the following:

  • Authentication of individual users, not groups of users – i.e. no generic accounts.
  • Protection with regards to the retrieval of passwords and security details.
  • System access monitoring and logging – at a user level.
  • Role management so that functions can be performed without sharing passwords.
  • Password admin processes must be properly controlled, secure and auditable.

7 Applying the Policy – Employee Access

7.1 User Access Management

Formal user access control procedures must be documented, implemented and kept up to date for each application and information system to ensure authorised user access and to prevent unauthorised access. They must cover all stages of the lifecycle of user access, from the initial registration of new users to the final de-registration of users who no longer require access. These must be agreed by [Organization Name]. Each user must be allocated access rights and permissions to computer systems and data that:

  • Are commensurate with the tasks they are expected to perform.
  • Have a unique login that is not shared with or disclosed to any other user.
  • Have an associated unique password that is requested at each new login.

User access rights must be reviewed at regular intervals to ensure that the appropriate rights are still allocated. System administration accounts must only be provided to users that are required to perform system administration tasks.

7.2 User Registration

A request for access to the Organization’s computer systems must first be submitted to the [Name a department – e.g. Information Services Helpdesk] for approval. Applications for access must only be submitted if approval has been gained from [Name a role – e.g. your line manager].

When an employee leaves the Organization, their access to computer systems and data must be suspended at the close of business on the employee’s last working day. It is the responsibility of the [Name a role – e.g. your line manager] to request the suspension of the access rights via the [Name a department – e.g. Information Services Helpdesk].

7.3 User Responsibilities

It is a user’s responsibility to prevent their userID and password is used to gain unauthorised access to Organization systems by:

  • Following the Password Policy Statements outlined above in Section 6.
  • Ensuring that any PC they are using that is left unattended is locked or logged out.
  • Leaving nothing on display that may contain access information such as login names and passwords.
  • Informing [Name a department – e.g. Information Services Helpdesk – and any relevant roles] of any changes to their role and access requirements.

7.4 Network Access Control

The use of modems on non-Organization owned PC’s connected to the Organization’s network can seriously compromise the security of the network. The normal operation of the network must not be interfered with. Specific approval must be obtained from [Name a department – e.g. Information Services] before connecting any equipment to the Organization’s network.

7.5 User Authentication for External Connections

Where remote access to the [Organization Name] network is required, an application must be made via the [Name a department – e.g. IT Helpdesk]. Remote access to the network must be secured by two-factor authentication consisting of a username and one other component, for example, a [Name a relevant authentication token]. For further information please refer to [name a relevant policy -likely to be Remote Working Policy].

7.6 Supplier’s Remote Access to the Organization Network

Partner agencies or 3rd party suppliers must not be given details of how to access the Organization’s network without permission from [Name a department – e.g. IT Helpdesk]. Any changes to supplier’s connections must be immediately sent to the [Name a department – e.g. IT Helpdesk] so that access can be updated or ceased. All permissions and access methods must be controlled by [Name a department – e.g. IT Helpdesk].

Partners or 3rd party suppliers must contact the [Name a department – e.g. IT Helpdesk] before connecting to the [Organization Name] network and a log of activity must be maintained. Remote access software must be disabled when not in use.

7.7 Operating System Access Control
Access to operating systems is controlled by a secure login process. The access control defined in the User Access Management section (section 7.1) and the Password section (section 6) above must be applied. The login procedure must also be protected by:

  • Not displaying any previous login information e.g. username.
  • Limiting the number of unsuccessful attempts and locking the account, if exceeded.
  • The password characters being hidden by symbols.
  • Displaying a general warning notice that only authorised users are allowed.

All access to operating systems is via a unique login id that will be audited and can be traced back to each individual user. The login id must not give any indication of the level of access that it provides to the system (e.g. administration rights). System administrators must have individual administrator accounts that will be logged and audited. The administrator account must not be used by individuals for normal day to day activities.

7.8 Application and Information Access

Access within software applications must be restricted using the security features built into the individual product. The [Name a department – e.g. IT Helpdesk or ‘business owner’] of the software application is responsible for granting access to the information within the system. The access must [amend the list as appropriate]:

  • Be compliant with the User Access Management section (section 7.1) and the Password section (section 6) above.
  • Be separated into clearly defined roles.
  • Give the appropriate level of access required for the role of the user.
  • Be unable to be overridden (with the admin settings removed or hidden from the user).
  • Be free from alteration by rights inherited from the operating system that could allow unauthorised higher levels of access.
  • Be logged and auditable.

8 Policy Compliance

If any user is found to have breached this policy, they may be subject to [Organization Name’s] disciplinary procedure. If a criminal offence is considered to have been committed further action may be taken to assist in the prosecution of the offender(s). If you do not understand the implications of this policy or how it may apply to you, seek advice from [name appropriate department].

9 Policy Governance

The following table identifies who within [Organization Name] is Accountable, Responsible, Informed or Consulted with regards to this policy. The following definitions apply:

  • Responsible – the person(s) responsible for developing and implementing the policy.
  • Accountable – the person who has ultimate accountability and authority for the policy.
  • Consulted – the person(s) or groups to be consulted prior to final policy implementation or amendment.
  • Informed – the person(s) or groups to be informed after policy implementation or amendment.

Responsible [Insert appropriate Job Title – e.g. Head of Information Services, Head of Human Resources etc.]
Accountable [Insert appropriate Job Title – e.g. Section 151 Officer, Director of Finance etc. It is important that only one role is held accountable.]
Consulted [Insert appropriate Job Title, Department or Group – e.g. Policy Department, Employee Panels, Unions etc.]
Informed [Insert appropriate Job Title, Department or Group – e.g. All Organization Employees, All Temporary Staff, All Contractors etc.]

10 Review and Revision

This policy will be reviewed as it is deemed appropriate, but no less frequently than every 12 months. Policy review will be undertaken by [Name an appropriate role].

11 References
The following [Organization Name] policy documents are directly relevant to this policy, and are referenced within this document [amend the list as appropriate]:
• Remote Working Policy.
The following [Organization Name] policy documents are indirectly relevant to this policy [amend the list as appropriate]:

  • Email Policy.
  • Internet Acceptable Usage Policy.
  • Software Policy.
  • GCSx Acceptable Usage Policy and Personal Commitment Statement.
  • Legal Responsibilities Policy.
  • Computer, Telephone and Desk Use Policy.
  • Removable Media Policy.
  • Information Protection Policy.
  • Human Resources Information Security Standards.
  • Information Security Incident Management Policy.
  • IT Infrastructure Policy.
  • Communications and Operation Management Policy.

12 Key Messages

  • All users must use strong passwords.
  • Passwords must be protected at all times and must be changed at least every 90 days.
  • User access rights must be reviewed at regular intervals.
  • It is a user’s responsibility to prevent their userID and password is being used to gain unauthorised access to Organization systems.
  • Partner agencies or 3rd party suppliers must not be given details of how to access the Organization’s network without permission from [Name a department – e.g. IT Helpdesk].
  • Partners or 3rd party suppliers must contact the [Name a department – e.g. IT Helpdesk] before connecting to the [Organization Name] network.

…………………………………….End of Example…………………………………

9.2 User access management


To ensure authorized user access and to prevent unauthorized access to systems and services.

9.2.1 User registration and de-registration


A formal user registration and de-registration process should be implemented to enable the assignment of access rights.

Implementation guidance

The process for managing user IDs should include:

  1. Using unique user IDs to enable users to be linked to and held responsible for their actions.  The use of shared IDs should only be permitted where they are necessary for business or operational reasons and should be approved and documented.
  2. Immediately disabling or removing user IDs of users who have left the organization.
  3. Periodically identifying and removing or disabling redundant user IDs;
  4. Ensuring that redundant user IDs are not issued to other users.

Providing or revoking access to information or information processing facilities is usually a two step  procedure:

  1. Assigning and enabling, or revoking, a user ID;
  2. Providing, or revoking, access rights to such user ID

9.2.2 User access provisioning


A formal user access provisioning process should be implemented to assign or revoke access rights for all user types to all systems and services.

Implementation guidance

The provisioning process for assigning or revoking access rights granted to user IDs should include:

  1. Obtaining authorization from the owner of the information system or service for the use of the information system or service.  Separate approval for access rights from management may also be appropriate.
  2. Verifying that the level of access granted is appropriate to the access policies and is consistent with other requirements such as segregation of duties.
  3. Ensuring that access rights are not activated (e.g. by service providers) before authorization procedures are completed.
  4. Maintaining a central record of access rights granted to a user ID to access information systems and services.
  5. Adapting access rights of users who have changed roles or jobs and immediately removing or
    blocking the access rights of users who have left the organization;
  6. Periodically reviewing access rights with owners of the information systems or services.

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 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 or contractors.

9.2.3 Management of privileged access rights


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

Implementation guidance

The allocation of privileged access rights should be controlled through a formal authorization process in accordance with the relevant access control policy. The following steps should be considered:

  1. The privileged access rights associated with each system or process, e.g. operating system, database management system and each application and the users to whom they need to be allocated should be identified.
  2. Privileged access rights should be allocated to users on a need-to-use basis and on an event-by-event basis in line with the access control policy, i.e. based on the minimum requirement for their functional roles.
  3. An authorization process and a record of all privileges allocated should be maintained. Privileged access rights should not be granted until the authorization process is complete.
  4. Requirements for the expiry of privileged access rights should be defined.
  5. Privileged access rights should be assigned to a user ID different from those used for regular business activities. Regular business activities should not be performed from privileged ID.
  6. The competences of users with privileged access rights should be reviewed regularly in order to verify if they are in line with their duties.
  7. Specific procedures should be established and maintained in order to avoid the unauthorized use of generic administration user IDs, according to systems’ configuration capabilities.
  8. For generic administration user IDs, the confidentiality of secret authentication information should be maintained when shared (e.g. changing passwords frequently and as soon as possible when a privileged user leaves or changes job, communicating them among privileged users with appropriate mechanisms).

Inappropriate use of system administration 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.

9.2.4 Management of secret authentication information of users


The allocation of secret authentication information should be controlled through a formal management process.

Implementation guidance

The process should include the following requirements:

  1. Users should be required to sign a statement to keep personal secret authentication information confidential and to keep group (i.e. shared) secret authentication information solely within the members of the group; this signed statement may be included in the terms and conditions of employment.
  2. When users are required to maintain their own secret authentication information they should be provided initially with secure temporary secret authentication information`, which they are forced to change on first use.
  3. Procedures should be established to verify the identity of a user prior to providing new, replacement or temporary secret authentication information.
  4. Temporary secret authentication information should be given to users in a secure manner; the use of external parties or unprotected (clear text) electronic mail messages should be avoided.
  5. Temporary secret authentication information should be unique to an individual and should not be guessable.
  6. Users should acknowledge receipt of secret authentication information.
  7. Default vendor secret authentication information should be altered following installation of systems or software.

Passwords are a commonly used type of secret authentication information and are a common means of verifying a user’s identity. Other types of secret authentication information are cryptographic keys and other data stored on hardware tokens (e.g. smart cards) that produce authentication codes.

9.2.5 Review of user access rights


Asset owners should review users’ access rights at regular intervals.

Implementation guidance

The review of access rights should consider the following:

  1. Users’ access rights should be reviewed at regular intervals and after any changes, such as promotion, demotion or termination of employment.
  2. User access rights should be reviewed and re-allocated when moving from one role to another within the same organization.
  3. Authorizations for privileged access rights should be reviewed at more frequent intervals.
  4. Privilege allocations should be checked at regular intervals to ensure that unauthorized privileges have not been obtained.
  5. Changes to privileged accounts should be logged for periodic review.

This control compensates for possible weaknesses in the execution of controls 9.2.1, 9.2.2 and 9.2.6.

9.2.6 Removal or adjustment of access rights


The access rights of all employees and external party users to information and information processing facilities should be removed upon termination of their employment, contract or agreement, or adjusted upon change.

Implementation guidance

Upon termination, the access rights of an individual to information and assets associated with information processing facilities and services should be removed or suspended. This will determine whether it is necessary to remove access rights. Changes of employment should be reflected in the removal of all access rights that were not approved for the new employment. The access rights that should be removed or adjusted include those of physical and logical access. Removal or adjustment can be done by removal, revocation or replacement of keys, identification cards, information processing facilities or subscriptions. Any documentation that identifies access rights of employees and contractors should reflect the removal or adjustment of access rights. If a departing employee or external party user has known passwords for user IDs remaining active, these should be changed upon termination or change of employment, contract or agreement.
Access rights for information and assets associated with information processing facilities should be reduced or removed before the employment terminates or changes, depending on the evaluation of risk factors such as:

  1. Whether the termination or change is initiated by the employee, the external party user or by management, and the reason for termination;
  2. The current responsibilities of the employee, external party user or any other user;
  3. The value of the assets currently accessible.

In certain circumstances, access rights may be allocated on the basis of being available to more people than the departing employee or external party user, e.g. group IDs. In such circumstances, departing individuals should be removed from any group access lists and arrangements should be made to advise all other employees and external party users involved to no longer share this information with the person departing. In cases of management-initiated termination, disgruntled employees or external party users can deliberately corrupt information or sabotage information processing facilities. In cases of persons resigning or being dismissed, they may be tempted to collect information for future use.

  1. User Types and Affiliations

All staff have 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, employee, vendors, client, 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 website etc.
  1. User Registration

Identification is the mechanism to ensure that a user, program, or device is the entity it claims to be.

User Registration:

The User registration process has, generally, four steps:

  • Identity Vetting: the collection and validation of identity information. This information may include full name as it appears in identity documents, date of birth, current address, existing relationship with the organization (e.g, hired employee, registered contractor, etc.
  • Identity Proofing: aligning collected data and matching an actual person to it. This can be done either:
    • By leveraging a pre-existing relationship with an individual (e.g., individual was a former contractor or a former employee)
    • In-person. The individual is required to go to the HR office charged with User registration and produce a valid current government photo ID that contains the individual’s picture (e.g., driver’s license or passport) and an address. The office compares the picture to the person, verifies the information with its records and, if everything checks, records the sources of proof and approves the issue of a credential.
    • If the individual is unable to fulfil the proofing requirements in-person (e.g., staff in a small remote office ), they can forward to the HR office charged with User registration, via email, mail, fax, a valid current government ID number (e.g., driver’s license or passport) and either a second government ID number or a financial account number (e.g., checking or savings account, credit card) with supporting documentation. The HR contacts the corresponding agencies and verifies the information provided with their records, and if everything checks record the sources of proof and approve the issue of a credential.
  • Creation of a master identity record
  • Issuance of credentials – each credential issued shall include a unique identifier (e.g., UserId) that distinguishes it from all other credentials issued to the individual and shall clearly associate the credential unique identifier to the individual’s master identity record. Credentials are usually issued as an UserId / Password pair but they can also be embedded in other devices such as Id Cards, second-factor tokens  etc
  1. Privilege Management

Privilege management is 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 related to privilege management are 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 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.

  1. Password Management

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 institution 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? 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 the information resource, 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 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

Alternatives to Manage Password Management Problems::


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.

  1. 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 which 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.

9.3 User responsibilities


To make users accountable for safeguarding their authentication information.

9.3.1 Use of secret authentication information


Users should be required to follow the organization’s practices in the use of secret authentication information.

Implementation guidance

All users should be advised to:

  1. Keep secret authentication information confidential, ensuring that it is not divulged to any other parties, including people of authority;
  2. Avoid keeping a record (e.g. on paper, software file or hand-held device) of secret authentication information, unless this can be stored securely and the method of storing has been approved (e.g. password vault);
  3. Change secret authentication information whenever there is any indication of its possible compromise;
  4. When passwords are used as secret authentication information, select quality passwords with sufficient minimum length which are:
    • easy to remember
    • not based on anything somebody else could easily guess or obtain using person related information, e.g. names, telephone numbers and dates of birth etc.
    • not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries);
    • free of consecutive identical, all-numeric or all-alphabetic characters;
    • if temporary, changed at the first log-on;
  5. Not share individual user’s secret authentication information;
  6. Ensure proper protection of passwords when passwords are used as secret authentication information in automated log-on procedures and are stored;
  7. Not use the same secret authentication information for business and non-business purposes.

Provision of Single Sign-On (SSO) or other secret authentication information management tools reduce the amount of secret authentication information that users are required to protect and thus can increase the effectiveness of this control. However, these tools can also increase the impact of disclosure of secret authentication information.

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 or 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 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

9.4 System and application access control


To prevent unauthorized access to systems and applications.

9.4.1 Information access restriction


Access to information and application system functions should be restricted in accordance with the access control policy.

Implementation guidance

Restrictions to access should be based on individual business application requirements and in accordance with the defined access control policy. The following should be considered in order to support access restriction requirements:

  1. Providing menus to control access to application system functions.
  2. Controlling which data can be accessed by a particular user.
  3. Controlling the access rights of users, e.g. read, write, delete and execute.
  4. Controlling the access rights of other applications.
  5. Limiting the information contained in outputs.
  6. Providing physical or logical access controls for the isolation of sensitive applications, application data, or systems.

9.4.2 Secure log-on procedures


Where required by the access control policy, access to systems and applications should be controlled by a secure log-on procedure.

Implementation guidance

A suitable authentication technique should be chosen to substantiate the claimed identity of a user. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as cryptographic means, smart cards, tokens or biometric means, should be used. The procedure for logging into a system or application should be designed to minimize the opportunity for unauthorized access. The log-on procedure should, therefore, disclose the minimum of information about the system or application, in order to avoid providing an unauthorized user with any unnecessary assistance. A good log-on procedure should:

  1. not display system or application identifiers until the log-on process has been successfully completed.
  2. display a general notice warning that the computer should only be accessed by authorized users.
  3. not provide help messages during the log-on procedure that would aid an unauthorized user.
  4. validate the log-on information only on completion of all input data. If an error condition arises, the system should not indicate which part of the data is correct or incorrect.
  5. protect against brute force log-on attempts.
  6. log unsuccessful and successful attempts.
  7. raise a security event if a potential attempted or successful breach of log-on controls is detected
  8. display the following information on completion of a successful log-on:
    •  date and time of the previous successful log-on;
    • details of any unsuccessful log-on attempts since the last successful log-on;
  9. not display a password being entered;
  10. not transmit passwords in clear text over a network;
  11. terminate inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the organization’s security management or on mobile devices;
  12. restrict connection times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access.

Passwords are a common way to provide identification and authentication based on a secret that only the user knows. The same can also be achieved with cryptographic means and authentication protocols. The strength of user authentication should be appropriate for the classification of the information to be accessed. If passwords are transmitted in clear text during the log-on session over a network, they can be captured by a network ”sniffer” program.

9.4.3 Password management system


Password management systems should be interactive and should ensure quality passwords.

Implementation guidance

A password management system should:
a) enforce the use of individual user IDs and passwords to maintain accountability;
b) allow users to select and change their own passwords and include a confirmation procedure to allow for input errors;
c) enforce a choice of quality passwords;
d) force users to change their passwords at the first log-on;
e) enforce regular password changes and as needed;
f) maintain a record of previously used passwords and prevent re-use;
g) not display passwords on the screen when being entered;
h) store password files separately from application system data;
i) store and transmit passwords in protected form.

Some applications require user passwords to be assigned by an independent authority; in such cases, points b), d) and e) of the above guidelines do not apply. In most cases, the passwords are selected and maintained by users.

9.4.4 Use of privileged utility programs


The use of utility programs that might be capable of overriding system and application controls should be restricted and tightly controlled.

Implementation guidance

The following guidelines for the use of utility programs that might be capable of overriding system and application controls should be considered:
a) use of identification, authentication and authorization procedures for utility programs;
b) segregation of utility programs from applications software;
c) limitation of the use of utility programs to the minimum practical number of trusted, authorized users.
d) authorization for the ad-hoc use of utility programs;
e) limitation of the availability of utility programs, e.g. for the duration of an authorized change;
f) logging of all use of utility programs;
g) defining and documenting of authorization levels for utility programs;
h) removal or disabling of all unnecessary utility programs;
i) not making utility programs available to users who have access to applications on systems where segregation of duties is required.

Most computer installations have one or more utility programs that might be capable of overriding system and application controls.

9.4.5 Access control to program source code


Access to program source code should be restricted.

Implementation guidance

Access to program source code and associated items (such as designs, specifications, verification plans and validation plans) should be strictly controlled, in order to prevent the introduction of unauthorized functionality and to avoid unintentional changes as well as to maintain the confidentiality of valuable intellectual property. For program source code, this can be achieved by controlled central storage of such code, preferably in program source libraries. The following guidelines should then be considered to control access to such program source libraries in order to reduce the potential for corruption of computer programs:
a) where possible, program source libraries should not be held in operational systems;
b) the program source code and the program source libraries should be managed according to established procedures;
c) support personnel should not have unrestricted access to program source libraries;
d) the updating of program source libraries and associated items and the issuing of program sources to programmers should only be performed after appropriate authorization has been received;
e) program listings should be held in a secure environment;
f) an audit log should be maintained of all accesses to program source libraries;
g) maintenance and copying of program source libraries should be subject to strict change control procedures
If the program source code is intended to be published, additional controls to help to get assurance on its integrity (e.g. digital signature) should be considered.

  1. Operating System Access Control

a) Single Sign-On

The Central Authentication Service can be used to securely integrate Web authentication in addition to providing single sign-on capabilities where appropriate. Although having a central authentication system makes account management easier, the exposure of one stolen account is greater when it gives the thief access to multiple systems on the network. Therefore, single sign-on is not necessarily desirable in higher education environments where password theft is a common risk. Less sign-on is ideal – using centralized authentication for most systems but maintaining separate accounts on computer systems that contain particularly sensitive data and require added protection.

b) Authentication

Authentication is the mechanism to confirm the identity of an entity requesting access to an information resource. Authentication is often a prerequisite to allowing access to an information resource. To be properly authenticated, the entity is required to provide credentials – a unique identifier or NetId and a password, passphrase or token. The credentials are compared to the identifying information previously stored on the entity and if the credentials match the stored information, the entity is authenticated.

Most organization require all members of their communities to have their own unique username and password to access certain IT resources. In addition, institutions authenticate these individuals before allowing them to connect to the network or Internet. This approach not only enables the organization to attribute network activities to individual accounts, but It also gives the opportunity to scan systems for vulnerabilities before they connect to the network.

Are a Username and Password Enough for Authentication?

Information security practitioners are increasingly making the case that passwords and password practices are bad and getting worse. Specifically, that usernames and passwords are no longer sufficient to authenticate to information resources containing confidential information. Two-Factor Authentication is the use of an additional factor to minimize the probability of fraudulent authentication.

What Is Two-Factor Authentication?

It is the use of two independent means of evidence (factors) to assert the identity of a user requesting access to some application or service to the organization that provides the application or service. The objective of two-factor authentication, as a method of electronic computer authentication, is to decrease the probability that the requestor is not who he/she claims to be (i.e., providing false evidence of his/her identity.) Two-factor authentication is achieved by a combination of any two of the three “Somethings” below:

  1. Something you know
  • Personal Identification Number (PIN)
  • Password

2. Something you have

  • Smartphone
  • Token
  • ID Badge / Smartcard

3. Something you are

  • Fingerprint
  • Retinal Scan
  • Voice Pattern
  • Typing Cadence

Note that the use of a password in combination with a PIN, for example, is NOT considered two-factor authentication because both pieces of information involve a single factor – something you know. The use of two-factor authentication has been pervasive and ubiquitous for quite a long time already. Any person who has used an ATM machine to withdraw cash for a bank account has used two-factor authentication – you had to provide something you had (a card) and had to provide something you know (a PIN) in order to complete the transaction.

Difference Between Two-Factor and Multi-Factor Authentication

The subtle difference is that, while two-factor authentication uses exactly two factors to assert the identity of a user, multi-factor authentication uses two or more factors to assert identity. In essence, two-factor authentication is a subset of multi-factor authentication. An example of multi-factor authentication would be the requirement to insert a smart-card (something you have) into a smart-card reader, enter a PIN (something you know), and provide a valid fingerprint (something you are) provided via a biometric fingerprint reader. This example uses three factors to assert the identity of a user.

Business Reasons to Consider Two-Factor Authentication

Privacy and the threat of identity theft is increasingly a concern as more of personal information finds its way to online applications.  In addition, passwords alone can frequently be easily guessed or compromised through phishing or hacking, consequently, no longer providing adequate protection for mission-critical information system and applications containing Personally Identifiable Information (PII), Personal Health Information (PHI), and other confidential information.  Some specific concerns:

  • As passwords become easier to guess or compromise, password complexity requirements are quickly coming to exceed what users can reasonably remember.
  • Password proliferation has increased the time and effort spent on user support because of forgotten passwords and the need to reset them.
  • Many password reset mechanisms are insecure, even if the passwords themselves are not.
  • The increased use of single sign-on increases the value of passwords and the number of ways by which those passwords can be potentially attacked.
  • Passwords are all-too-often cached in applications (e.g., email clients or web browsers), stored off-site (e.g.,  POP consolidation of email from multiple accounts), and reused for multiple services, some highly sensitive.
  1. Application and Information Access Control

a) Information Access Restriction

The organizations Access Control page can contain publications, presentations, policies, podcasts, and blogs regarding mechanisms by which a system grants or revokes the right to access some data or perform some action.

b) Sensitive System Isolation

Segregation can be defined as the action or state of setting someone or something apart from other people or things or being set apart. Information resources that are critical to the performance of an institution of higher education’s mission, contain confidential information, or is otherwise considered sensitive should be segregated (i.e., have a dedicated environment) based on sensitivity and risk. The segregation of information resources can be accomplished by:

  • Creating network domains (e.g., public vs internal, critical vs non-critical, etc) – the collection of devices and subjects that share a common security policy – and trusts – a security bridge between domains to enable users of one domain to access resources from another – are common practices in decentralized access implementations. Domains are defined based on risk and the specific security requirements of the domain.
  • Implementing virtual local area networks (VLAN) and/or virtual private networks (VPN) for specific user/application groups
  • Controlling network data flows using network equipment routing/switching capabilities (e.g., access control lists (ACLs))
  1. Federation

 A federation is an association of organizations that come together to exchange information, as appropriate, about their users and resources in order to enable collaborations and transactions

  • Increasingly, people must easily and securely exchange information in cyberspace among known individuals and be trusted to access restricted resources without having to struggle with numerous and onerous security processes
  • Ideally, individuals would each like a single digital credential that can be securely used to authenticate his or her identity anytime authentication of identity is required to secure any transaction.
  • Traditional forms of authentication and authorization are no longer sufficient or the level of assurance needed by modern internet-based applications
    • Increase security
    • Compliance with federal and state rules
  • Application security is becoming increasingly onerous (multiple applications, multiple enterprises, and multiple user roles in multiple contexts)
    • Inter-institutional collaboration
    • Operational efficiencies and cost control
  • Examples:
    • The organization wants to offer services to their constituents but doesn’t want to host them.
    • Vendor wants to offer a service to an organization but doesn’t want the burden of managing user credentials and authentication.
    • The user wants seamless access to services. “Single Sign-On”.
    • Security officer wants to protect organization assets, user identity information, and passwords

Traditional Approach

Federated Approach:

First Steps:

Technically speaking, it involves:

  • new policies
  • new processes
  • new trust relationships
  • new authentication and authorization mechanisms
  • new enterprise directories
  • new applications and much more

Participating organization must agree on:

  • Technical specifications: data attributes to exchange, the software to interoperate with
  • Policy specifications: privacy, establish trust and trustworthy data

Must provide two sets of services:

  • Metadata management: aggregate, distribute, and maintain members’ attribute data, syntax, and semantics
  • Trust management:
    • federation and member operation practices and control
    • privacy and security policies

Things to Think About:

  • Policy work is very slow, but critical – start early
    • Identifiers
    • Privacy
    • Content copyright
  • Do not underestimate the difficulty of application integration with new or legacy infrastructure
  • Authorization can be quite a challenge (e.g., how to identify subsets of people)
  • Consider new support models
  • Communication and coordination are key
  • Keeping all stakeholders motivated and involved can be quite a challenge

Policy Issues:

  • Which services reside where?
  • How is vetting / credentialing performed?
  • How do application owners determine the required Level of Assurance (LOA) for their applications?
  • How do Identity providers comply with applications’ LOA requirements?
  • Who supports the end users and applications?
  • Who audits identity providers’ practices and what standards are used?
  • What is the role of Information Security Governance?

Federation Technology Standards:

  • Security Assertion Markup Language (SAML):
    • Standard developed and ratified by OASIS, an international non-profit standards organization, and managed by the OASIS Security Services Technical Committee
    • Has broad vendor and industry acceptance
  • WS-Federation: a specification developed by IBM, Microsoft, BEA, and others. OASIS now has a technical committee tasked with standardizing WS-Fed.
  • Liberty Identity Federation Framework (ID-FF): now integrated into the SAML 2.0 standard.
  • Open ID: a user-centric distributed web-SSO technology perceived as being lighter-weight and less focused on communities of trust than SAML

Benefits of Federation:

  • Sharing of Resources
  • Collaboration
  • Increase security (fewer usernames and passwords to manage)
  • Lower support costs (no application-based identity management)
  • Improved user experience (fewer usernames and passwords to remember)

Challenges of Federation:

  • Deploying new infrastructure is hard
    • The infrastructure must be there before gains can be realized, which makes justification a challenge.
  • Policy development can take considerable time.
  • Trust can be difficult to achieve.
    • Good policy and governance helps (“trust but verify”)
  • Making it ubiquitous across entities of varying size is a challenge.
    • Many times, it is the smaller organizations that can benefit most.

 Good security and identity practices help ensure that an individual using an electronic credential is the person you think it is. For Service Providers in an identity federation, having Identity Provider Operators support a standard practice set (or profile) can mitigate the risk of service compromise. For Identity Providers, it is a way to provide single sign-on access to applications requiring an increased level of confidence in a credential.

Cloud Computing and Software as a Service (SaaS)

Cloud [computing] describes the use of a collection of distributed services, applications, information and infrastructure comprised of pools of compute, network, information and storage resources. These components can be rapidly orchestrated, provisioned, implemented and decommissioned using an on-demand utility-like model of allocation and consumption.

Software as a Service (SaaS) is the capability provided to the consumer to use a provider’s applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email).


  • The decision to procure cloud computing services or SaaS may be driven mostly by individual departments instead of organizational IT strategy.
  • Integrating separately developed applications into an integrated approach.
    • How to manage access?
    • How to manage to provision?
    • How to integrate these applications into institutional web services?
  • How to reduce the number of credentials

An Alternative Solution:

  • Focus on four activities:
    • Develop an institutional Identity Management System
    • Create a standard set of attributes for each person (eduPerson)
    • Use a federation to enable external access
    • Require institutional developers and in RFPs that service providers support SAML and InCommon
  • InCommon provides an easy to use framework for customers and service providers that will work across higher education.

Mobile Computing and Teleworking

Teleworking (i.e., telecommuting), e-commerce, use of intranets, online education, and the increasing use of portable computing devices (e.g., laptops, tablets, smartphones) are driving the need for access to information resources from any place at any time. Today’s mobile workforce or users are no longer just staff trying to check e-mail from home but part and full-time staff, telecommuters, business partners, vendors. and customers who rely on access to institutional networks to accomplish day-to-day business functions.. Information security controls specifically targeting mobile computing and remote access to information resources are becoming an increasingly critical component of any information security program ensuring the protection of the integrity of the organizational networks while allowing remote access to it.

Challenges of Mobile Computing:

  • User Authentication
  • Protection of Transmitted Data
  • Protection of the Institutional Network

The enable remote access to organisational information resources, institutions of higher education are implementing Virtual Private Networks (VPN) technology to provide a secure connection to the institutional network. VPNs send data securely through a shared network. VPNs can be established between remote users and a network or between two or more networks thus using the Internet as the medium for transmitting information securely over and between networks via a process called tunnelling.

Your Donation can make a difference

We have chosen to make our Resources freely and openly available on the web with the hope that it touches the lives of thousands of readers who visit us daily. We hope our blog has helped in enhancing the knowledge of our readers and added value to the organization and their implementers. We would request you to make donation large and small, so as to provide us with the resources needed to distribute, collect, digitize as it is becoming extremely difficult for us to afford the full cost of updating and enriching our site content. Your contribution will ensure that we can keep our blog up-to-date and add more of the rich resources — such as video — that make a difference for so many worldwide. Your donation will demonstrate your commitment to knowledge as a public good and is an important part of our overall sustainability plan. Your donation is also important in demonstrating to us how much you value the site and motivates us to devote more of our time to developing this blog.

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at or call Pretesh Biswas at +919923345531. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.



Pretesh Biswas

Pretesh Biswas