Privileged Access Management (P.A.M) has gained quite a lot of traction. A cliché indeed, but nonetheless true. Unsupervised accounts, unnecessarily elevated rights, subpar SAML implementation, and the lack of powerful access (and authentication) policies are what inspired a whole new chapter in the book of cybersecurity. PAM is founded on a very simple principle: no one’s to be trusted and everyone’s a suspect.
Simple, indeed, but the statement above is more akin to paranoia than to a living- and thriving – corporate environment. In an article I wrote a while back, I’ve talked about the fundamentals of identity and access governance.
Role assignation is, if you will, the powerhouse of PAM – accounting should only have access to financial documents, marketing should only access relevant materials, without the possibility of peeking at, for instance, finance-related documents and so on.
Furthermore, in stepping up to the plate, PAM has become just as vital as patching, DNS traffic filtering, antivirus, and antimalware tools.
Privileged Access Management is the first step in the right direction, but it’s lacking something; some sort of padding. Since the subject of PAM security has yet to be broached, today’s article is dedicated to what you can do (or can be done) to reinforce your identity and access governance policies.
Putting the “S” in Privileged Access Management
So, is it SPAM, PAMS, or S-PAM? Can’t say which one sounds better and wrapping our heads around this would be beside the point. In a broader context, PAM Security refers to a set of policies, rules, permissions, and the scripting framework required to create a sustainable role-based (not play!) ecosystem.
Where do we begin? What’s the best way to talk the talk about PAM Security? Well, to shape what will very well be then next big paradigm leap in identity and access management, we need to have a little chat about a quaint little thing called SAML.
For those of you who have yet to rub elbows with markup languages, SAML, which is short for Security Assertion Markup Language, is an open standard used for mediating the information exchange (authorization & authentication) between various parties.
Now, if the suffix (ML) sounds familiar, then you’re right – SAML is based on the Extensible Markup Language. One of the fundamental differences between SAML and XML is that the first is used for security assertations, while the latter is mostly used for encoding documents.
SAML provides the security padding PAM (desperately) needs. Remember when we said that role assignation is the powerhouse of IAM? Even SAML has a penchant for thespianism. So, what are the roles in SAML?
Tinseltown SAML
The SAML vernacular defines three roles:
1) Principal (not the headmaster though).
2) idP (Identity Provider).
3) SP (Service Provider).
So, how does it work? The principal, which, in most cases, is considered the human user (although not mandatory), requests a service from the SP (Service Provider). To ascertain if the principal is really, well, the principal and not someone (or something) else, the SP queries one or more identity providers (idP) to make a security assertion – requesting authentication details.
Now, based on the security assertion received from the idP, the SP makes an access control decision – determines if the service requested by the principal should be provided or not.
For validation purposes, the idP can (and will) request some additional information from the principal, aka the solicitor, that so feverishly seeks the service from the SP. The entire P – idP-SP cycle is summed up in the diagram below.
Image courtesy of JBoss
This depiction of the P – idP-SP cycle is not exhaustive. Many things make this system tick, but there’s no point in going further. The only thing you should know is that a single idP can make security assertions for many SPs. More than that, a single SP can query as many idPs to make the right access control decision.
I seemed to have mentioned that idPs make their security assertions based on credentials such as username-password pairs. In practice, these identity providers can take advantage of all authentication forms, including MFA, to make the best decision. Directory Services (e.g. LDAP, AD, or RADIUS) can also be employed in the authentication process.
All these things sound amazing, but how do they fit into place? And, more importantly, what do they have to do with PAM security?
SAML in motion. TLS, XML Signature, and XML Encryption
One thing to consider before I add more beef to this article – SAML plays an important role in SSO (Single Sign-On) authentication schemes, but it’s not limited to them. That’s where SAML profiling comes into play.
In a nutshell, SAML profiles are very much like brain scans. Whereas the latter shows how the various brain parts operate, SAML profiles showcase how all the bindings, protocols, and assertions work together within a case. Depending on the nature of the user case, there are various profiles
- SSO Profiles (e.g. Web Browser SSO Profile, Enhanced Client or Proxy Profile, Identity Provider Discovery Profile, Single Logout Profile, Name Identifier Management Profile).
- Artifact Resolution Profile.
- Assertion Query Profile.
- Name Identifier Mapping Profile.
- Security Assertion Markup Language Attribute Profiles.
Back to SAML – let’s see what happens during such an exchange.
SAML in Web Browser SSO
In this case, the service is requested from an SP by a human user through a user agent. The UA is a web browser.
Step 1. Resource querying at the Service Provider.
Usually done via HTTP. The query looks like this:
https://sp.noname.com/resource
Note: If the same principal made the same query to the service provider, the process will be approved without going through the usual…formalities.
Step 2. The service provider redirects the request to Identity Provider’s SSO Service.
SP sees the principal’s service request and redirects it to the preferred idP for a security assertion. The secondary query looks like this:
https://idp.noname.org/SAML2/SSO/Redirect?Request=request
Note: the web browser will usually request the SSO service by URL parametrization using a GET type request.
Step 3. XHTML response from idP’s SSO service.
The SSO service attached to the idP will validate the request and send the response in an XHTML form. This form will look something like this:
Step 4. The user-agent requests the result of the assertion consumer service at the Service Provider.
The principal’s user-agent (i.e. web browser) will request the result of the assertion consumer service at the SP using a POST-type request.
Note: The Assertion Consumer Service or ACS denotes a location hosted at the SP that accepts SAML artifacts (
Step 5. Target resource redirect.
After the assertion consumer service evaluates the results, it will ‘inform’ the SP that a security context can be safely created. Subsequently, the SP will redirect the principal’s user agent to the resource requested in the first place.
Step 6. User Agent to SP (again).
The principal’s user agent will once again request the resource at the SP.
Step 7. SP fetches the resource of the user agent.
With the security context created, the SP can safely provide access to the requested resource.
Here’s an example of a SAML, idP to SP (encrypted) response.
Security mechanisms in SAML
SAML utilizes two types of security countermeasures: transportation-level (usually TLS 1.0 or above) and message-level (XML Encryption and XML Signature). I’ve already covered the ins and outs of Transport-level Security in an article I wrote a while back. Let’s talk about XML Encryption and XML Signature.
1. XML Signature
Without getting into too many technical details, in the context of SAML, an XML Signature is a type of digital signature akin to PKCS#7 used to sign various XML documents.
A typical XML signature contains the following elements:
SignedInfo– information about signed data and the signature algorithms utilized.SignatureMethod&CanonicalizationMethod– anti-tampering elements.Transforms– describes the transformation applied to a resource before it is signed.DigestMethod– describes the used hashing algorithm before its application.DigestValue– result after the hash algorithm is applied. Encoded in Base64.Signature Value– the signature’s result. Also encoded in Base64.KeyInfo– signer can provide the recipient with the key attached to the signature.
For additional information on digital signatures, cryptographic algorithms used in XML digital signing, or deployment options, please refer to W3C’s paper on XML Signature Syntax and Processing Version 1.1.
2. XML Encryption
XML Encryption refers to how the contents of XML element are encryption. Both XML Signature and XML Encryption draw data from the SignedInfo element.
There’s not much to say about XML documents encryption algorithms – most take advantage of symmetric cryptography since they are less resource-consuming compared to the asymmetric approach. Although most use AES-128, other symmetric ciphers can be employed. It’s all up to the developer.
Actionable Identity and Access Governance Tips
Adding SAML padding increases your PAM security factor and that’s a fact. Still, this isn’t the kind of thing that can be deployed just like an application. It’s much more than that. Your entire Identity and Access Management infrastructure will have to be reevaluated to determine the best course of action. Have a nice (friendly) chat with your sysadmin and CTO to see how your PAM solution can be improved through SAML.
Naturally, with prevention being the best cure, up next, I will share with you some of my favorites IAM and PAM tips that are sure to improve your user access management game. Enjoy!
1. Requests for additional access.
Your sysadmin’s dashboard may become flooded with requests for additional access to various applications. For instance, a manager may need access to financial documents in order to determine who’s next in line for a raise.
Anywho, the takeaway here is that there’s no clear dividing line between roles. Keep that in mind the next time someone hits you with an access request. Don’t be so eager to hit that “deny” button.
2. Reporting proficiency.
All the answers to your PAM related questions are in those auto-generated reports. If you know how to read them right, you can quickly map out vulnerabilities. From your PAM solution’s dashboard, you can gather info status, account activity, account holder’s name & unique ID, job title, role attributions, identities, and much more. So, get comfortable with those reports because they can help you solve a lot of issues.
System admins waste 30% of their time manually managing user rights or installations.
Thor AdminPrivilege™
is the automatic Privileged Access Management (PAM) solution
which frees up huge chunks of sys-admin time.
- Automate the elevation of admin rights on request;
- Approve or reject escalations with one click;
- Provide a full audit trail into user behavior;
- Automatically de-escalate on infection;
3. Choose an all-inclusive PAM solution.
If you’re not sure about the next step, let me give you a little hint. The PAM solution you choose must maintain a balance between security and ease-of-access.
Heimdal™ Security’s Thor AdminPrivilege™ is your go-to solution for all your PAM and IAM needs. Role assignation is very flexible (i.e. the dashboard allows you to quickly define and commit modifications to your roles), easy to use, and can have powerful MDM capabilities. By design, Thor AdminPrivilege™ has SAML padding for extra security.
Besides, Heimdal™ Security’s solution is the only PAM solution on the market that automatically de-escalates rights on threat detection (i.e. when associated with Thor Vigilance). Other perks: auto-kill process on elevated session expiration, full audit trail, powerful reporting features, software, and hardware inventory, and much more.
Conclusion
PAM Security is poised to become the very next golden standard in identity access management. SAML padding is a good way to add more protection to your IAM infrastructure. What’s your take on PAM? Head to the comments section and let me know.
