Unblocking The Main Thread Solving ANRs and Frozen Frames
David doret (2019) SIGS IAM Conference: Revisiting IAM Foundations
1. Revisiting IAM
Foundations
Security Interest Group Switzerland (SIGS)
IAM Conference, Zürich, November 2019
David Doret
david.doret@me.com
https://ch.linkedin.com/in/daviddoret
https://twitter.com/daviddoret
4. IAM: A broad spectrum of opportunities to create value
Business Productivity & Agility
Information Security
Compliance & Auditability
Risk Optimization
On-boarding, ID beyond boundaries, Reorgs
Protection from identity and privilege abuse
SoD, 4 eyes checks, toxic rights, transparency
Fraud prevention and detection, legal risks
risk by Template
from the Noun
Project
start up by Alina
Oleynik from the
Noun Project
Audit by Arafat
Uddin from the
Noun Project
Security by Ben
Davis from the
Noun Project
6. SoD
“(…) the allocation of work so
that an employee cannot both
perpetrate and conceal errors
or fraud in the normal course
of performing their duties”
(Stone, 2009)
8. Control
Depth
Business App
Report
Middleware
OS
Hypervisor
Out-of-band
Database ETL
Web Server
PAM
Security ServicesInfra Services
Physical Security
SDLC
UEFI
But it is more rewarding
to embrace complexity
and adopt a risk-based approach
Queuing
Etc. Etc. Etc.
API
You may live a happy life
ticking boxes to scratch the surface
Report
AD LDAP Kerberos Radius
Federation Services
9. “Not all our challenges
are top-down.
There is a need for an
important bottom-up
view of security
requirements
engineering.”
Crook et al. (2002)
Top-Down
Bottom-Up
10. Permission Drift
“If deprovisioning does not occur, it
may not affect a user’s
productivity, but it results in the
user maintaining unnecessary or
inappropriate permissions. This
phenomenon is referred to as
permission drift and results in
‘overentitled’ users.”
Reference: Alan C. O’Connor and
Ross J. Loomis (2010)
11. Ignorance-by-Design
The Need-to-Know Meme
• Not a principle, sometimes a dogma
• An excellent tool for strictly limited use cases
• Burden of proof inversion
• Inhibits collaboration, innovation
• As a general rule, we want information to flow
• What risk?
• What opportunity cost?
12. Role Engineering
is the glue
between Users
and Resources
Reference: Alain Huet. (2015). Identity and Access Management - Data modeling.
RBAC – A quick reminder
13. What is a role?
It is not just a
group of users
and permissions
Primarily, it has
business meaning
(…) security requirements are mostly social
requirements rather than technical solutions (…) To
understand the problem of security engineering we
need to model and analyze organizational settings,
in terms of relationships between relevant actors,
including the system-to-be. Modeling only digital
protection mechanisms is not sufficient. Indeed,
several studies have revealed how security is often
compromised by exploiting weaknesses at the
interface between procedures and policies adopted
by an organization and the system that support
them (…)
(Massacci et al. 2007)
Role: a job or function “with some associated
semantics regarding the authority and
responsibility conferred on a member of the role.”
(Ravi Sandhu et al., 2000)
15. Role Engineering
“So role engineering is the application of engineering principals and techniques to create a set
of roles that implements a security policy and that is organized into a structure that reflects the
nature of the enterprise or organization. The role structure will be optimized for effectiveness
and efficiency using engineering principles and techniques.” (Coyne and Davis 2008)
16. Net Economic Benefit of RBAC
RBAC
Net Economic Benefit
Per Employee per Year
in 2018 (with inflation)
USD: 168.47
EUR: 147.71
CHF: 167.56
Reference: O’Connor and Loomis (2010)
17. The Key is the IAM Team and its Skillset
IAM requires highly specialized skills across multiple technical and
business disciplines
Aggressively develop the
hell out of your IAM staff!
team by Gwen Stacy, teach by Becris, win by Dev Patel from the Noun Project
18. Anti-bullshit
Indicators
• Network of peer IAM
professionals
• Objectives
• Standardize metrics
• Benchmarking data
• You are welcome to
participate, reach out to me!
19. IAM Scope Governance
• Unit: # of systems
• Forces you to define the IAM scope
• Do you manage 3rd parties?
• Do you manage external identities?
• Do you manage pre-prod environments?
• Do you manage technical systems?
• Provide assurance of scope coverage
in-scope
+ uncertain
+ out-of-scope
= total
#Systems
Time
in-scope uncertain out-of-scope
20. % RBAC Efficiency
• Underlying unit: # of entitlements
• Easy to collect and compute
• Unless you measure this indicator,
you have no clue wether RBAC
is implemented or not
• Required threshold to claim RBAC is
implemented: 80%
• Should reach a plateau
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
RBACEfficiency
Cost / Time / Effort
Law of diminishing returns
𝒂𝒄𝒄𝒆𝒔𝒔𝒊𝒏𝒉𝒆𝒓𝒊𝒕𝒆𝒅
𝒂𝒄𝒄𝒆𝒔𝒔 𝒕𝒐𝒕𝒂𝒍
100
inherited
total
100
21. % Auto-Reconciliation
• Underlying unit: # of systems
• Assumes you have an IAM platform
• Auto-rec frequency: daily
• Auto-rec scope: identities and entitlements
• Demonstrate your capacity to detect
unauthorized identities and entitlements
auto-reconciliated
in-scope
100
23. % MFA
• Underlying unit: # of systems
• You may start with a limited scope,
e.g. define what a sensitive system is
and impose MFA on sensitive systems
• Good indicator of the robustness of your
identity protection program
MFA
in-scope
100
24. % Revocation within SLA
• Underlying unit: # of revocation requests
• Assumes you have an IAM platform
• Forces you to define SLAs
(usually 2-3 profiles function of sensitivity)
• Help you zoom-in on failing provisioning
processes
100
σ 𝒕 𝒓𝒆𝒗𝒐𝒄𝒂𝒕𝒊𝒐𝒏<𝑺𝑳𝑨;𝟏;𝟎
𝒓𝒆𝒗𝒐𝒄𝒂𝒕𝒊𝒐𝒏𝒔
25. % Grant within SLA
• Underlying unit: # of grant requests
• Assumes you have an IAM platform
• Forces you to define SLAs
• Help you accelerate staff on-boarding
100
σ 𝒕 𝒈𝒓𝒂𝒏𝒕<𝑺𝑳𝑨;𝟏;𝟎
𝒈𝒓𝒂𝒏𝒕𝒔
26. % Bastion
• Underlying unit: # of systems
• Bastioned = technical and applicative
privileged accesses are intermediated
by a bastion, except break-the-glass
bastioned
in-scope
100
27. Bibliography
«If I have seen further
it is by standing on the
sholders of Giants.”
Isaac Newton, 1676
28. Bibliography (1/3)
• Anderson (1994) Liability and computer security: Nine principles
• ANSI. (2004). ANSI INCITS 359-2004: Role Based Access Control.
• Benantar (2006). Access control systems: security, identity management and trust models.
• Bertino and Takahashi (2011) Identity management: concepts, technologies, and systems.
• Barker, S. (2009). The next 700 access control models or a unifying meta-model
• Brink (2015) How Managing Privileged Access Reduces the Risk of a Data breach.
• Coyne, E.J. and Davis, J.M. (2008). Role engineering for enterprise security management.
• Coyne, E., Weil, T.R. (2013). ABAC and RBAC: Scalable, Flexible, and Auditable Access Management
• Crook et al. (2002) Security requirements engineering: when anti-requirements hit the fan.
• Donaldson et al. (2018) Enterprise Cybersecurity Study Guide.
• Elliott, A.A. and Knight, G.S. (2010). Role Explosion: Acknowledging the Problem. , p.7.
• Ernst & Young (2013) Key considerations for your internal audit plan - Enhancing the risk assessment and addressing emerging risks.
• Feltus, C., Petit, M. and Sloman, M. (2010). Enhancement of Business IT Alignment by Including Responsibility Components in RBAC.
29. Bibliography (2/3)
• Ferraiolo, D.F., Barkley, J.F. and Kuhn, D.R. (1999). A role-based access control model and reference implementation within a corporate intranet.
• Ferraiolo et al. (2007). Role-based access control. 2nd ed.
• Ferraiolo, D., Kuhn, R. and Sandhu, R. (2007). RBAC Standard Rationale: Comments on ‘A Critique of the ANSI Standard on Role-Based Access Control’.
• Gallaher et al. (2002). Planning Report 02-1: The Economic Impact of Role-Based Access Control
• Gartner (2005) Consider Identity and Access Management as a Process, Not a Technology.
• Gartner (2017) Best Practices for Privileged Access Management.
• Hall et al. (2005) Policies, Models, and Languages for Access Control
• Herda (1995). Non-repudiation: Constituting evidence and proof in digital cooperation.
• Giorgini, P. et al. (2006). Requirements engineering for trust management: model, methodology, and reasoning.
• Huet (2015). Identity and Access Management - Data modeling.
• Kobelsky, K. (2013). A Conceptual Model for Segregation of Duties: Integrating Theory and Practice for Manual and IT-based Processes. University of
Michigan - Dearborn.
• Kobelsky (2014) Enhancing IT Governance With a Simplified Approach to Segregation of Duties.
• Li, N., Bizri, Z. and Tripunitara, M.V. (2007) On Mutually-Exclusive Roles and Separation of Duty.
30. Bibliography (3/3)
• Massacci et al. (2007) Computer-aided Support for Secure Tropos.
• Moses, S., Rowe, D.C. and Cunha, S.A. (2015). Addressing the Inadequacies of Role Based Access Control (RBAC)
Models for Highly Privileged Administrators: Introducing the SNAP Principle for Mitigating Privileged Account Breaches.
• O’Connor and Loomis (2010). 2010 Economic Analysis of Role-Based Access Control - Final Report. NIST.
• Osborn, S., Sandhu, R. and Munawer, Q. (2000). Configuring role-based access control to enforce mandatory and
discretionary access control policies.
• Osmanoglu, T.E. (2013). Identity and access management: business performance through connected intelligence.
• Sandhu, R. et al. (1996). Role-Based Access Control Models.
• Sinclair and Smith (2008) Preventative Directions For Insider Threat Mitigation Via Access Control
• Singleton, T.W., Singleton, A.J., (2010) Fraud Management.
• Stone, N. (2009). Simplifying Segregation of Duties - A targeted approach not only saves money, but also allows
auditors to focus on more high-risk areas. The IIA - Internal Auditor.
• Wisegate (2012). Role Based Access Control: How-to Tips and Lessons Learned from IT Peers
• Zhang, D. et al. (2014). Efficient Graph Based Approach to Large Scale Role Engineering