ISO 27001:2022 A. 8.5 Secure authentication

Access to systems and applications must be controlled by a secure authentication technologies and procedure to prove the identity of the user. This can go beyond the typical password approach into multi-factor authentication, bio metrics, smart cards, and other means of encryption based on the risk being considered. Secure authentication on should be designed so it cannot be easily circumvented and that any authentication information is transmitted and stored encrypted to prevent interception and misuse. Secure authentication is the primary method which human and non-human users engage with when attempting to utilize an organisation’s ICT assets. Over the past decade, authentication technology has undergone a fundamental shift from traditional username/password-based validations into a variety of complementing techniques involving bio metric information, logical and physical access controls, external device authentications, SMS codes and one time passwords (OTP). The organisations should be controlling access to their ICT systems and assets via a secure login gateway. It is a preventative control that maintains risk by implementing technology and establishing topic-specific secure authentication procedures that ensure human and non-human users and identities undergo a robust and secure authentication procedure when attempting to access ICT resources.

Control

Secure authentication technologies and procedures should be implemented based on information access restrictions and the topic-specific policy on access control.

Purpose

To ensure a user or an entity is securely authenticated, when access to systems, applications and services is granted.

ISO 27002 Implementation Guidance

A suitable authentication technique should be chosen to substantiate the claimed identity of a user, software, messages and other entities. The strength of authentication should be appropriate for the classification of the information to be accessed. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as digital certificates, smart cards, tokens or bio metric means, should be used. Authentication information should be accompanied by additional authentication factors for accessing critical information systems (also known as multi-factor authentication). Using a combination of multiple authentication factors, such as what you know, what you have and what you are, reduces the possibilities for unauthorized accesses. Multi-factor authentication can be combined with other techniques to require additional factors under specific circumstances, based on predefined rules and patterns, such as access from an unusual location, from an unusual device or at an unusual time. Biometric authentication information should be invalidated if it is ever compromised. Biometric authentication can be unavailable depending on the conditions of use (e.g. moisture or aging). To prepare for these issues, biometric authentication should be accompanied with at least one alternative authentication technique. The procedure for logging into a system or application should be designed to minimize the risk of unauthorized access. Log-on procedures and technologies should be implemented considering the following:

1. not displaying sensitive system or application information until the log-on process has been successfully completed in order to avoid providing an unauthorized user with any unnecessary assistance;
2. displaying a general notice warning that the system or the application or the service should only be accessed by authorized users;
3. not providing help messages during the log-on procedure that would aid an unauthorized user (e.g. if an error condition arises, the system should not indicate which part of the data is correct or incorrect);
4. validating the log-on information only on completion of all input data;
5. protecting against brute force log-on attempts on usernames and passwords [e.g. using completely automated public Turing test to tell computers and humans apart (CAPTCHA), requiring password reset after a predefined number of failed attempts or blocking the user after a maximum number of errors];
6. logging unsuccessful and successful attempts;
7. raising a security event if a potential attempted or successful breach of log-on controls is detected (e.g. sending an alert to the user and the organization’s system administrators when a certain number of wrong password attempts has been reached);
8. displaying or sending the following information on a separate channel 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 displaying a password in clear text when it is being entered; in some cases, it can be required to de-activate this functionality in order to facilitate user log-on (e.g. for accessibility reasons or to avoid blocking users because of repeated errors);
10. not transmitting passwords in clear text over a network to avoid being captured by a network “sniffer” program;
11. terminating 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 user endpoint devices;
12. restricting connection duration times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access.

Other information

Additional information on entity authentication assurance can be found is ISO/IEC 29115.

Organizations should consider authentication controls that are relevant to the type and sensitivity of the data and network that’s being accessed, including:

• Multi-factor authentication (MFA)
• Digital certificates
• Smart access controls (smart cards)
• Biometric logins
• Secure tokens

To prevent and/or minimize the risk of unauthorized access to its protected systems, the organization should

1. Restrict the display of information until after a successful authentication attempt.
2. Display a warning pre-logon which clearly states that information should only be accessed by authorised users.
3. Minimise the assistance it provides to unauthenticated users who are attempting to access the system e.g. organisations should not divulge which specific part of a login attempt is incorrect, such as a biometric aspect of an MFA login, and instead simply state that the login attempt has failed.
4. Validate the login attempt only when all required information has been provided to the login service, to maintain security.
5. Implement industry-standard security measures that protect against blanket access and/or brute force attacks on login portals. These measures can include:
   • CAPTCHA controls
   • Enforcing a password reset after a set amount of failed login attempts
   • Preventing further login attempts following a predefined number of failed attempts
6. Recording all failed login attempts for auditing and security purposes, including their use in criminal and/or regulatory proceedings.
7. Initiating a security incident whenever a major login discrepancy is detected, such as a perceived intrusion. In these cases, all relevant internal personnel should be notified, particularly those with systems administrator access or any ability to combat malicious login attempts.
8. Upon validating a login, relay certain pieces of information to a separate data source that list:
   • The date and time of the previous successful logon
   • A list of all login attempts since the last validated logon
9. Display passwords as asterisk’s (or similarly abstract symbols), where there is no pressing need not to do so (e.g. user accessibility).
10. Strictly prohibit the sharing of or display of passwords as clear, legible text.
11. Maintain a policy of terminating dormant login sessions after a specific period of time. This is particularly relevant for sessions that are active in high risk locations (remote working environments) or on user-supplied assets such as personal laptops or mobile phones.
12. Limiting the amount of time that an authenticated session can remain open – even when active – relative to the information that’s being accessed (i.e. business critical information or financially sensitive applications).

To control privileged access to systems and applications, the organization must implement of secure authentication technologies and procedures. To log-on to systems and applications, users must access privileged credentials. Organizations can configure the log-on to display a general notice warning that access to the system or application is limited to authorized users. The log-on process can also display information upon completion of a successful log-on, such as number of previous failed log-on attempts since the last successful login. Organizations can protect against brute-force log-on attacks by limiting repeated access attempts. Users who fail authentication to the vault should be locked out until enabled by an administrator, preventing access to privileged credentials. Re authentication for users or applications can be required based on inactivity or time-limits. Privileged session connection times can be restricted to certain times of day and sessions can be disconnected when a threshold (i.e. 15 minutes) is reached.
Application access can also be protected against (for example) brute-force log-on attacks. To perform designated tasks like processing information in a database, applications must be granted use of privileged accounts. Credentials are typically hard-coded and in clear text within applications, making them susceptible to brute-force attacks. For example, to access a database, an application must first have authorized access to the privileged credential in the vault. To gain access to the credential, an application is authenticated using advanced authentication methods, based not only on ID and password but also on specific application characteristics including the server it resides on, the operating system it uses, and a crypto “fingerprint.” Organizations can ensure only authorized applications with the appropriate ID and characteristics can access the database. The system can record and monitor all access attempts to privileged credentials. All valid and invalid access attempts by privileged credentials can also be logged, such as an application attempting to connect to a database. For raising security events such as a potential attack on log-on controls, it can integrates with Security Information and Event Management and event log systems.

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.

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 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 organizations require all members of their communities to have their own unique usernames and password to access certain IT resources. In addition, organizations authenticate these individuals before allowing them to connect to the network or the 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 requester 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 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 systems 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 organization’s 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 the Organization’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-organizational collaboration
  • Operational efficiencies and cost control
• Examples:
  • The organization wants to offer services to their constituents but doesn’t want to host them.
  • The 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”.
  • The 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

The 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 it just 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 sizes is a challenge.
  • Many times, it is the smaller organizations that can benefit the 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 a 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 organizational web services?
• How to reduce the number of credentials

An Alternative Solution:

• Focus on four activities:
  • Develop an organizational Identity Management System
  • Create a standard set of attributes for each person.
  • Use a federation to enable external access
  • Require organizational 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 organizational 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 Organizational Network

To enable remote access to organizational information resources, organizations 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 tunneling.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.