The possibility of a breach of customer data residing on public cloud repositories is multifaceted, as it introduces more vulnerabilities with the exploitation of high-privilege identities.
One example is the Capital One breach, where an S3 bucket on Amazon was compromised.
This scenario creates a complex environment where:
- Work is viewed as a place, not an activity.
- The infrastructure cannot be scaled to meet the demands of modern architecture.
- Identities are not centrally managed.
- There are siloed and disparate data stores, security implementations and point-in-time-based fixes, resulting in a duct tape solution architecture.
This ever-increasing attack surface raises many questions for the people responsible for implementing zero trust, such as:
Companies can make better access decisions by providing approvers with business context, peer group analysis and risk-based recommendations.
- How do we identify risk, suspicious activity and so-called indicators of compromise?
- Having identified a risk level, how do we respond? Do we allow, block or trigger a step-up authentication process; eg, a one-time-PIN) sent to a cellphone for multi-factor authentication?
- How do we gain visibility into who or what has elevated privilege and how do we enforce least privilege?
- How do we balance security versus a productive experience so we can retain customers?
- How do we enable productivity with single sign-on so that users do not have to remember multiple usernames and passwords?
- How do we enforce continuous identity verification in a way that maintains operational efficiencies?
- How do we gain visibility into roles and access rights and present this information in a simple way that allows business owners to make informed decisions when certifying user access?
- How do we automate the governance process so that preparing for a compliance audit doesn't take weeks or months?
- How do we notify business owners of unauthorised access to applications or sensitive files and respond with an on-the-spot micro certification if necessary?
- How do we identify access creep?
- How do we automate the provisioning and lifecycle of identities so that it doesn't take days or weeks to onboard or off-board an employee?
- Finally, with complex active directory environments, managing potentially hundreds of thousands of users and computers, how do we make administrative changes in a reliable, audited, secure and monitored way?
IGA enters the picture
How do you respond to these immensely pertinent questions? The answer is by implementing an identity governance and administration (IGA) programme that will provide policy automation: automating the provisioning of users' rights to access applications and data.
For example, without an IGA programme in place, every new employee must be registered on many siloed applications (such as Workday, SalesForce, Mainframe, SAP and more) and systems.
Onboarding − and subsequent access to applications and data − can take days, even weeks. IGA manages not only user provisioning, but the complete identity lifecycle of any user, including surname changes, location changes, etc, and the offboarding of users, ensuring they cannot access systems after leaving organisations.
Companies need to achieve automation of the access review process. Auditors want to know if business owners have visibility into and can certify an employee's access rights.
IGA enforces and monitors the appropriate level of access for an identity, ensuring there are no compliance violations, and no roles that have unusual, elevated levels of access and it accelerates the certification process from weeks/months to days. The latter is a compelling proposition for any business owner.
How do you control visibility (and remediation) of governance violations? For example, can someone in accounts receivable also authorise payments?
If yes, this is a possible fraud risk. Taking this line of thought further, investigate if any users − whether permanent staff or contractors − were granted access to sensitive financial data within the last six months, and still require that access.
An example would be someone from finance changing careers and moving to marketing, but still having access to payroll information. This is called access creep.
Companies can make better access decisions by providing approvers with business context, peer group analysis and risk-based recommendations. Adaptive certification must be implemented. This is achieved by engaging business owners in periodic and event-driven access reviews to identify entitlement risks, take corrective action and prove compliance.
Continuous compliance is another matter. But again, an IGA programme will successfully enable the organisation to detect changes as they happen in connected systems, provide event-triggered remediation, identify high-risk changes in the environment and facilitate immediate response.
IGA also facilitates peer group analysis and risk scoring to identify, assess and remediate access risk, as well as insights into governance metrics and trends.
Finally, risk- and forensic-based analytics: visualising current and historical access rights and events are all covered by IGA. The foregoing illustrates just some of the key benefits of an IGA programme implementation.
Share