Archive for the ‘Access Management’ Category

First look onto EmpowerID

August 13, 2015 Leave a comment

I’ve had the chance to get a demo on one of the .Net-based IAM tools earlier this week. I had the pleasure to get some insight on the EmpowerID product platform. As i do come from a legacy-Voelcker background, being shifted through the aquisition through Quest Software in 2010 and joining my current (vendor neutral – although we do have unique competencies for a couple of IDM / IAM / IAG tools) employer, i’m still working mainly with what is now Dell One Identity Manager, which completely based on the Microsoft .Net stack, as the EmpowerID suite is. There are a couple of things in common: both tools come with their very own database based meta-directory (EmpowerID support Microsoft SQL Server, Dell supports Microsoft SQL Server as well as an Oracle Database Server), both tools use the IIS server for their web applications, both tools do ship with a graphical workflow designer, both tools ship with a bundle of native connectors but are able to be extended using their API capabilities to program custom connectors against their extensible meta-directory. There are a couple of mor things in common betwenn D1IM and the EmpowerID suite, but there are also a whole bunch of differences between the two solutions approaching the same problem. The main issue at least for the european market for the EmpowerID suite is the missing SAP connector to provision into the SAP security stack. They do have a connector to provision Identities from or to SAP HCM natively, which Dell is currently missing as a native connector.

From what i’ve seen during that 90 minute demo, i’d like to get a demo installation of the EmpowerID solution suite to do some hands-on experiments discovering the tool. It looked pretty nice, pretty quick and pretty responsive although the majority of the configuration and administration is done through web interfaces.


MDM in the context of IAM

While BYOD is not the newest phenomena in the IT and Security area, i just had my first project not only touching an Mobile Device Management platform. As part of the identity lifecycle it’s necessary to get control over mobile devices that are used by the end user. While this is pretty easy reg. mail integration (as soon as the user gets deprovisioned, the mailbox access is no longer possible), it’s not that easy to handle reg. profiles and own apps.

In my customers case, they do have MobileIron deployed in their infrastructure. As part of the deprovisioning process they came up with the requirement to retire devices used by the terminated employee within their MobileIron instance, which would take all the certificate based access from that device to the customers wifi and network resources.

As the MobileIron API does support HTTP requests to retire devices, it was necessary to have the device ID for an device in order to retire it. But lucky wise there is an HTTP web request to get a decent set of device attributes from MobileIron. We choose the most convenient and quickest approach: extending our IAM database model with an table to store the data of mobile devices with an foreign key link to the employees table. Calling an dedicated HTTP request within MobileIron, we got an CSV back from MobileIron carrying the decent set of attributes. This CSV then get’s imported into the IAM system. This process happens every hour.

As an employee now get’s terminated, we also kick off a process to retire all devices that are known for this employee in MobileIron. So far, this is satisfying the customers requirements.

For an later phase, this does also satisfy additional requirements that will come up (or already came up in while defining upcoming phases of the IAM strategy): being able to use the data from an governance and access management perspective does also answer questions such as “Who is accessing the enterprise network with what kind devices?” or “Are there devices with an software release that is not safe to let them touch the enterprise network and enterprise resources?”.

To cite a good IAM guy i did a project with: “Building an IAM implementation is like building a house: it’s all based on a strong foundation.”

I expect to see more projects coming up with even deeper integration between IAM and MDM as the BYOD wave is still rising…

Physical Access Control from an IAM / IAG perspective

October 28, 2012 Leave a comment

I was traveling a lot in the last two weeks to deliver two PoC’s on-site at customers being interested in an IAM / IAG solution. One customers facility is totally locked down by Physical Access Control Systems (PACS), that it’s even necessary to have a badge to get to the restroom. During the work on our PoC scenarios and discussions about how to handle some of the upcoming challenges, we also touched the PACS from IAM / IAG perspective.

Just take a look at the onboarding process of an employee:

IAM get’s a new Identity from it’s integration with the HR system. HR does deliver all necessary attributes, so that IAM is able to provision all necessary entitlements based on

  • the location
  • the department
  • the cost center
  • primary or secondary business roles
  • job titles or other attributes. So why not utilize these information also for an integration with the customers PACS? This would enable the IAM system to either interact directly with the PACS to issue necessary “physical access permissions” or to integrate with the PACS in an disconnected way by at least letting the PACS guys know, that there is a new employee to issue a new badge containing a certain amount of access permissions within the dedicated location of the employee.
    By thinking this integration in an wider context, IAM could also offer physical access permissions to other locations (for example meeting places in another building or floor) in form of an access request done by the employee or someone else on behalf of the employee. This would bring audit trail also down to physical access permissions of employees including their request and approval process in an proven way tracked by the IAM system.

Just keeping in mind that theses physical access permission can be issued based on an approved request out of the IAM system, these request could also be only for an limited time for special locations or rooms. But anyways, over time there will be huge number of physical access permissions being issued to all the employees, so how to keep control? Pretty simple by just utilizing the IAG capabilities of an grown IAM suite: Based on dedicated schedules, managers could be asked by the system to recertify their employees physical access permissions as well they would be asked to recertify role or group memberships. For special locations or sensitive rooms like archives or so, their could be also special attestators integrated into the recertification process.

But there are still one and a half challenge left:

Starting with the half challenge: if there is no direct integration with the PACS (disconnected system), there is a bit of an effort to keep track of existing physical access permissions and how to reconcile them. But this could be managed by utilizing data exchange formats.

The full-sized challenge still exists with an deep PACS integration as well as with an integration as an disconnected system stays the same: the physical connection between a human and the access card or badge. As soon as this combination is “broken” and not reported to the instances who can react, this will be a security threat. This could be only taken out of the way by using biometric procedures such as fingerprints or iris scans to identify someone by an system to determine the physical access permissions. But this might lead us to an privacy discussion as well.

An example for the need of Access Control and Governance

September 13, 2012 Leave a comment

There was an article on ZDNet yesterday, saying that the Scottish Borders Council was fined £250,000 for dumped pension records.

So what was happened: The Scottish Borders Council hired a third party to digitize pension records of former employees. (Hopefully) After digitizing those records would have been shredded if everything would have going well. But it didn’t. The records were dumped in an recycle bin like old newspapers. A citizen found those documents and informed the Police, which secured the documents and all contained data (as the article says there were salary and bank account data included within those records).

So in this case there were major faults done by the Scottish Borders Council:

  1. It seems like there were no agreement or part of the contract how the records would kept or shredded after digitizing them. So no one within the Scottish Borders Council was taking care if and how the records were handled or destroyed.
  2. While passing the records to a third party, the Scottish Borders Council still is legally responsible for all contained personal data within those records according to the Data Protection Act. This would have meant that there would have been a tracking of the records handling, digitalization and shredding or handing them back to the Scottish Borders Control Council for an separate process of destroying the records.
    Both issues are showing the lack of Access Control and Governance over those records. There was no check, if those records are still existing or if they are destroyed. With the responsibility according to the Data Protection Act, the Scottish Borders Council would have needed at least a certified proof of the data handling, process of digitalization as well as the process of handing those records back or shredding them in an appropriate way instead of just dumping them into a recycling bin. Within IT systems we would name that an complete Audit Trail, in the best case peppered with access recertification to ensure, that it’s ok that someone has access to somewhat.

So with the potential exposure of personal data to identity fraud £250,000 (currently a bit more that $400,000 or 310,000 €) those faults are pretty expensive in comparison to the minimal impact of avoiding them.