Identity and Access Management Security

Activity 8.1 Federated Security Scenario

In this exercise I will examine two federated identity scenarios. For each I will research the technology used and brainstorm any security issues related with the implementation.

Part 1: Google OAuth integeration

Summary:

A company has implemented an OAuth integration with Google using their own internally developed code. The integration will be implmented on their server via HTTP.

Security Issues:

This implementation faces numerous security issues.

Using HTTP makes the system vulnerable to traffic capture. HTTPS should be used in place.
The latest version, OAuth 2.0 should be used when possible
Potential for AS Mix-up Attack if multiple authorization servers are used
Staff may be vulnerable to phishing email attacks as per 2017 OAuth-based phishing attack
Instead of internally developed code, the organization should utilize the provided OAuth libraries
MFA and strong passwords need to be enforced on internal Google Accounts
Storage of user secrets needs to be secure, i.e. segmented network, encryption at rest/in transit.

Part 2: High security federation incident response

Summary:

A company is considering using Facebook Login to allow users to login to their customer support site. As a benefit the company will no longer be responsible for handling identity management in their application. Login with Facebook

Reccomendations:

Below are recommendations for the implementation team:

Verify Graph API Calls as per Facebook recommendations .
Utilize the Facebook provided SDK. Do not create your own library.
Consider implementing Google OAuth or additional providers for redundancy.
Use HTTPS.
Check implementation against Facebook’s checklist
Do not implement tracking scripts which pull info from Facebook’s login API.

Incident Response Plan:

Here are some points which would need to be included in an incident response plan if using Facebook login:

Create a process if the identity provider (Facebook) is compromised.
Anticipate small-lever incidents, i.e. if the identity provider is offline or a small portion of accounts are compromised.
A procedure on how to handle bots, fake or compromised accounts which may be logging in to the app via Facebook Login.

Part 3: Analyze your responses

In regards to Google OAuth, my reccommendations can be checked against the OWASP Cheat Sheet

OWASP’s main reccomendations are:

Use OAuth 1.0a or OAuth 2.0 since the first version (OAuth1.0) has been found to be vulnerable to session fixation.
OAuth 2.0 uses HTTPS and should be used over OAuth 1.0a
Audit the OAuth 2.0 code; developer mistakes can cause serious vulnerabilities.
OAuth should be used for authorization - not authentication

As for the second activity, information for developing a federation incident response can be located at: Federated SecurityIncident Response Policy

The btaa provides an example response to a security incident where Federated Identity is involved. The main point of difference being “instead of interacting directly with the user…interacts with the user’s home institution (the IdP), who take the lead with user interactions and forensic investigation.” Once the compromise of a user’s account is discovered, the Federated Identity Provider will be informed of the compromised credentials and provided with the evidence. The provider will then need to reset the user’s account and restore their credentials. Finally, the provider will inform the organization of the successful reset. Information discovered during the investigation of the account compromise should be shared between both parties. For example, if the compromise is determined to originate from a specific netblock of IP addresses, the organization may be able to block these addresses.

Sources:

Activity 8.2: On-site Identity Issues Scenario

In this exercise I will examine two local identity scenarios. As per the last exercise, for each I will research the technology and highlight any security issues related with the implementation.

Part 1: Emergency privelege escalation

Summary:

A companies’ administrative accounts are created and managed via a central IDAM solution. This solution, along with the company’s central AAA servers are hosted in redundant data centres. Site-to-site VPNs then connect these servers to multiple locations around the country. A recent internet connectivity outage resulted in engineers being unable to access privileged accounts. They require a solution in order to allow for emergency, on-demand privileged local access during an outage when central AAA servers are unavailable. The solution should be secure and flexible enough to enable authentication for network devices, servers and workstations.

Solution:

I propose utilizing a local, read-only domain controller RODC at local sites. According to Microsoft, RODCs allow users to logon and complete tasks “even when there is no network connectivity to hub sites.” The RODCs at the branch sites would replicate directory information from the central hub Domain controllers. As the RODCs are read-only they would allow greater security, preventing an attacker from writing to the domain controller should they compromise a local site. Network connections between the RODC and the central Domain controllers would be tunnelled through the existing site-to-site VPNs. In the event of an outage, AAA services would automatically fail over to the RODC and failback once service is restored.

Sample Architecture Diagram:

Part 2: Managing privelege creep

Summary:

A recent audit revealed many long-term employees possessed broader rights to files and folders needed to accomplish their jobs. Some employees could even access sensitive data. How can you handle the current issue of privilege creep and ensure it does not happen in the future? The solution cannot disrupt company operations.

Solution:

From a procedural perspective there are several policies which can prevent privilege creep. These include enforcing the principle of least privilege, conducting regular access audits, reviewing the access granting process and reducing the number of departments which can manage user privileges. In this situation, user rights not relevant to an individual’s job role need to be removed. Removing access rights to sensitive and confidential data should be prioritized. The next step would be to revert user permissions to their default settings. To avoid causing any widespread disruptions, this process will be performed in stages or in small groups. In the event of any issues, permissions could easily be restored. The last stage would involve taking a baseline measurement of user rights. This baseline could then be fed into an automation workflow. The workflow could generate a report comparing user permissions to the baseline to measure privilege creep. During regularly scheduled audits, the governance team could review these reports and determine which user permissions drifted too far from the baseline.

Glossary

A glossary of all the terms, acronyms and slang I run across for this chapter.

Directory	Centralized repository of names, address, title, email, contact info, principal name, etc for auth purposes.
Privilege Management	Ongoing management of user rights to perform actions or gain access to systems
IAM systems	Identity and access management systems allow for central management of user info
Directory Services	AD, LDAP, provide info about systems, users and other info.
TACAS+	Uses TCP to provide AAA services for network devices; suffers from several security flaws and should only be used on isolated networks
RADIUS	Can operate via TCP or UDP, provides AAA for network devices, wireless and other services.
Kerberos	AAA service designed to operate on untrusted networks, separates untrusted networks into realms, key distribution centers and groups of principals
OpenID	Open source standard for decentralized identity, i.e. users create a Gmail account and use that identity to authenticate to other services
Oath	Open authorization standard; Uses tokens; Allows users to share elements of their identity or account info while authenticating via the original identity provider
OpenID Connect	Authentication layer built using the Oath protocol, often paired with Oauth and allows authorization server to issue an ID token
Facebook Connect	Facebook based authentication protocol
RBAC	Role Based Access Control - Roles with permissions are assigned to users, groups, systems, etc.
ABAC	Attribute Based Access Control - Provides users rights based on policies which are collections of attributes, i.e. job title, responsibilities, position, location, etc.
MAC	Mandatory Access Control - Rigid; Relies on the OS to control what access and rights a user has; Implemented by a system admin.
Rule Based AC	Rule Based Access Control - Access based on a set of rules or ACLs set by an admin
DAC	Discretionary Access Control - Delegates control of resource privileges to admins or owners of protected resources
Personnel Security	Includes training and awareness - faces threats such as phishing, insider attacks and social engineering
Server Exploits	Target the systems which run identity services
KDC	Key Distribution Centre, centralized key store in Kerberos, hotspot for attackers
Common Kerberos Attacks	KDC attacks, Admin Account Compromise, Kerberos Ticket Reuse, TGT Ticket Granting Server attacks
Common Radius Attacks	Session replay of server responses, Targeting of the RADIUS shared secret, DoS attacks to prevent authentication, Brute-force attack against credentials
Common AD Attacks	Deploying credential capturing malware, credential theft via phishing, privilege escalation attacks, service account compromise, excessive domain admin rights, Group policy attacks
Account Lifecycle	Create an account, Set account permissions, Maintain Account, Disable Account, Retire and delete account
Privilege Creep	Steady accrual of privileges and rights over time
Common Identity and Authorization Exploits	Impersonation, MitM, Session Hijacking, Privilege Escalation, Rootkits
Session Hijacking	Focuses on taking over already existing sessions by acquiring the session key or cookies used by a remote server
Identity Defence in Depth	Create only valid accounts - Consistent provisioning of accounts - Track accounts to avoid privilege creep - Ensure complete account termination
Privileged User Management	The management of administrative and other super user rights, additional monitoring and logging
MFA Factors	Knowledge, possession, biometric, location
Context-based authentication	System which allows authentication decisions to be made based on info about the user, i.e. user group membership, ip address, time of day, location, frequency of access, device-based info, etc.
IDAAS	Identity As A Service - Cloud based services which provide directory services, identity life cycle management, sso, privileged account mgmt., reporting, auditing and other mgmt capabilities
Federation	The process of connecting an identity and its related attributes between multiple identity management systems
IDP	Identity Provider - In a federation must provide identities and release info about the identity
RP	Relying Party - In a federation must provide services to members of the federation
Consumer	User of federated services - may be asked to make decisions about attribute release and provide validation info about identity claims to the IDP
Federated Identity Technologies	SAML, OpenID, OAuth2, ADFS
SAML	Security Assertion Mark-up Language - Used to send authentication and authorization info between identity and service providers in enterprise, Linux-centric environments
ADFS	Active Directory Federation Services - Used to send authentication and authorization info between identity and service providers in enterprise, windows-centric environments