The Blog

Elvis has left the building (what to do when a new version of the software is released).

Todd Rossin | August 25th, 2010

RE: Oracle Fusion Middleware 10g vs. 11g stack selection (OID, OVD, OIM, OAM specifically).

Here at IDMWorks we specialize in Identity and Access Management full life-cycle services.

Discovery √ Design √ Implementation √ Development √ Support √

During a recent trip to a customer site for an installation of the Oracle Fusion Middleware stack we ran into an interesting conundrum. We were to install the 10g release of OVD, OID, OAM and OIM into the development environment. The customer pointed out that 11g had been released approximately 3 weeks prior and asked for a recommendation of whether we should jump to the 11g implementation path or continue down the 10g path.

First, let me say, the customer was right on point with the question. We like a customer who is knowledgeable and will challenge the decisions and recommendations that we make as a team because that is the same customer who will “take care” of there system long after Elvis (or in this case IDMWorks) has left the building.

Conventional wisdom states that you never jump to the next release of a product in the first month. You wait for stabilization (and typically the first service pack). However in this case we must keep in mind that the products, at least the directory components, are pretty mature. So we can add another option of a mixed upgrade, perhaps 11g OID and OVD, with the 10g release of OAM and OIM. Additionally, with a new release, and this speaks to stabilization, you don’t have the luxury of all the little “gotchas” that have been addressed with implementations of the past. In our case, when we had a Linux Service Pack Library dependency issue, we had Google to rely on to find the fix in less than 5 minutes. No call to Oracle Support, no waiting for recreation and resolution, no explanation to the customer on why we must halt progress while we investigate the issue.

So we created a game plan as follows:

1) Stick with what works!
The known 10g release, while the “older” release, provides a level of maturity and issue resolution that will allow our project to remain on budget and time. This is HUGE. The unknowns that a fresh release present, if the customer has time and budgetary constraints (don’t they all?), means that time spent resolving the “basics” is time lost (and hence money).

2) Plan, Plan, Plan for the future!
In order to address the 11g want of the customer, the resolution we opted for, was to develop an upgrade path and plan to 11g including the steps, the timeline, the associated cost and the follow up procedures that will allow, in a cost and time effective manner, the ability to smoothly transition into the next release in a matter of months instead of years.

3) Work with the customer
This should go without saying but don’t let personal agendas drive the project to failure. The customer wants (and rightfully so) the latest and greatest they can have. If that means the latest technology, than so be it. In our case we have three options, Old, New, and Newish (a little old and new mixed together). However, because we are the implementation partner ours is not to decide but to recommend. As such we explained all available options, gave our recommended approach and let the customer know that if they choose to move forward with another option (the non-recommended one) we would support them 100% and move forward in that direction.

In the end the customer stuck with the recommendation approach and we are well on our way to a successful implementation with a path to the future product laid over the existing framework!

Build your project toolbox

tim.edmonds | August 25th, 2010

New clients sometimes ask “what tools do I need to keep this new technology up and running”. A basic tool kit for IDM or WAM environments is essential for making a successful project into a successful long term operation.

Here are a few basics I have collected over time.

For any LDAP access, you need an LDAP browser that can read any LDAP acessable directory. Apache Directory Studio fills that need and is available on just about any platform you might be running.

Apache Directory Studio LDAP browser is based on Eclipse, and can be had in two flavors. One is a stand alone installable program that requires only a system Java Run Time to function. Download, install, and run.

http://directory.apache.org/studio/

The second flavor is as a plug-in to your existing Eclipse installation. If you already use Eclipse for other work, this will add the LDAP browser capability.

http://directory.apache.org/studio/installation-in-eclipse.html

Either way you go, you get an LDAP browser that is capable of working with any LDAP accessible directory.

Many IDM and WAM products run on Linux. Working with Linux requires different tools than a Window Server. Many applications use a command line installer that may or may not have a GUI component.

GUI access necessitates X-Windows capability to display. If you run a Mac, you should have it covered. PC’s do not come with any X-Windows capability. Xming provides that capability for PC’s and
I have been able to run Xming on all recent versions of the Windows OS.

http://www.straightrunning.com/XmingNotes/

Start with the Public Domain version, and don’t forget the fonts. Get all the fonts because you never know what a vendor may use.

Of course, you cannot get to the X-Windows unless you have some way of accessing the Linux
Console. Once again, Mac users have that covered with Terminal. You can use telnet on a
PC, but a better method is via the old standby, Putty. No, this is not your Plumbers Putty,
but an SSH client that has stood the test of time.

http://www.chiark.greenend.org.uk/~sgtatham/putty/

This is the official site, grab a copy. There is no installation necessary, it just runs.

The next tool is something to transfer files back and forth between your PC and the
Linux systems. For this, the SCP secure protocol is used, and you need a program that
can do this reliably.

For the PC, I use WinSCP.

http://winscp.net/eng/index.php

This is another of those programs that has stood up over time. It allows you to drag and
drop files between systems. Even better, if you set it up to do so, you can have it
open and edit text files on the target system in your favorite text editor (more on those below).

For the Mac I like Cyberduck. I have tried a few others, but I keep coming back to this one.

http://cyberduck.ch/

Must be the name…

Next up would be some text editors. Often this is a personal choice, there are many out there,
but here are a couple that I use.

For the PC, PSPad is a free and very capable editor available with many languages.

http://www.pspad.com/

When I say languages, I refer both to spoken and programming languages. Highly versatile, and
very configurable. Much better than Notepad or Wordpad

For the Mac, I use TextWrangler

http://www.barebones.com/products/textwrangler/

Many of the same features, in a package for the Mac.

I have not done too many IDM projects where some type of SQL database was not involved. Most have their own client tools, but what if you wanted something that could handle them all? For that, I turn to the Squirrels… SQuirreL SQL.

http://squirrel-sql.sourceforge.net/

You will need to obtain each vendors JDBC Type 4 driver to connect. I am a Novell IDM person, and I like this because I can use the same JDBC URL in SQuirreL as I do in the JDBC Driver. This gives me the same view of the data that the driver should see. SQuirreL is Java, so it works well on pretty much any desktop OS.

I did not intend to go into how to use these, maybe later. These are just a few available
tools to keep in your toolbox for system administration and maintenance. Remember, when
it comes to ideas on how to use these tools, Google is your friend.

PCI yai yai!

rquinney | August 18th, 2010

If your business accepts or processes payment cards, it must comply with the PCI DSS (Payment Card Industry Data Security Standards). All businesses and merchants that store, process and or transmit card holder information are now required to be PCI compliant.

PCI DSS is a set of requirements for enhancing data security. This originally began as individual programs from Visa, MasterCard, American Express, Discover, and JCB. To facilitate the broad adoption of consistent data security measures Visa, MasterCard, American Express, Discover, and JCB aligned their individual policies to release the Payment Card Industry Data Security Standards.

In today’s economy, with merchants and business owners required to thoroughly evaluate operating costs, merchant processing fees are an area frequently overlooked. Evaluating and comparing merchant processing solutions including fees for services, such as PCI compliance for your business, can be well worth the time it takes and may result in considerable savings for your company.

Many companies are struggling with some of the same issues repeatedly around PCI DSS compliance and Governance.  First and foremost, companies need to know whom and how to pay for PCI Compliance and where the ROI is.  Second,  how do companies free up the System administrators to do what they pay them to do (administer systems that is).  Whether they be network engineers, UNIX administrators, or Windows administrators (to name a few); too often organizations have turned our technical assets into grumpy compliance administrators and/or control owners.  I think we all know how much system administrators just love to get involved in compliance and governance (can someone get Johnny form under his desk and let him know I’m not here for PCI, SOX and Audit).  Third, spreadsheets, spreadsheets, spreadsheets.  Did I mention spreadsheets?  I’m not sure about how much I need to elaborate here, but multiple spreadsheets housing your control environment assures that everyone is working off a different set of controls.

Too often we task our administrators to be owners of controls that are poorly written (often by other System Administrators).  Most times these controls are written very broadly and are not housed in a central repository (which, by the way, external auditors love to flag).  With broad controls the external auditor can test what they believe the control defines, often times leading to the entire control failing and thus having to be retested.  Additionally, we do not supply our System administrators with the correct tool set, what tools says Johnny.  We spend many times manually going through IOS Code, systems logs, Active directory logs, and of course spreadsheets to try to test controls and assure governance.

This is where IDMWorks can come in.  IDMWorks QSA’s can build a framework based on Risk Drivers, write general controls that can be applied to most standards, build automation into the process, reduce your external audit time by 50% (ROI), and assist you with writing solid test plans to execute.  Look at IDMWORKS as your tax preparer, but for Compliance and Governance.  Creating a new framework along with solid test plans assure a very efficient process to reduce the amount of time wasted by your external auditor during the testing of poorly defined controls.  Additionally poorly written test plans are part of this spiral of non compliance.  IDMworks takes a practical approach that will assure your PCI certification and reduced your audit cycle and costs.

The truth about Roles, what people won’t tell you about RBAC.

Paul Bedi | August 2nd, 2010

I have been at three separate companies as of late  that all strive to have the “perfect role model” for their enterprise. This desire is usually coupled with the desire to have some irrational number of roles to show that their role model was successful.

<Sidebar> Let’s say your company has 100,000 people worldwide, how on earth could you believe that you’re going to end up with 10 roles?

The answer to the number of roles is generally a product of how you want to create enterprise roles (this includes Business and/or IT roles). There are few options when it comes to designing roles, to list a few:

  1. Bottom-up, Top-down and Intersection Analysis (yawn, that’s so 2009)… and the result being a set of IT roles that map to resources, and business roles that map to the IT roles.
  2. Allow Supervisors to control # of roles, they decide what goes in their roles, and your systems make sure that they haven’t put any “toxic combinations” in their roles.
  3. Use #1 & #2 with a standard set of entitlements that everybody gets based on some organizational data.
  4. Allow a product to analyze your data and suggest candidate roles.

(All of these mean nothing unless your roles are “in-context”… to be covered in my next post.)

Now comes the part where I give my prescriptive advice on which of the 4 options to use. The answer: RBAC is art, not science, you should try all of the above, at least see if they pass the litmus test for your organization (better yet, call IDMWorks and we can help you figure it out).

Once you’ve figured out what direction you are going with roles, the next step is to stuff all of that in a product. Might I suggest Aveksa as it is the one of the best products in the industry, and use it to manage your roles, entitlements, segregation of duties rules and certifications.

Baby Steps – Password Management

tdubois | July 29th, 2010

To build on an earlier posting, I would like to touch on the phased approach to implementing an Identity Management solution. I was recently on an engagement where the customer requested that we implement an identity management product and an single sign on product to perform a simple phase one approach. The project had a primary focus on password management on the Identity Management side and Web SSO to a handful of key applications for the customer. Within three weeks we implemented password synchronization from AD to IdM and three secondary resources, Forgotten password management using custom Questions and Answers, and password reset via a web interface. We also implemented Web SSO to a handful of key enterprise applications.

The key point here is that the project was focused and limited to a specific achievable goal. The project was a success in a short period of time and produced a quick win for the vendor, the customer and our team. Password management and Web SSO are fairly straight forward and simple parts of an Identity and Access Management project and they produce highly visible and easy to quantify ROI for the customer. The visibility is across the board.

The end user experience of being able to login once to access much of their entitlements, to clicking on a simple link if they forget their passwords, to having their passwords automatically synchronized across the enterprise when they change it.

System Administrators and Help Desk personnel are able to focus on more important aspects of their jobs and less on resetting passwords.

Management can watch as the number of help desk tickets and the productivity of their System Administrator teams improves.

Password Management is a great first step towards easing the administrative burden on some of the same teams that will be key in implementing future phases if the IAM infrastructure. It is a great strategy that many enterprises miss out on when they attempt a “Big Bang” implementation and end up with a fragmented solution and a stressed out project team. I can’t stress enough how important it is to only bite off only what you can chew and allow the ‘Process’ to work for you.

Unique Identifiers and Why you shouldn’t let users select their own ID

Todd Rossin | July 20th, 2010

The Unique Identifier, AKA the Unique ID, the UID, the Enterprise Unique ID, the Primary ID, the Global Unique ID.

The UID is the key internal identifier, potentially used for authentication, authorization, group membership, and tracking (reporting, logging, auditing). It is recommended to have this ID be unfriendly so as to discourage its inappropriate use. This ID is centrally provided, perhaps through your Identity Management solution, and should be assigned to all current active users and future users. The UID should be non-revokable and non-reassignable; hence it needs a large enough capacity to sustain generations of UIDs . All other identifiers should be either directly or indirectly linked to the UID.

Now as to why you shouldn’t let users select their own ID:
1) The first mistake users make is using Private Data when creating their ID (such as):

  • First and last name
  • Address
  • Phone numbers
  • SSN
  • The names of parents, children and siblings

Many governance rules for applications specifically disallow Personal Identity Data and this most likely would need to be coded in your IdM application and you would not be able to prevent it in the case of someone using SSN when you are forbidden from asking for SSN in the first place and this is a really, really long run-on sentence :) .

2) Some users will use derogatory and/or inflammatory language in their name (which may cause an issue with your support staff/help desk).  I mean let’s face it, there are a lot of geniuses in the world who think Bizhatch is a cool user ID.

3) As a fix in your Identity Management process, might I suggest adding a forgotten user name Use Case into your requirements so as to avoid the issue of the user having an inaccessible ID as they can request the user name be sent to their registered email address.

4) If a user name is selected by a user, and the user name already exists, the new user will now “know” an existing user name in the system.
This presents an associated issue of “guess the password” in which someone selects a user name/password combination such as userID: Minnesota password: Twins.  While you should have password rules to help offset this, the above example might just work.

5) I would highly recommend NOT using email address as a login credential in the future as you cannot guarantee uniqueness and a family could all use the same ID (ex. RossinFamily@ThisIsNotUnique.com).  Additionally if someone uses an address they no longer have you have just added to the complication (“oh yeah, I registered with my Mickey D’s email address, too bad I got fired for embezzling, maybe I should have though ahead”).

6) Technologically why not:

  • You must code validation rules if rejecting special characters in the name (O’Rossin, R@isen, Van Rossin, etc.) and worse if allowing them (such as remove the ‘ from O’Rossin and make it ORossin, join Van Rossin into VanRossin, etc.).
  • If the user can select User ID, you will have to decide if it should be case sensitive (which I would hope not as the volume of help desk calls will sky rocket) as a user might pick a name they wish to be case-sensitive (ex. ToddRossinRulez)

All in all, this list, while not being complete by any stretch, should give you some ammo as to not allowing a user to select his/her own ID.

Provisioning Roadmap

tbalfour | July 19th, 2010

Identity Management – Best Practices

With the current regulations and audit requirements being placed on organizations, many companies are looking to Identity Management (IdM) solutions to help achieve control of who has access to what resources. This includes not only the provisioning of access rights, but also the ability to change access when individuals change positions, and rapidly and completely remove access when employment in terminated.

The available commercial off-the-shelf (COTS) applications are very capable of performing these tasks in an automated fashion and include many features such as enterprise wide password management, self serve functionality, approval workflows, timed events, high privilege account management (firecall accounts), Role Based Access Control (RBAC), and compliance reporting. With all these capabilities, it becomes obvious in a very short period of time that these features will provide great value to an organization by eliminating or reducing manual processes, decreasing potential for human error, improving the time to productivity of new employees, and maintaining control of who is accessing what resources.

The identity management companies will be more then happy to tell you all the wonderful benefits available with their products, these benefits can be huge. What you may have difficulty determining is what it is going to take to deploy this software. During the sales cycle, you will hear many grand stories of how a vendor can assess your environment and accurately design an implementation solution within a couple of brief weeks — and that the actual deployment will take place and be in production in no time. This is also where the flashing red lights should go off with a large blinking “warning” sign in your head.

Let’s face it, in order to properly deploy an enterprise-wide IdM solution, you are redefining how a critical component of your business operates, or, in other words, you’re taking on a business re-engineering effort. To suggest that this can be done in a short period of time with little design effort is not only unrealistic, but rather insulting. Now with a bit of the dirty laundry about identity management on the table, let’s talk about a realistic approach if you truly plan on succeeding with this endeavor.

Consulting Versus In-House

Many companies have attempted to deploy IdM solutions on their own with varied levels of success. Unless you have resources on staff with a significant amount of experience in this area, experts suggest you consider hiring a company that is well versed in the technology you choose. These projects consist of a plethora of integration activities along with very detailed configuration parameters, requiring individuals skilled in many different areas. Of course, there are many training courses available to teach the technology. However, it has been proven time and again that, without real world deployment experience, the information gained in the training class will only take you about half the distance required to handle a full-blown production deployment.

In the interest of becoming self sufficient in the shortest order of time, sending your staff to training just before the implementation activities begin, and then having them work side by side with the consulting team, produces the best results. This allows the freshly trained staff member to work with experienced individuals in their own environment.

Over the past several years, best practices have proven that multi-phased implementations are truly the only realistic approach. By training your staff early and then having them work with the consultant on the first couple of phases, they will be much better prepared to proficiently handle the additional phases with little or no assistance.

Design As You Go – Not Likely

If you are led down a path that suggests the assessment, design, and deployment of your IdM solution can be done in a few weeks, be assured that what will really be happening is a “design as it’s built” approach, and you will be riddled with change orders.

A similar scenario would be to hire a builder who presents you with a plan for a house that has a foundation, four walls, and a roof and will cost you $100,000 for live-in conditions. You sign the contract, and when the job is just about done, the contractor approaches you and inquires if you would also like windows in this house. Rather perplexed that this had not already been done in the initial phase of the project, you nod yes. He then tells you that an additional $50,000 is required to have that feature and he has to cut holes in the new walls. He then asks if you plan on having separate rooms in the house, which, again, of course you do, so now you need an additional $250,000. Next come questions about lights, bathrooms, kitchen, doors, etc. You get the point. For an additional $500,000 above the original estimate, you get the house you really wanted. Bottom line: you realize if you had hired an architect, all these things would have been handled initially. You would have known the true cost of the project at the get-go.

Like this scenario above, the proper approach to an IdM deployment is for your vendor to understand your requirements at the beginning, perform an assessment, and then develop a solution design. Of course, throughout the design, you should be interacting closely with the vendor to make sure that the end result is what you really want implemented.

Process is King

The way your company has evolved has been the impetus for many of your current methods of getting the job done. At the time it was done, it probably was the most efficient way to resolve the issue at hand, but over time you add more complexity, more features, more functionality, but rarely re-evaluate the method in which access is granted. This results in “wedging” in a quick fix to get the desired solution accessible in the quickest manner possible. This is all done to meet business requirements and to ignore that in the design phase would be irresponsible.

Remember, an IdM deployment is a business process re-engineering effort. In order for any vendor to properly deploy the solution, they must first gain an understanding of your current processes and requirements in order to ensure that the desired end result is achieved in the new solution. Once they have done that, the design process can begin, which should also have clearly defined “to be” process models.

Now that the requirements have been gathered, assessment and design completed, the vendor should be in a position to give you a very accurate statement of work and project plan that ties back directly to the design document.

Up to this point we have discussed what it takes to get to the deployment stages of an IdM solution. By now you may realize that these are the most critical elements to achieve success. Let’s face it, if you don’t have a road map, you will get lost and will be asking for a lot of costly directions.

Staged approach

A staged or “phased” approach to implementing an IdM Solution is the only realistic approach. This “phased” approach creates an organized time line and project plan for rolling out an IdM solution in the shortest possible amount of time and with the lowest possible costs for an organization, while at the same time minimizing risk in proportion to the scope and requirements of the entire project.

The simplest rationale to this implementation plan is to enable your internal staff with the appropriate skills as early as possible in each key stage and milestone to enable self-reliance as quickly as possible.

This approach also naturally restricts each phase into manageable chunks, while delivering clear, tangible value every step of the way, so your organization can commit to business-related deliverables and deliver those values and ROI as planned.

Phase 1: As soon as the base IdM solution is installed, the first few critical applications or back-end system should be integrated into the IdM system. Once those back-end resources are connected, orphan accounts will be identified, adopted and otherwise cleaned up, and self-service capabilities for that user base will be initiated for password resets and forgotten passwords.

Phase 1A should include the automatic provisioning and workflow for infrastructure accounts for those same critical systems. This process should be dynamically driven by attribute evaluation, based on organizational unit, job title, business role, etc. Once that process is complete, automated approval workflows and RFI workflows should be created.

Once Phase 1 and 1A are complete, they can be combined and repeated by your group to bring on other standard systems. We assume that during the first Phase 1 and Phase 1A, internal staff is learning the necessary skills in which to achieve this, so more activities can be conducted internally and in parallel as the project progresses, thus ultimately reducing your overall time-to-market and implementation costs.

Phase 2 will include all the non-infrastructure based applications and systems in your IdM implementation, and will be dependent on the integration of the systems rolled out in phases 1 and 1A.

Ultimately, lessons learned will enable refinement and replication across other business units. Although this project phase is the most complex and far-reaching, it ultimately will have the highest long-term rewards.

While implementing an IdM solution, it is recommended that to recognize the full value of that solution, organizations should be moving toward a role-based provisioning model. Phase 2 should include the formation of Role-Based Access Controls (RBAC) for out-of-the-box services and applications (services and applications which require custom connections into the system will be done in Phase 3). A full analysis of business role requirements will be conducted, as well as the mapping of business roles to actual user and group access rights. Depending on the size of the organization, this process can be conducted much more quickly and efficiently using a vendor-based solution.

Ultimately, once this mapping and analysis is complete, these roles and policies should be defined as either static or dynamic within the IdM system. Once this process is finished, provisioning and de- provisioning of access rights will be fully automated and role-driven.

The Role of Identity Management in Public vs. Private Cloud Computing or How I stopped worrying and learned to love the Cloud: Part II

Todd Rossin | July 9th, 2010

Let’s recap shall we? That install of Firefox, IE, Safari, etc. is your method to cheaper, easier to use techno-services outsourced to a service provider (like Google) who take on the infrastructure, technology and heavy lifting so that you, the business, can reap the ROI. Risks, well, we covered that already, HERE.

So how about Identity Management?
We also defined Identity Management, HERE. We can take the 101 knowledge and apply it to the Cloud. So we build out our security into buckets including Access Management (Authentication, Authorization, Entitlements), Provisioning and lest we forget, GRC (Governance, Risk and Compliance). Mix in audit, logging and reporting and we have a recipe for success.

Access Management in the Cloud
For our Cloud solution to work we need strong authentication (making sure you are who you say you are), strong authorization (making sure you can access what you are allowed to access, write where you are allowed to write, read what you are allowed to read, etc.) and record what the user has been up to (audit, log, report).

Provisioning in the Cloud
The keys to the kingdom rely on creation of an actual account (provisioning) but almost importantly in making sure that that when you leave, by choice or not, that we take those keys away (de-provisioning).

Governance, Risk and Compliance in the Cloud (GRC)
Attestation of all accounts (clean up and dump the orphaned accounts folks) and a certification process to ensure it remains so must be implemented. We don’t want Walt of the just fired brigade to have access to the company payroll do we?

Private Cloud Identity Management – Lower Risk with Higher Cost
We defined Private Clouds, HERE. Basically you own it, you operate it, you control it, you firewall it and the associated cost savings are greatly reduced but the security is greatly improved. Private clouds can be built on your own or outsourced to a “private” cloud provider but the cost savings diminishes regardless (disadvantage). Your single sign-on, authentication, authorization, provisioning, role management, GRC, and audit & logging can sit behind the firewall in the private cloud. The odds of data loss and hacking go down considerably (advantage). The return on Investment will be long term at best (I say at best because the technology cycle may produce the “next best thing” before you have a chance to recoup the cost).

Public Cloud Identity Management – Higher Risk with Lower Cost
We defined Public Clouds, HERE. On the plus side, Public Clouds equal diminished costs. Diminished costs equals happy Business people concerned with ROI in business speak we mean Return On Investment, in Security speak we would have meant Risk of Incarceration ;) . The risk of deploying Identity Management services in the Cloud increase with the move into the public realm. Security in a shared environment is much more complex as well as the potential network complexity. The risk can be diminished in deploying Identity Management services within the Cloud as you should have access to defined best practices that have been utilized by past customer Cloud IdM implementations. As such the amount of bleeding edge risk will be reduced somewhat (this is where a company like IDMWorks can help you). Your contract with your public cloud provider had better insure that they manage and take responsibility for the risk associated with potentially exposing your company’s corporate, customer and/or user data (by accident of course, but no one wants to lose their job or get sued over such an occurrence).

The Benefits of Private vs. Public Cloud Identity and Access Management
Public Cloud:
Return on Investment (ROI) higher, much quicker
Higher Risk through lessened security and network complexity

Private Cloud:
Risk of Incarceration (ROI) lower, Return on Investment long term at best
Associated costs are similar to running the environment in-house, Cloud free

Conclusion: Use Identity and Access Management to cut the Endemic Risk of Cloud Computing
By outsourcing our infrastructure hardware, software and services you, the customer, must verify and co-manage the security your provider provides. This is where Identity and Access Management come in to play.

Custom extensions for Citrix Password Manager

James Carroll | July 8th, 2010

Whether installed as a standalone solution or as a feature of a Citrix XenApp farm, Citrix Password Manager (CPM) provides a secure and effective Single Sign On (SSO) solution.  Users benefit from no longer having to remember (or worse jot down on scrap paper) the numerous credentials needed to access the systems they use.  Organizations benefit from reduced Help Desk/Password Reset activities and greater control over user credentialing processes. Add in provisioning services, Windows account reset, and Smart Card integration and you have an solution that can rapidly fill many pressing security needs.  Complexity associated with installation and configuration of the system is driven largely by the existing infrastructure and applications, but Citrix does a fairly good job of limiting the moving pieces and the installation process is straightforward.  Basically you’ll need to get 4 things in place:

  1. A Central Store to keep all those credentials.  Citrix supports Active Directory, NTFS File Share, and Novell shared folder repositories.
  2. A client side application to retrieve credentials from the Central Store, cache them to the local machine, and submit them to the application
  3. A License Server as Citrix has this crazy notion about getting paid for some reason
  4. Application definitions that define how CPM should identify and react to applications of interest

For Application Definitions, Citrix provides a tool cunningly call the Application Definition Tool that walks you through the process.  Definitions can be created to handle Logon events as well as Password change events.  The latter includes Password Format validation designed to help the user (or even CPM itself) create a password that meets each application’s strength, length, and complexity requirements.  CPM provides these wizards for typical Windows applications, Web based applications, as well as Host based applications presented to the user in a HLLAPI compliant emulator.  Each has its individual quirks, but most technical professionals, even managers, will find the process straightforward.

There are times, however, that even the best efforts of Citrix and the Application Definition Tool are not up to the task.  For those situations allows CPM to call external applications that can manage credential submission.  The external applications can be written in any Windows compliant language and once again Citrix provides a fairly straight forward path.  Again a quick look at the moving parts:

  1. An Application Definition is still required to identify the application of interest. The key difference, however, is that instead (or in addition to) having CPM take actions upon the application itself, CPM executes you custom extension.   Since the users local credential store is encrypted and in accessible to any other applications CPM can be instructed to pass credential information to the external application as command line parameters.
  2. Since the Application Definition is only told  the name of the executable, a registry key of the same name located at [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\MetaFrame Password
    Manager\Extension\{ExtensionName}] where {ExtensionName} is replaced with the name that you gave to the Application Defintion. Of the several values that need to be set in the key, there are two that are the most interesting. The ‘Excutable’ value must contain the path to the extension’s compiled binary. The ‘Arguments’ value would contain any commandline parameters that you like passed. For instance, a value of “/u $_USERNAME /p $_PASSWORD” will pass the UserName and Password for the extension’s use.
  3. The extension itself placed in the folder identified in the key above.

Each of these elements must be installed on each client machine that will use the extension, but once it is the possibilities are endless.  As compiled Windows applications, extensions have the ability to access any and all services available to any other application.  In addition, they could be used to access other systems that may be in place.  External auditing applications, usage tracking services, extended logging, real time centralized validation…. literally any application or service that you have, or want to create, can be accessed and integrated into your custom extension.

Are we underestimating the business impact a security breach may have on our clients?

dstevens | June 25th, 2010

Are we underestimating the business impact a security breach may have on our clients? As information security professionals most of us are familiar with case studies and analysis of the costs associated with a data breach. Aside from the loss of reputation and good will, there are the substantial costs of breach notifications, legal and professional fees, fines, and lost sales. Lost sales due to a data breach, the focus of this blog, can vary widely based on the type and severity of the breach, as well as business factors specific to the type of organization affected.

How might a breach affect your company’s sales? My prior assumptions on the topic changed significantly last week after listening to an ISSA presentation by Julie Machal-Fulks of Scott & Scott LLP, a New York & Dallas firm with legal expertise in data breaches.(1) Scott & Scott commissioned a study by the Ponemon Institute in 2007 on “The Business Impact of a Data Breach” where up to 20% of customers affected by a breach notification would consider taking their business elsewhere.(2) In a separate 2008 study by the Ponemon Institute, thirty-one percent of surveyed people terminated their business relationships with a company that suffered a data breach.(3)

Then Julie mentioned a statistic that I had not heard before. How might customers react to a second breach disclosed by a company? Up to 100% of its customers might terminate their business relationship. I found that number startling. After all, how many Berkeley students switched schools after that university disclosed its second data breach? I would expect none did, despite a loss of reputation for not protecting students’ private information.

But what if you are an entity disclosing a second serious data breach? According to a 2007 conference paper published by the Kansas City Federal Reserve, “While research has shown a disconnect between expressed consumer sentiment on privacy and their actually behavior, it has also shown that consumers respond strongly if a second data breach closely follows the first.”(4)

I believe several factors lead to different outcomes in this situation. If you produce a product or service that is highly desired and unavailable elsewhere, then fewer customers may terminate their relationship, even after a second breach. On the other hand, if your company’s products or services are viewed as a commodity then pay close attention to what Julie said, and take a fresh look at your security strategy, policies, training, and infrastructure.
————
(1) Scott & Scott LLP, http://www.scottandscottllp.com
(2) The Business Impact of a Data Breach, http://www.scottandscottllp.com/resources/data_breach.pdf
(3) Consumers’ Report Card on Data Breach Notification, http://www.ponemon.org/local/upload/fckjail/generalcontent/18/file/Consumer%20Report%20Card%20Data%20Breach%20Noti%20Apr08.pdf
(4) Nonbanks in the Payments System: Innovation, Competition and Risk- a Conference Summary, http://www.kansascityfed.org/PUBLICAT/econrev/pdf/3q07sullivan.pdf

Identity Management

PCI Compliance

Application Dev

Regulatory Compliance

Project Development