Patterns and Antipatterns in Enterprise Security
2 likes1,473 views
The document discusses various patterns and antipatterns related to identity and access management in enterprise security, with a focus on practical solutions for common problems such as user integration, authentication, and security management. It outlines several strategies, including identity brokers, federated authentication, multi-factor authentication, and secure information exchange methods, detailing their benefits and limitations. Additionally, the document highlights the importance of effective governance and modular design in maintaining secure and scalable identity management systems.
![66
References
[1] https://msdn.microsoft.com/en-us/library/
[2] http://soapatterns.org/
[3] https://medium.facilelogin.com/thirty-solution-patterns-with-the-wso2-identity-server-
16f9fd0c0389#.1f3slrjnt
[4] http://wso2.com/library/blog-post/2014/10/blog-post-identity-anti-patterns-federation-silos-
and-spaghetti-identity/
[5] http://wso2.com/library/webinars/identity-server/
[6] M. Schumacher, E. Fernandez-Buglioni and D. Hybertson, Security Patterns: Integrating
Security and Systems Engineering. 2005.](https://image.slidesharecdn.com/enterprisesecuritypatternsanti-patterns-160601085750/85/Patterns-and-Antipatterns-in-Enterprise-Security-66-320.jpg)
Patterns and Antipatterns in Enterprise Security
- 1. Patterns and Antipatterns in Enterprise Security Johann Nallathamby Malithi Edirisinghe 1
- 2. For whom? ● Looking to learn about Identity and Access Management Patterns to solve real world business problems. ● Some experience with Identity and Access Management Technologies. E.g. Directories, SAML2, OAuth2 which are some of the most commonly used data standards / protocols for transporting Identity and Access Management data. ● Main focus is on Identity and Access Management Patterns. ○ NOT Network Security ○ NOT OS Security 2
- 3. 1. Identity Integration / Virtual Directory 3
- 4. Problem ● Users to the system can come from multiple sources ● A single user’s attributes can come from multiple sources ● User credentials and attributes can come from separate sources Solution ● Mount multiple user stores for user management and make the number and type of user stores transparent to the application ● Connect the credential stores and identity stores to the system and provide a unified view of the user's’ identity hiding away the complexity in aggregating those data 4
- 6. Problem Users will work with multiple applications in an enterprise. They will have to use specific credentials for each. ● Disjointed User Experience ● Complicated user and account management ● Security Threats Solution Delegate authentication to a trusted identity provider - Brokered Identity 6
- 7. Benefits ● Single Sign On ● Separate user authentication from application code ● Hides user credentials from applications ● Removes administrative overhead from applications ● Improves user experience Limitations ● Authentication can be a single point of failure. ● Introduce a single point where the security of the entire system can be breached 7
- 9. Problem Users will use applications across enterprise borders and cloud. Solution Multiple trust domains with multiple Identity Providers. Federated authentication based on the trust relationship 9
- 10. Benefits ● Single Sign On ● No need of managing accounts in the on premise userstore ● Reduce administration overhead Limitations Security of the system can be compromised if any of the Identity Provider that your Identity Provider trusts are breached. 10
- 11. 3.1. Identity Federation Variation -1 Inter-Domain Token Exchange 11
- 12. Problem A consumer who is living in a trust domain needs to interact with a service that is developed in a federated trust domain Solution Establish a trust relationship between the two Identity Providers residing in each trust domain. IdP-A IdP-B Consumer Service Trust Trust Trust Trust Domain A Trust Domain B 12
- 13. Benefits ● Flexible in maintaining trust domains ● Facilitates federated interactions between consumers and services across trust domains ● Same model can be extended to address more complex federation scenarios Limitations Introduces certain level of dependency between the consumer and the Identity Provider in the other trust domain 13
- 14. 3.2. Identity Federation Variation -2 Intra-Domain Token Exchange 14
- 15. Problem A consumer who is living in a trust domain needs to interact with a service that is developed in a federated trust domain, without any dependencies to entities in the other trust domain Solution Consumer presents the token to the service in the other trust domain. Service will validate the token with its Identity Provider. IdP-A IdP-B Consumer Service Trust Trust Trust Trust Domain A Trust Domain B 15
- 16. Benefits ● Removes dependencies between consumers and service in different trust domains ● Can handle different token claim representations Limitations ● Adds complexity to the mechanism used to model the trust relationship with the Identity Provider in the other trust domain ● Makes the services to accept messages that are not issued by the Identity Provider that they trusts 16
- 17. 3.3. Identity Federation Variation -3 Third Party Trust Establisher 17
- 18. Problem Creation of trust between Identity Providers can be complex. Ex: Cannot establish direct trust relationship as some identity information cannot be shared with partner company. Solution Establish the trust relationship with a third party Identity Provider, that act as a bridge between other Identity Providers IdP-A IdP-B Consumer Service Trust Trust Trust Trust Domain A Trust Domain BIdP-C Trust Trust 18
- 19. Benefits Isolates the complexities of the federated environment from different trust domains Limitations Introduces a new component that needs to maintained 19
- 21. Problem ● Increasing no of Service Providers and Identity Providers ● Each Service Provider has to trust Each Identity Provider Not scalable Hard to manage Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2. html Spaghetti 21
- 22. Solution One Identity Broker trusted by relying parties and federated parties acting as a hub 22
- 24. Problem ● Multiple Identity Federation Protocols SAML, OpenID Connect, WS-Federation etc. ● But federation systems relies on only one protocol Ex: Silo of SAML Federation Silo of OpenID Connect Federation Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2. html Federation Silos 24
- 25. Solution ● Bridge between protocols. SAML with OpenID Connect 25
- 26. Benefits ● Single Sign On across heterogeneous protocols ● Identity federation between Service Providers and Identity Providers with heterogeneous federation protocols ● Scalability Limitations ● Authentication can be a single point of failure. ● Introduce a single point where the security of the entire system can be breached 26
- 28. Problem Service Providers may not be able to understand claims or roles of the subject, in the format issued by Identity Providers and vise versa. Solution Convert incoming claims to the expected format Benefits ● Process claims in a single point reducing the complexity of enforcing brokered trust ● Can be used with legacy systems 28
- 30. Problem Digital identity fraud is still on the rise Needs “strong” user authentication Solution Use two or more authentication factors ● Something known to only the user (Knowledge based) password, shared secret, PIN ● Something held only by the user (Possession based) security token, smart card, mobile device ● Something inherent only to the user (Biometric) facial recognition, fingerprint, voice recognition 30
- 32. Problem Multiple domains essentially isolated due to lack of mutual inbound or outbound trust relationships. Service Providers opt for different login options Solution Multiple login options are presented to the user as per the Service Provider application. 32
- 34. Problem Needs “strong” user authentication, if and only if there is an actual risk. Solution Provide additional authentication steps, if and only if the risk profile (derived from a matrix of variables) is high. Enhance user experience 34
- 36. 36 MAC vs. DAC ● Mandatory Access Control (MAC) ○ Centralized security policy ○ Users do not have the ability to override the policy ● Discretionary Access Control (DAC) ○ Governs the ability of subjects to access objects ○ Allows users the ability to make policy decisions and/or assign security attributes. ○ The traditional Unix system of users, groups, and read-write- execute permissions is an example of DAC.
- 37. 37 Access Control Patterns ● Access Matrix / Access Control Table / Access Control List ● Role Based Access Control (RBAC) ● Group Based Access Control ● Claim Based Access Control ● Policy Based ● Hierarchical Authorization ○ Hierarchical Tenants ○ Hierarchical Groups/Roles ○ Hierarchical Resources ● Multilevel Access Control
- 41. 11. SSO with Delegated Access Control 41
- 42. Problem Consumers need to access back-end APIs on behalf of the logged in user. 42 Solution Should adhere to some access delegation protocol Ex: OAuth Exchange the authentication token to some access token SAML token, JSON Web Token (JWT)
- 43. 43
- 44. 44
- 46. 46
- 47. 47
- 48. 48
- 49. 49
- 50. 13. JIT Provisioning / Shadow Accounts 50
- 51. Requirements ● Transient Name IDs ● Persistent Name IDs ● Identity Protection ● Identity Mapping ● Identity Collision 51
- 53. 53 Problem Securing a n-tier application ● Securing only the top most layer ● Expansion in the number and kinds of users ● Heterogeneous devices ● Unlimited connections ● Who should be allowed to access the data? ● Cannot protect from an attack originating from the local area network within the company. ● Who has already accessed the data? Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-w html
- 54. 54 Solution 1 Impersonation and Delegation ● Delegation is the process of allowing another party to act on behalf of an identity. ● This process bestows upon a party the rights and privileges of another party to perform a set of tasks. ● Impersonation can be viewed as the most relaxed form of delegation, such that one identity is assigned the complete set of permissions of the impersonated identity.
- 55. 55 Solution 2 Trusted Subsystem ● Trusted subsystem model implies that application services are trusted to perform a specific set of application tasks. ● Frequently, downstream services need to make application authorization decisions. ● To do so, the service must know the identity of the end user. ● While the ability to flow the identity of the end user is an inherent property of the delegation model, it is not so for the trusted subsystem model and special efforts must be made to include this feature. Source : https://msdn.microsoft.com/en-us/library/aa905320. aspx#trstsubsysdes_topic6
- 56. 56 Solution 2 Contd. Trusted Subsystem ● Authenticate and verify the identity of the upstream or downstream service they are communicating with. ● Decide if the identified service is a trusted subsystem for a specific set of application functions, including propagating identity claims. ● Protect the integrity of the data being communicated between trusted subsystem and downstream services. Besides application data and application plumbing data, such as the identity claims of the original user, must also be protected so that no man-in-the-middle can modify the identity information that is in transit.
- 57. 57 Solution 2 Contd. Trusted Subsystem - Identity Flows ● Trusted subsystem generated identity tokens / Self-issued ○ When downstream services trust the trusted subsystem to assert the original caller's identity, without requiring additional evidence from other parties. ● Third party generated identity tokens / Self-contained ○ When the downstream services trust the trusted subsystem to assert claims regarding the original caller in conjunction with third party evidence that satisfies an additional set of security requirements. ● User self-signed tokens ○ When the trusted subsystem is authorized to perform a set of application functions and when there must be evidence from the original caller that the caller initiated the request. ● Identity/Credential Mapping ○ Special function of the trusted subsystem role, where the goal is to transform an identity to another related identity for the purpose of gaining access to downstream resources that only recognize the transformed identity.
- 59. 59
- 60. 60
- 61. 61 Audit Interceptor Requirement ● Log security incidents to trace system abuse: ○ Failed login attempts ○ Unauthorized access attempts to services Solution ● All messages flow through the a gateway of the system. ● Necessary auditing is done by the logging at the gateway.
- 62. 62 Data Origin Authentication Requirement ● Non-repudiation Solution ● Digital Signature Data Confidentiality Requirement Protect sensitive personal data during transmission from: ● Tampering ● unauthorized access Solution ● Digital Encryption
- 63. 63 Message Screening Requirement Mitigate damages to the system from messages with malicious content ● SQL injection ● X-Doc attacks Solution ● XML Schema validation. ● Regular expression validation to avoid SQL injections contained in strings. ● An application of Perimeter Security
- 64. 64 Replay Mitigation/DoS Safety Requirement Prevent denial of service attacks caused by replaying valid messages. Solution ● Apply throttling rules at the entry point. ● Validate message freshness by WS-Security mechanisms (Timestamp/Nonce). ● An application of Perimeter Security.
- 65. 65 Exception Shielding Requirement Avoid exposing sensitive data through exceptions. ● Legacy application code might throw exceptions containing sensitive information. ● Need to filter those exceptions when system is exposed to external parties. Solution ● Sanitize unsafe exception data by replacing it with non-harmful exception message and give the right level of detail to the user.
- 66. 66 References [1] https://msdn.microsoft.com/en-us/library/ [2] http://soapatterns.org/ [3] https://medium.facilelogin.com/thirty-solution-patterns-with-the-wso2-identity-server- 16f9fd0c0389#.1f3slrjnt [4] http://wso2.com/library/blog-post/2014/10/blog-post-identity-anti-patterns-federation-silos- and-spaghetti-identity/ [5] http://wso2.com/library/webinars/identity-server/ [6] M. Schumacher, E. Fernandez-Buglioni and D. Hybertson, Security Patterns: Integrating Security and Systems Engineering. 2005.
- 67. 67 Q & A