Use It or Lose It

by Deborah Volk on May 17th, 2009

This blog post is a continuation of Waiting at a Station where I talked about attestation and possible strategies of reducing its scope. The strategy I am proposing is to segment user accounts into active and dormant where the definition of dormant is set by audit guidelines or IT policy; dormant accounts can then be excluded from attestation. At its simplest (and for the sake of this example), we can define dormant as any account that has not been used since the last attestation. If we assume that attestation is done once a quarter, our definition becomes "any account that has not been used since the beginning of this quarter".

Making this definition become an actionable rule, we have to boil it down to data elements that we can interrogate. Really, we just need a single element - time of user's last login ("has not been used"). Once we have that, we're done with our rule and our segment. How can we implement this segmentation strategy? Let's examine several organizations with an existing attestation process but with different levels of maturity in their access management solution.
Orgs with no access management solution. Each application has its own authentication and authorization schemes, identity-related information is stored in application's own repository. (Marketers like to call this an identity silo). Applications have point-to-point integrations for exchange of data, e.g. if SAP needs to know about the employee's birth date, it asks PeopleSoft. Even though there's no identity and access management per se, attestation process does exist and our mythical El Caro Corp has been doing it every quarter for a number of years. It went from being completely paper-based to Excel to (drumroll, please) Sharepoint.

In this scenario, we have to retrieve the time of user's last login from the application. Each application will have an interface for extacting data and (potentially) its own unique way of representing the timestamp. Some apps might be relatively young and restless (breathless?), allowing you to query the data via SQL, while other apps might be ancient, requiring a COBOL program/call (Y2K anybody?).

It is certainly possible to catalogue all apps, their interfaces and data representations and write a Giant Perl Script That Reads Like a Thomas Pynchon Novel (sorry, Thomas). It would work and the suicide rate of developers having to maintain The Script may be low but it won't be zero. (I do occasionally wonder about Pynchon's editor...how does he/she do it?!). In the land of Perl scripts, the rule of thumb is "someone already wrote it" (and it's probably a one-liner).

If you're not afraid of scripting, there's a slightly better solution available - log extraction, sometimes billed as log analysis or monitoring or all of the above. The premise here being that many access front-ends such as web servers or secure proxies or network gateways or CFOs close to end of the quarter will log events to a text file in a semi-structured fashion. That's how log extraction got its started but that was a long time ago. Modern log analysis/extraction products such as Splunk do a lot more than read and parse text files, they've evolved to cover just about any interface and data format. These tools typically allow for quick customization by writing a script-like plugin (sometimes as little as a regular expression) so you can handle your app without reinventing the wheel from scratch (or semi-scratch for CPAN-savvy) in Perl. Log extraction and analysis is a capability found in many classes of security products; Security Incident and Event Management (SIEM) products can also do this. One popular Open Source SIEM product is OSSIM, for example.

In the somewhat-perfect-but-not-too-perfect world where all apps of interest to us (and there are very few, we're still attestation- and regulation-bound) have a database or directory as their repository of runtime metadata such as user sessions, we can use a data virtualization solution such as Oracle Virtual Directory to present a uniform interface with the desired data element(s). This way we don't have to bother with hacking through a jungle of different schemas to get the timestamp of user's last login, we have it neatly packaged and folded in one drawer.

Last but not least, I would be remiss not to mention the ultimate solution to all problems - reconciliation of access metadata via an identity administration tool such as Oracle Identity Manager (OIM). While more labor-intensive than writing a regular expression in Perl, the architectural rationale for this option is very strong IF we're managing our attestation process in OIM. If so, we could send last logged in timestamp right into process forms for SOX-in-scope resources defined for our users and have the attestation logic in OIM skip users that qualify for our dormant segment.

All of these options - scripting, log extraction/analysis, data virtualization - assume that application is keeping track of sessions. Some apps don't bother with recording the time of last login, an unfortunate and not altogether infrequent occurrence.
Orgs with Web Access Management (WAM) solution. All major WAM (read: web SSO) products have a capability for auditing user access. For example, Oracle Access Manager has a notion of an audit policy that allows the administrator to define what events are of interest (for audit), what information gets logged for each event and what application is the event coming from. There's only one problem with using a WAM solution for audits: it only deals with web apps. Sure, WAM tools come with all kinds of interfaces and in the olden days I've even seen enterprising WAM implementations where the app developers created an HTTP interface to a non-web app for the sole purpose of kinda-sorta including it in the web SSO scheme but let's be honest, WAM is all about the W.
Orgs with Enterprise Single Sign-On (ESSO) solution. I am tempted to use the term Enterprise Access Management (EAM) but we'll go with a more established ESSO. The advantage of deploying an ESSO rather than a WAM solution is that ESSO can manage all classes of apps, not just web apps. It can handle standalone (client-server, desktop) apps, web apps, green screens on a mainframe and so on. Wanna know who was editing your accounting records by opening a QuickBooks file at 2am on Sunday night? An ESSO product such as v-GO Single Sign-On from our partner Passlogix can audit that login for you even though there's no native auditing capability in low-end QuickBooks editions (but there's a password screen). Certainly deploying ESSO for a sole purpose of access audit may be overkill but combined with other drivers, closing the audit gap strengthens your business case.


Posted in Oracle Identity Manager, Access Management, Identity Management, Oracle Virtual Directory, Oracle Access Manager, Passlogix v-GO, Enterprise Single Sign-On    Tagged with no tags


0 Comments


Leave a Comment
Search

Subscribe

follow on

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)