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
ISMS: Access control Page 1 of 29
 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
Objective:
To limit access to information and information processing facilities.
A.9.1.1 Access control policy

Control
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

Control
Users should only be provided with access to the network and network services that they have
been specifically authorized to use.
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, ifexceeded.
 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 beingused 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

Objective:
To ensure authorized user access and to prevent unauthorized access to systems and
services.
9.2.1 User registration and de-registration

Control
A formal user registration and de-registration process should be implemented to enable the
assignment of access rights.
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

Control
A formal user access provisioning process should be implemented to assign or revoke access
rights for all user types to all systems and services.
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

Control
The allocation and use of privileged access rights should be restricted and controlled.
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

Control
The allocation of secret authentication information should be controlled through a formal
management process.
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

Control
Asset owners should review users’ access rights at regular intervals.
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
Control
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.
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.
2. 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
3. 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.
4. 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::
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.
5. 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

Objective:
To make users accountable for safeguarding their authentication information.
9.3.1 Use of secret authentication information

Control
Users should be required to follow the organization’s practices in the use of secret
authentication information.
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

Objective:
To prevent unauthorized access to systems and applications.
9.4.1 Information access restriction

Control
Access to information and application system functions should be restricted in accordance
with the access control policy.
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

Control
Where required by the access control policy, access to systems and applications should be
controlled by a secure log-on procedure.
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

Control
Password management systems should be interactive and should ensure quality passwords.
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

Control
The use of utility programs that might be capable of overriding system and application controls
should be restricted and tightly controlled.
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

Control
Access to program source code should be restricted.
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.
2. 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).
Challenges:
 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.
s

ISMS Access Control

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ISMS Access Control

Caricato da

Copyright:

Formati disponibili

ISMS: Access control

The terminology of access control:

Activities of access control

ISMS: Access control Page 2 of 29

A.9.1.1 Access control policy

1. security requirements of business applications.

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

9.1.2 Access to networks and network services

1. the networks and network services which are allowed to be accessed.

ISMS: Access control Page 4 of 29

Type of Access Control

ISMS: Access control Page 5 of 29

Access Control Policy

 Roles and responsibilities

Access Control Program

ISMS: Access control Page 6 of 29

Information security is the protection of information against accidental or malicious disclosure,

ISMS: Access control Page 7 of 29

On occasion business information may be disclosed or accessed prematurely, accidentally or

6 Applying the Policy – Passwords

6.1.1 Weak and strong passwords

Everyone must use strong passwords with a minimum standard of:

 At least seven characters.

6.2 Protecting Passwords

 Never reveal your passwords to anyone.

6.3 Changing Passwords

6.4 System Administration Standards

 Authentication of individual users, not groups of users – i.e. no generic accounts.

7 Applying the Policy – Employee Access

 Are commensurate with the tasks they are expected to perform.

7.2 User Registration

7.3 User Responsibilities

ISMS: Access control Page 9 of 29

 Following the Password Policy Statements outlined above in Section 6.

7.4 Network Access Control

7.5 User Authentication for External Connections

7.6 Supplier’s Remote Access to the Organization Network

7.7 Operating System Access Control

 Not displaying any previous login information e.g. username.

7.8 Application and Information Access

10 Review and Revision

 All users must use strong passwords.

9.2 User access management

9.2.1 User registration and de-registration

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

1. Assigning and enabling, or revoking, a user ID;

9.2.2 User access provisioning

9.2.3 Management of privileged access rights

9.2.4 Management of secret authentication information of users

9.2.5 Review of user access rights

1. User Types and Affiliations

The User registration process has, generally, four steps:

Good Password Practices:

 Use strong passwords or long passphrases

What is a Strong Password?

To Change or Not to Change? How Often?

 Password policy should be based on risk, vulnerabilities, and deployed safeguards

Password Management Problems: By no means a comprehensive list

 Need (and failure) to remember multiple passwords

Alternatives to Manage Password Management Problems::

5. Review of Access Rights

9.3 User responsibilities

9.3.1 Use of secret authentication information

Password-protect their desktops/laptops when left unattended