How to comply with ISO 27000 with WSO2 Identity Server

  • By Dinali Dabarera
  • 9 Mar, 2021

Multi-Factor Authentication of WSO2 Identity Server enables compliance with ISO 27000 - 9. Access control

Relying only on one authentication factor leaves your business solution with a single point of failure, in the sense that if the knowledge, device, or biometric pattern is compromised, anyone who has it can impersonate the user. This can lead to a significant data breach. By using two-factor authentication, you create an additional layer of protection against anyone seeking to obtain unauthorized access, because although one factor is compromised, the resource will be protected unless the second factor is exposed.

Security controls of ISO 27000

Rationale

9.1.1 Access Policy Control

9.4 System and application access control

9.4.1 Information access restrictions

9.4.2 Secure log-on procedures

● The need for two-factor authentication will vary with the business requirement. Based on the requirement for Role-Based Access Control, Attribute-Based Access Control can be achieved with WSO2 CIAM, Multi-Factor Authentication, and Adaptive Authentication.

● Adaptive Authentication will provide dynamic control over the authentication flow to provide more security in a user-friendly manner. 

● The solution’s Adaptive Authentication can connect with an Open Policy Agent (OPA) or Analytics Server and control access based on the decisions given.

Reference: https://is.docs.wso2.com/en/5.11.0/learn/multi-factor-authentication/#multi-factor-authentication-mfa

https://is.docs.wso2.com/en/5.11.0/learn/adaptive-authentication/

Identity Provisioning and Deprovisioning of WSO2 Identity Server enables compliance with ISO 27000 - 9. Access control

Users can be provisioned or registered to WSO2 Identity Server in three ways.

  • Users can self-register
  • The administrator can invite users to register
  • Users will be just-in time provisions to the system during federation

The provisioning and de-provisioning in the WSO2 Identity Server can be controlled by enforcing policies or changing permission levels that need to achieve each task.

To enforce policies during provisioning and deprovisioning in WSO2 Identity Server:

  • WSO2 Identity Server ships with an inbuilt XACML engine to enforce XACML policies to achieve Rule Based Access Control or Role-Based Access Control during provisioning/registration or de-provisioning
  • Provisioning patterns can be configured in WSO2 Identity Server to outbound provision users to third-party systems
  • WSO2 Identity Server ships with an in-built workflow engine to activate a workflow during provisioning and de-provisioning. This will control the provisioning and de-provisioning by an approval process (multi-step or uni-step approvals)

Security controls of ISO 27000

Rationale

9.2 Responsibilities for assets

9.2.1 User registration and de-registration

9.2.2 User access provisioning

● Controlling provisioning identities depends on the business requirement, and WSO2 Identity Server provides the capability to customize the existing features to achieve the requirement via extension points.

● Provisioning and de-provisioning of users, groups can be controlled through XACML policies and workflows

Reference: https://is.docs.wso2.com/en/latest/learn/identity-provisioning/

Password/Tokens/Secret Management of WSO2 Identity Server enables compliance with ISO 27000 - 9. Access control

 Password Management

There are several ways to change the password with the use of the WSO2 Identity Server

  • Reset password or forgot password
  • Reset password through challenge questions
  • Administrator forcefully resets user’s password in a critical situation
  • Periodically user has to reset the password and can not repeat the same password - Password policy authenticator

To secure user’s password:

To secure Identity Server passwords in files:

The plaintext passwords in configuration files can be encrypted using the secure vault implementation that is built into the WSO2 Identity Server. Outsiders will not be able to see the plaintext password. The keystore password and private key password of the product's primary keystore will serve as the root passwords for Secure Vault. This is because the keystore passwords are needed to initialize the values encrypted by the Secret Manager in the Secret Repository. Therefore, the Secret Callback handler is used to resolve these passwords.

Security controls of ISO 27000

Rationale

9.4.3 Password management system

● Passwords can be encrypted or Hashed with a Salt as per requirement

● Passwords can be changed regularly with complex policies

Best Practices:

Reference: https://is.docs.wso2.com/en/latest/setup/maintaining-logins-and-passwords/

Tokens and Secret Management

Best practices:

Key Management feature of WSO2 Identity Server enables compliance with ISO 27000 - 10.1 Cryptographic Control

Best Practices:

Two keystore can be maintained:

  • Internal keystore - used for encrypting/decrypting internal data. By default, the primary keystore is used as the internal keystore. The key rotation of the internal keystore can have a longer period compared to TLS key stores.
  • TLS Keystore - used for TLS communication. By default, the primary keystore is used as the TLS keystore. Key rotation of TLS key stores can be done frequently as these keys are exposed to outside more frequently.

Security controls of ISO 27000

Rationale

10.1 Cryptographic Controls

10.1.1 Policy on the user of Cryptographic controls

10.1.2 Key Management

● Tokens, secrets can be symmetrically encrypted(faster than Asymmetric encryption and industry-standard) with the internal keystore

● Two keystores of internal and TLS can be the user with different key rotations

Auditing and Logging capabilities of WSO2 Identity Server enabled compliance with ISO 27000 - 12.4 Logging and Monitoring

The Following logs can be monitored through WSO2 Identity Server:

  • Audit logs
  • Access Logs
  • DEBUG/WARN/ERROR Logs

WSO2 Identity Server supports logging capabilities for tracking down latencies due to database calls. See Working with Product Observability for instructions on how to configure and use this capability.

Events and logs can be published to any popular SIEM for further analysis e.g., SPLUNK integration

WSO2 Identity Server ships with an Analytics Server to view login and session analytics in a dashboard and a PDF can be downloaded (dashboard details).

Best Practices:

Security controls of ISO 27000

Rationale

12.4.1 Event logging

12.4.2 Protection of log information

12.4.3 Administrator and operator log

● The access logs of users, audit logs of all the operations, and debug logs will be recorded in separate files inside WSO2 Identity Server. These files can be hosted in a separate location for added security or analysis.

● This information can be published to any advanced SIEM for further analysis based on the business requirement

● WSO2 Identity Server analytics is available to view user login and session statistics.

Consent Management Feature of WSO2 Identity Server enables compliance with ISO 27000 - 18. Compliance with legal and contractual requirements

WSO2 Identity Server (WSO2 IS) is designed based on privacy best practices and is fully compliant with GDPR. GDPR compliance in your IAM and API security spaces can be completely fulfilled with WSO2 Identity Server.

Consent management refers to the practice of prompting, collecting, and managing user approval for collecting or sharing the user's personal information. "Consent" itself is granting permission or agreement for a specified action to take place. When creating, storing, or sharing user information WSO2 Identity Server will prompt for user consent. User consent can be managed by the user via a portal.

WSO2 Identity Server supports the following:

Privacy by design and privacy by default

● Consent identity management

● Consent life cycle management

● Consent receipt specification (draft)

● Right to be forgotten

● Exercising individual rights

Reference for more details: https://is.docs.wso2.com/en/latest/compliance/general-data-protection-regulation/

Admin portal support for organizations to define and manage consent, data processing purposes, and user attributes per consent. For more information, see Managing Consent Purposes.

Consent collection during single sign-on (SSO) before sharing the user attributes with external applications. For more information, see Consent Management with Single-Sign-On.

Support for the Kantara consent receipt specification. For more information, see the Kantara Consent Receipt Specification.

WSO2 Identity Server is also compliant with eIDAS and CCPA

Security controls of ISO 27000

Rationale

18.1.4 Privacy and protection of personally identifiable information

18.1.3 Protection of records

18.1.5 Regulation of cryptographic control

18.2.1 Compliance with security policies and standards

● WSO2 Identity Server get consent from the user to comply with EU GDPR

● Support Kantara consent receipt specification

● Sensitive user information can be encrypted. We can also encrypt all the user information via a custom userstore if needed by the business requirement.

● WSO2 Identity Server can be extensible to comply with any regulation based on a customer requirement.

Other Security Best Practices to follow when setting up a production deployment

About Author

  • Dinali Dabarera
  • Software Engineer
  • WSO2
Dinali is a Senior Solutions Engineer in the security team at WSO2. She holds a bachelors degree in Computer Engineering from University of Peradeniya, Sri Lanka.