You don't work in a vacuum and your systems shouldn't either. In order to be successful in today's marketplace,
financial companies have been forced to rethink their business operating model. For traditional "brick and mortar" financial firms, realizing that having all personnel, systems and services for managing their information confined within the walls of the company is an outdated strategy has been game changing. In order to maintain efficient, cost-effective business operations, they've been forced to look to third-party partners to perform those commoditized functions that no longer add value -- for example, benefits management, HR, IT help desks, travel services, underwriting and stock valuation.
While business leaders easily see the value of these relationships -- letting experts do the work at a lower cost -- the actual execution has been difficult. Regulations like PCI DSS and HIPAA have cracked down on the transportation and access of data when it contains sensitive, financial or personally identifiable information (PII). In addition, state breach notification laws make organizations responsible for the exposure of personal and financial information even if the loss occurs due to a deficiency in a third party's security. Because of these risks, many financial firms have elected to keep their information local to guarantee its protection, but allow access for their partners to manage the data. This has caused a boom in the use of identity management federation technologies like OASIS' Security Assertion Markup Language (SAML). However, like PKI in the 90s, adoption of secure "trust relationship channels" for business-to-partner communications still continues to lag business need.
Identity management federation issues
There are several reasons for this delay in implementing identity management federation. The main reason is the lack of contract language around the "trust relationship" between the financial company and its partner. Without the proper contract wording, the company cannot ascertain the level of risk they're exposed to by using a third party, or how much relief they can expect should the partner breach the terms.
There's also a major communication management issue involved. For identity management federation relationships, one company takes on the role of the identity service provider to many partners. Due to the level of management complexity that arises from operating many trust relationships across multiple protocols with multiple versions, few companies want to take on the role of the service provider.
This complexity is partially due to a major technology issue in the actual transportation of the trust relationship information. Transportation of "security assertions" is done through the use of federation technologies: SAML and the Liberty Alliance's Identity Federation Framework (ID-FF), both of which are viable solutions. Three versions of SAML are used in the financial industry -- V1.0, V1.1 and V2.0 -- along with two ID-FF versions,V1.1 and V1.2. While they all work, they are not interoperable. This is causing companies to have to support an infrastructure for multiple technologies, and sometimes all of them.
Finally, it can be extremely difficult to ensure a third party is granting access to the right personnel authorized to see and manage the financial company's information.
Key identity federation considerations
So what can be done to streamline identity management federation? Here are some steps to help the process:
- Know your business -- Before a company looks at the use of strategic partners, it needs to understand the functions within the organization that are candidates for outsourcing. Business functions should be classified, and strategic operations should be excluded from outsource consideration.
- Know your workflows -- As a company looks at working with outside partners, it needs to understand where the entry and exit points are for the partner. An organization must also know if data will continue to reside within the confines of the company or will reside at the partner's site. Appropriate processes and procedures must be modified to reflect the new business workflows.
- Determine the sensitivity of the information in the function under consideration -- An organization must know what information resides in the function and whether it contains sensitive, financial or PII data. The company must also determine if there are any regulatory or legal issues concerning where the information resides or where it's acted upon. The company must work with its potential partner(s) to decide if the personnel interacting with the information need to have additional background or any other checks before they're granted access to the information. Finally, they must determine if the information has any intrinsic value to aid in determining contract relief values if it's lost or exposed.
- Determine the access requirements of the partner's resources -- Once a company knows what information the function contains, it must then determine the access rights needed by the partner to manage the function: administrative roles for managing the identity management federation technology, management roles for managing the federation relationship, system access for applications and programs that will use the federation services, and access rights for end users who will use federation technologies in gaining access to remote services.
- Define the security assertions needed to ensure security of the information -- Upon knowing the sensitivity of the information and access requirements, the financial company is now in a position to define the contractual obligations, security controls and communication needs to ensure the partner's authorized users can securely interact with the information of the business function. These should then be communicated to the partner company for its consent.
- Determine the security assertion protocols needed in support of the communication channels defined -- At this point the company should work with its partner(s) to define the proper protocol -- SAML, ID-FF or both -- and the versions that will to be supported. Where possible, the latest versions of the protocols should be used to provide maximum information on the requester and the role they will play in interacting with the financial company's information.
This can be a strong point of contention. The financial company will of course want to support a minimal number of protocols to reduce their support costs while the partner(s) will want to support the standards they use. There's also the risk that the partner doesn't support any federation capabilities. While not optimal, alternative authorization methods may be needed, like synchronizing login/password information, but this should be considered a short-term mitigating control. In any case, whatever is agreed on should be put in the wording of the contract and any future migrations, say from username/password to SAML in two years, should be documented with who will incur the costs and the timeframe for the conversion.
- Define the audit levels and reports required -- A financial company should work with its partners to determine what levels of audit and reporting are necessary to ensure compliance with the contract terms and conditions.
- Define how the communication channel(s) will be managed -- If the financial organization doesn't wish to offer identity services, it must either delegate this responsibility to the partner or seek out companies like Ping Identity Corp., which provides independent federation operations for companies and their partners. The obvious advantage of using an independent operator is that it can provide connections to all of a company's partners, and do protocol conversion if necessary, without the company incurring ongoing connection and management costs. The disadvantage is that a company must budget for use of the service on top of the partner's services.
- Build a plan --After reaching an agreement of how the partner will connect to the financial company and what functions it'll perform, the company should build an execution plan including timelines, resources needed, architectural changes, process definition, funding model and business justifications. These should then go through the proper approval channels before execution.
With understanding of how third-party partners can benefit the company, and careful planning around the use of their services, financial companies can reduce their risks while providing optimized services to their stakeholders, customers and partners. While the communications component is only one facet in making this work, without it, your systems will continue to work in a vacuum while the rest of the financial industry leaves your company in the dust.
About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 20 years. He specializes in security/identity management strategies, methodologies and architectures.