Simplifying SaaS security


Breaking down Privileged Access Management (PAM) complexities for ISO 27001 compliance

Understanding Privileged Access Management (PAM) requirements

Once organizations embarking on a certification journey of either ISO 27001 or SOC 2 Type II have got past the early chaotic stages of asset identification, assigning roles and responsibilities and publishing policies, the focus shifts to uplifting controls.

One of the more complex controls for most organizations to implement is Privileged Access Management. This is defined in ISO 27001 Annex A 9.2.3 as “Management of privileged access rights: The allocation and use of privileged access rights should be restricted and controlled.” 

In a traditional IT model, privileged access was normally tightly controlled by a small internal IT team. When people needed access to systems or data, a formal support request was needed and privileged access was rarely given out to business users. In the modern SaaS-powered workplace, the traditional approach rarely applies as the business chooses, procures and operates the SaaS themselves. This doesn’t mean that the risk articulated in the standard doesn’t apply “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.”

ISO 27001 Annex A 9.2.3 implementation guidance

When delving deeper into the implementation guidance it is clear to see the controls apply to SaaS:

  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 IDs.

  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).

Most organizations attempting to implement these controls will start down the path of a discovery and clean up project that normally starts with a current state audit. This often leads the organization to find that multiple SaaS solutions introduce additional complexities into this activity:

  1. The highly privileged and privileged roles in each SaaS have different names and privileges, mapping these to organizational roles is difficult;

  2. Identifying the person or persons in each SaaS with rights to perform audits can be difficult when little is known of who / what business unit uses the SaaS;

  3. Accounts will often be active long after access is needed, e.g. staff will have left or changed roles and still have access;

  4. Multiple dashboards and views require knowledge to use, for example some SaaS require three different dashboards to be able to see all privileged access;

  5. That some SaaS will be using non-named accounts with no ability to trace the accountable owner.

Industry experience says this takes significant time

Detexian has spoken to multiple organizations who have completed this discovery activity ranging in size from 20 to more than 500 staff. In each case, the effort required to perform this activity was measured in days, sometimes weeks. One commented it took the entire six person team over two weeks to complete, this was before the clean up actions were undertaken which have been on-going for over a year. 

Once initial discovery and clean up is complete, the organization needs to undertake periodic reviews to attest compliance. Depending on your industry, policies and certification framework, this will be between every three months to annually. The periodic “audit of SaaS permissions becomes a time sink” which is why organizations look to reduce the effort of manual audits. 

How can Detexian help?

Detexian can reduce the effort of auditing SaaS privileged access by:

  • Discovery of all SaaS highly privileged and privileged users; 

  • Detection of both named and non-named accounts;

  • Identification of privileged users who no longer need access, e.g. left the organization or changed role;

  • Continuous monitoring and detection of new privileged users being created or changed.

Find out how you can detect SaaS privileged access in minutes and keep track of changes at all times. Inquire now for a free trial.

You got good security hygiene for core, centrally managed SaaS solutions. What about those not centrally managed and spread across different business teams?

Continue Reading

Secure what you can't see in the cloud
710 Collins Street
Melbourne VIC 3008
9848 Mercy Rd #2
San Diego 92129

Get the latest information about SaaS security misconfigurations

Copyright Detexian 2020 All Rights ReservedTerms & ConditionsPrivacy Policy