SSL is not broken, Browser based PKI is

Trust using Public Key Infrastructure is alive and well; especially when profiled the way that Healthcare is doing.

There are many articles being written lately about how broken SSL is. I assure you that SSL is not broken, but this declaration does not in any way contradict anything said in the other articles. What is wrong is that their Title is wrong. I suspect that each one of them knows that their title is wrong, but recognize that it is much harder to explain "Browser based PKI" than it is to just denigrate all of SSL.

The problem is well defined by others (e.g. The Register: How is SSL hopelessly broken? Let us count the ways, SSL And The Future Of Authenticity, HTTPS Is Under Attack Again), so I am not going to rehash the problem. I will however say that what the Browser publishers did (all of then, vendor and open) was produce something that was better than nothing, and likely the best they could have possibly produced at the time. I am not convinced that even today the use-case scope that they are trying to address is possible to do any other way. The scope is simply too big. So, what we have is something that was "Good-Enough", had we waited for "Perfection" the internet would have literally never left the confines of a toy for research.

The good news is that Healthcare standards and regulation efforts have had the benefit of this example of failure. Back in 2004 when IHE was putting together the Audit Trail and Node Authentication (ATNA) profile, we were very careful to take a very strong standard, TLS (The standards version of SSL), and carefully call for the certificates to be either manually managed one-by-one, or managed off of a dedicated Certificate Authority (CA) explicitly for that purpose (See IHE ITI TF Vol 2a:3.19.6.1 Certificate Validation). We spoke about this for a few years and finally realized we needed to capture even more details in a White Paper on Management of Machine Authentication Certificates

Further we recognized that the trust must be bi-directional. It is important that a Server be strongly authenticated, but that server really should have a way that it can tell that a truly authentic client is connecting to it. Thus we defined from the very beginning something that is not done with SSL at all, and rarely done with TLS; require that both sides can mutually authenticate. In this way a rogue system can't probe a server, as that rogue system won't be able to authenticate that it exists. This very step stops many malicious methods.

Healthcare Use-cases:
One of the big advantages we have is that healthcare has much smaller use-case scope. It may seem that universal access to healthcare information globally might be too big of scope, but even at the intergalactic scope this is more controlled than the scope of an Internet Browser. I am not going to say that we have the problem solved, but the very fact that our use-case scope is much smaller makes this more likely.

The Direct Project had many discussions on how to handle Certificates. There were quite a few attempts to oversimplify in ways that would have created a very similar problem as the Internet Browser has. But many
good people kept insisting that we can't re-invent that failed system. I cover this in my blog post on Trusting e-Mail.

The Exchange pattern is different, and I cover some USA initiatives Healthcare use of X.509 and PKI is trust worthy when managed. Although this is a discussion of the USA initiative, it is actually covering ground that is being covered in many places.

Revocation Checking:
When a Private key is exposed, the PKI solution is to indicate that the certificate is revoked. This is done using either a Certificate Revocation List (CRL), or Online Certificate Status Protocol (OCSP). I am not going to go into the technical details of either of these. They are methods of indicating that a certificate that looks otherwise good, is actually not good.

Part of the articles lately is to point out that again the Internet Browsers have implemented a Policy that is potentially not the best policy. Again, I will point out that at the time they didn't really have a choice. The Policy that they implemented is to consider a failure to contact be able to check revocation as an indication that the certificate is likely good. A really security minded person would see this as broken, clearly if you can't get a positive indication that the certificate was NOT revoked, then one must assume that it actually is revoked. A Security minded person would have the system 'fail closed', that is if in doubt don't allow something. The Internet Browsers chose to 'fail open', again because of their scope.

Healthcare has not really address Revocation Checking and what it means to the healthcare use-cases. I have been involved in a handful, and they typically never really come to a conclusion. The terms 'fail open' and 'fail closed' are too narrow for healthcare. We need to think in terms of 'fail safe', that is to look at the use-case and do what is the safe thing. Where safety considers the patient's medical status. Safe might be to 'fail closed', telling the patient to come back tomorrow; but safe might be to 'fail open' because the patient is in great pain and danger.

Revocation must be part of the PKI discussion. Unfortunately there is no simple answer here, unless you consider "fail safe" a simple answer.

Conclusion
Covering an infinite scope, like Internet Browsers must cover, is impossible. When the scope is limited to a specific industry a much more intelligent solution can be achieved. This has happened in other industries. SSL is not the problem, the PKI model is the problem. We must stay alert and make sure that simplification doesn't make a fatal mistake. Don't throw the baby out with the bath water.

PHR as an equal peer on the HIE

There are many people wondering why the Patient is not involved in the discussions of HIE. I think that the patient is involved, but I am not likely to convince any skeptics. What I am frustrated by is that the PHR vendors, who claim to speak for the Patient (Ill leave that skepticism aside), are sitting around the edge of the room and shouting insults at those trying hard to make something work. A very civil example is one out yesterday from Bill Crounse from Microsoft. Bill points out a very realistic view of how the Patient can collect and make available their health information.


I would rather the PHR vendors come into the open and transparent discussions as someone who wants to be constructive. The HIE model I have always envisioned and worked hard to make concrete in the IHE XDS and XCA profiles is one where the PHR is an equal partner on the HIE.

A fact that is not well publicized by Microsoft is that they were a major force in the creation of XDS.b as their IHE member was the Editor of the supplement throughout the development. So, clearly there was a time when they did participate openly and transparently in the development of the Profiles that they are now ignoring.

Another fact that is not well publicized by Microsoft is that they were a major contributor to PCAST, where they write about a very different model for building a HIE.

By participating as a equal partner on the HIE,  the whole vision that Bill has can happen. And yet for those patients that are NOT CONNECTED their data can still be shared. And support those use-cases that are necessary without the patient agreement (such as legal action).

I challenge the PHR vendors to come into the open. Participate openly in a transparent way. Help us understand why there is concern with the current models. Help us shape the solution. This is a journey, not a destination. Stepping stones are what we need to make concrete while having a good vision of the horizon.

Update 4/8/2011: Bill tells me via Twitter DM that he never got my comment, so I entered it again.

Trusting e-Mail

The "The Direct Project" re-branded from "NHIN-Direct Project" - is addressing the use-cases where the very small healthcare clinic that has little or no current Healthcare IT technology can take some initial steps into the Healthcare IT world. I very much support this usecase, as this audience really needs low-tech solutions. Getting this audience to think in terms of electronic documents (text, PDF, CDA, or any other) is more important than getting them convinced on a specific method of exchanging the documents. A component of the Direct Project that has not been totally settled is Trust, that is the 'why' of Trust.

The Direct Project has nice formal "Overview" document. Given that I was a contributor to this document, I think it is a good document. This document is a really good introduction, it is not a technical document, specification, or deployment guide. These other topics are covered elsewhere on The Direct Project wiki

The Direct Project is recommending that Secure E-Mail be used to enable the very small doctor office to communicate Patient information with others. In short, replacing their FAX machine with e-Mail; but e-Mail that is 'secured'.  So, how does e-mail get 'secured'? There are a few ways to do this with the most common being an isolated and/or proprietary messaging system (e.g., the old AOL network). This is clearly not a solution, as it is not standards based nor open. In standards there is PGP and S/MIME (I am not going to spell out the acronyms as it is really not that helpful here). The Direct Project choose to specify S/MIME. This answers the question of the standards to protect the content, but does not address why someone should trust the content.

The technical answer is X.509 Digital Certificates, and Public Key Infrastructure (PKI).  More technology, that I really don't think needs to be fully understood by you, right now. These are technologies that are really good and really mature. They give us a technology equivalent of credit cards. With credit cards there is a known system behind them, there are online ways that merchants can verify they are not stolen. We trust credit cards because we have built up trust in them. They are not all issued by the same company, most are issued by the big credit card agencies, but there are still some that are issued by a local store. The important part is that we as consumers don't know how this all works, but we have come to trust them.

Trust is not easy, I could go deep into the X.509 technical details; But ultimately trust is more of a soft art, it needs to be built and maintained. Trust can be one-on-one, like you and your closest friends; Trust can be built in a close social group, like your church or work; or Trust can be brokered by large institutions. The X.509 system can scale like this as well.

Starting big, the USA has an Infrastructure (PKI) where many federal partners have 'cross-certified'; essentially they have agreed that each-other's way of issuing X.509 Digital Certificates (credit-cards) are good-enough. There is technology behind 'cross-certifying', but I am keeping this blog to softer arts. This cross-certifying allows someone looking at another identity to be sure that it was issued by someone they 'should trust'. Meaning the federal partners have a way to know that the other guy should be trust-able. This cross-certifying has been extended to others. I cover this in more detail elsewhere

This wonderful system says I 'should trust' this identity, but I might not really want to trust them for sending or receiving Patient Data. As a doctor, why would I trust a EVERYONE who has a federal issued identity to send me Patient Data. So, this still means that I need to include some subset that I Trust. I have a number of communications with DoD and VA customers. These certificates chain to the Federal PKI bridge, and I know that they require far more identity assurances than our GE certificate authority. Even with this fact, I do NOT TRUST ALL certificates issued by the Federal PKI bridge. I trust those that I know I should.

In my job as a Healthcare Standards developer, I work with GEs competitors. So I also have signed e-mail conversations with specific individuals in companies like Siemens, Philips, etc. Clearly I do NOT want to trust all of their corporate issued certificates. But I do want to trust their standards developers. I also deal with individual consultants, that use self-signed certificates.

My solution is to leverage the functionality of my email application. When I want to send something securely with someone else, my email application will look into my local directory of trusted X.509 certificates. If it doesn't find one it tells me that it can't send the message securely. If this happens then I send that person a simple email telling them who I am and that I want to send them something securely. I tell my email application to sign this email with my GE issued X.509 Digital Certificate. Eventually I get back an email from this person that is signed by them, thus giving me their X.509 Digital Certificate. Now that I have their X.509 Digital Certificate I can send my original message securely to them.

Trust happened in there. I didn't detail how trust was built, so let me do that now. When anyone receives a signed email, the email application will verify the signature and indicate if it was good, bad, or unverified. Good means that it fully checks out, bad clearly says that there is falsification going on. Unverified means that it checks out, but that the identity is not known. This will happen for any first-contact. If I am not expecting this email, I will likely simply delete it. If I am feeling generous I might read the email to see if there is a reason I should follow up. If I am uncomfortable, I might call the person. It is only after I am comfortable that this is a legitimate email from someone I should trust; then I explicitly tell my email application to trust that certificate.

Today there is not much risk that someone will send me a signed email that I should not trust. I am confident that I can weed these out. The number of individuals that I should trust is likely 100 or less, a rather easily managed number.  I prefer that my X.509 Digital Certificate is NOT published on a white-pages Directory. I am far more worried  that someone will use my publicly available GE issued X.509 Digital Certificate to send me encrypted SPAM, as encrypted email can't be inspected by the GE SPAM filters.

I offer here a way to get started at the 'why' of Trust. Start with the small number of connections that this small provider needs to communicate with. I really don't think that we need a large system of Trust. Like the credit-card industry, starting with the local department-store and building upward is a good roadmap. Setting expectations is the factor we need to teach in awareness. Awareness of what certificates are, what encrypted email is, what signed email is... These tools, just like any new tool needs to be explained to the community. Once they know what the tool is and how it should be used; they can better understand and use it. Encrypted email from someone they have never worked with before is 'unexpected'.

Thoughts on Goal III of the ONC HealthIT Strategic Plan

On Friday, March 25, ONC released the Federal Healthcare IT Strategic Plan 2011-2015. I will constrain my observations to Goal III, as I think people like Keith Boone will have the others covered well.

Goal III: Inspire Confidence and Trust in Health IT

• This section is not large (7 pages), seems to want to say all the right things, but falls flat in a few places. I like the attention to openness and transparency, as these are the prime ways to get 'Confidence and Trust'. When things happen that can't be explained, people will loose trust. When things happen and no one is held accountable, people will loose trust.
• "Transparency" is said 8 times in these 7 pages. I like that, I want to see more transparency from HHS/ONC...

III.A. Protect confidentiality, integrity, and availability of health information III.A.1 Promulgate appropriate and enforceable federal policies to protect the privacy and security of health information.

• This is a nice solid section. There are some specific items listed that are going to make the regulations better. More clarity, more specifics.
• I hope they do keep the regulations Risk based. Many people complain about the HIPAA Security rule being too vague and allowing items to be 'addressable'. This is a recognition that not all operational environments must implement the same technology, procedure, or physical controls. The HIPAA Security rule is primarily a Risk based rule, with guidance on the areas to be worried about. Risk models are always the best way to address Security. 

III.A.2 Enforce existing federal privacy and security laws and maintain consistency with federal confidentiality, policy.

• An important tool to get better security and privacy is to increase the punishment for poor security and privacy violations. This is a huge win for Privacy and Security, nothing like a little punishment of your peers to get you to think more closely about your own house. The more open and transparent this is, the better. See: USA healthcare breach notifications. 

III.A.3 Encourage the incorporation of privacy and security functionality into health IT.

• I very much agree with the title. I very much disagree with the substance behind this title. There are many frameworks for Security capability/functionality. We do NOT need to invent a new one. We simply need to apply those that exist. I know that those in Healthcare think that healthcare data is so special, but from a security perspective it is not special. Re-invention comes with unintended consequences. We should stop thinking we need to reinvent security for healthcare. I am frustrated at being involved in 6 re-inventions so far: HIPAA, NIST 800-53, CCHIT, EHR Functional Model, HITSP, and now Meaningful Use. See: Meaningful Use Security Capabilities for Engineers

III.A.4 Identify health IT system security vulnerabilities and develop strategic solutions.

• My initial reaction to this was not printable. We really don't need ONC trying to analyze security vulnerabilities and defining how to fix them. I don't think that the spirit of this section is at the same scope as I was initially thinking (SQL injections, buffer overruns, cross-site scripting). I think what they mean is high level controls, such as identifying that we need to have a consistent way (policy, guidance) to address an emergency mode that exists when a natural disaster takes out the local infrastructure (Katrina, Fukushima). 

III.A.5 Identify health IT privacy and security requirements and best practices, and communicate them through health IT programs.

• I am worried that the guidance they give will be too specific and not recognize risk based application.  For example: The guideline to encrypt everything, without a clear understanding of the scope and appropriate application in a risk assessed context has caused much unnecessary churn. Overall this vague guidance that doesn't recognize the scope and risks would be bad for Health IT.

III.B. Inform individuals of their rights and increase transparency regarding the uses of protected health information
III.B.1 Inform individuals about their privacy and security rights and how their information may be used and shared.

• I welcome this. I think that patients are uninformed, and too often the lack of information drives fear. The hard part is that this is a tough audience. I have seen the marketing power of HHS/ONC in their current marketing of the Direct Project. 

III.B.2 Increase transparency regarding the development of policies and standards related to uses and sharing of protected health information.

• I agree transparency is critical to building trust

III.B.3 Require easy to understand reporting of breach notifications.

• I agree empowering patients to monitor what is happening to their data is a critical part of trust

III.C. Improve safety and effectiveness of health IT
III.C.1 Provide implementation and best practice tools for the effective use of health IT.

The short statement given sounds really good. But the text found in section III.C.1 is frightening. It is clear that they see the Vendor community as the problem. They speak over and over about helping avoid legal issues, avoiding workflow redesign, avoid ongoing maintenance and upgrades, and legal concerns related to vendor contract clauses. If this is happening, then I agree it needs to be fixed; but as a prime strategy and veiled in 'safety and effectiveness'? I work for a vendor, and I am poring out endless hours to make this Health IT vision happen. I think I can claim to be a leader and have many peers from GE that are creating this thing called Health IT. Is this the thanks I get?

III.C.2 Evaluate safety concerns and update approach to health IT safety.

• ONC has commissioned the Institute of Medicine (IOM) to conduct a formal study. Why is the IOM looked to on the topic of "Safety"? This seems like the domain of the FDA. I know this is a scary thing to many, but Safety is not rocket science. It is handled through Risk based methods with monitoring and remediation. I would like to see some openness and transparency here too.

III.C.3 Monitor patient safety issues related to health IT and address concerns.

• Monitoring patient safety is critical to achieving patient safety. Transparency to the process is critical to a system that can be trusted. Transparency is hard, so it must be carefully used.
• A second topic covered in this single paragraph topic is that of data integrity, data provenance, and data correction. These are prime use-cases for any data management system. They should not be relegated to a tiny minor component. 

Goal III: Measure
Decrease the percentage of Americans who are very concerned about the security of electronic health records

• The most interesting part about this is that they are willing to admit that they have no idea what the current baseline is. I would suggest that they do actually have a good baseline in the current HHS published Breach Notifications. Is this sufficient, no; But it does exist.

Healthcare use of X.509 and PKI is trust worthy when managed

In todays HIT Standards meeting there is a presentation by the Privacy and Security Workgroup. The presentation includes two topics: "Digital Signature Standard" -- which is really "Digital Certificate Standard" (a typo that keeps coming back; and "Enterprise Level Provider Directories".

The discussion on Digital Certificates should look good to the readers of my blog, as it simply says that X.509 digital certificates and certificate management are the right method to build trust for healthcare. I worked hard to get the group to simply recognize that these are already strong standards, and that healthcare does not need anything special from them. They do recognize that a single strong Certificate Authority would be easy, but recognize that multiple trust-roots is likely to be needed.

The group also recognized that both Direct and NwHIN exchange can use the same technology. A point I made in S/MIME vs TLS -- Two great solutions for different architectures. 

What is very exciting is that the group did come to the conclusion that HHS/ONC should take a leadership role in managing certificate trust, specifically recommending that there be a certificate authority that is available for building a Nationwide Health Information Network (NwHIN) that is cross-certified with the Federal PKI Bridge. The good news on this is that the CA that the NwHIN Exchange uses today is cross-certified with the Federal PKI Bridge. So, I think this simply means continued funding and explicit endorsement of this model. This would make managing trust across the nation 'easy'.

As soon as anyone says that managing trust is 'easy' those in the security domain get worried. This worry is well founded as security is hard. One timely and specifically targeting of certificate management is the "Compromise of SSL Digital Certificates". This news has gotten some people to question the X.509 PKI model, and even the SSL/TLS protocols. In both of these cases the technology are in no way flawed. The technology is still the best technology available today. What is broken is the way that certificates are managed for Internet based Web-Servers. This broken part is very different between Internet based Web-Servers and the way that HIT Standards expect NwHIN to operate.

1) Default - No Trusted Certificates

• The recommendation for the Direct Project is that there are no assumed certificates, that a site explicitly trust certificate roots only when there is known and validated reason to trust.
• In the NwHIN Exchange there is ONLY one Certificate Authority that is 'trusted' by the systems
• In IHE ATNA there is a warning about the need to have a different trust pathway for healthcare than is used for internet web servers (See IHE ITI 2a:3.19.6.1)
• Essentially for Healthcare Information, there should be a totally independent analysis of 'who should you trust'

2) Reality is that multiple trust-anchors are needed

• Direct fully recognizes this, and the report out showed this. Indeed it recognizes that sometimes in e-mail communication one trusts specific certificates and not necessarily all certificates issued from a Certificate Authority.
• The participants in the NwHIN Exchange will likely need to have more than the one Certificate Authority in order to support the local connections.
• IHE specifically recognizes both of these as fact. And points to an excellent white paper from NEMA

This is a good start, but does not address the very fact that no matter how carefully one has evaluated 'who should you trust' and mistakes can happen. Thus there needs to be a strong mechanism to deal with mistakes. Certificate Revocation is a mature field for checking if a specific certificate has been revoked. This mechanism is used when a certificate is determined to have been exploited. This mechanism checks with the Certificate Authority to either get a list of certificates that have been revoked or using an online transaction check that a specific certificate has not been revoked.

3) Certificate Revocation mechanism are needed

• Direct didn't fully specify this, but did include it in the Security Model
• The NwHIN exchange includes certificate revocation
• IHE recommends that systems support both OCSP and CRL mechanisms.
• In all cases a certificate should not be 'trusted' unless it has been fully validated. Full validation does include checking the signature and how it chains to the set of trusted certificates, that the certificate has not expired, and that it is not revoked.

This mechanism is not typically used for root certificates. This is the problem that is being exercised with the current SSL Digital Certificate Compromise, in that there is a Certificate Authority 'Comodo' that had it's infrastructure compromised. Thus there is a need to tell the world that their root certificate needs to be un-trusted. As scary as this situation is, it doesn't happen very often. Given that it doesn't happen very often, there is little energy spent on trying to automate it. Given the breath of 'trust' that all of the copies of Internet Browsers have (the distribution mechanism); this un-trust is a very big problem.

The result is that X.509 and Certificate Management is the right technology for building technical trust for Healthcare. But this does not mean that we can relax and not continuously think about this trust.  We should recognize that the way that Internet Web-Servers is a different management model than we will use in Healthcare. This is the key to why a system that seems broken for Internet Web-Servers should be considered highly secure for Healthcare Information.

Which leads to the second part of the presentation. a topic I covered Healthcare Provider Discoverability and building Trust

HIMSS assembling Risk Analysis Resources

This group is just getting going. They are made up mostly of healthcare providers. There is a Survey on the site that is looking for input on what should be done. I have injected IEC 80001, but need more support to make it stick.

HIMSS Medical Devices & Patient Safety and CE-IT Community Create Systems Risk Analysis Resource Guide Web page
Recognizing the critical need for guidelines that would help healthcare organizations by identifying or providing resources and tools necessary to address the challenge of today's medical technologies, the HIMSS Medical Device & Patient Safety Task Force and the CE-IT Community have collaborated in establishing this site. Here you will find valuable resources that will help to insure that your organization has the information and tools it needs to realize the benefits of today's healthcare technologies while also being prepared to address any of the challenges and vulnerabilities associated with those technologies.

For more about the Medical Devices & Patient Safety Task Force, contact David Collins. For more about the CE-IT Community, contact Christel Anderson.

ANSI and Shared Assessments Launch Initiative to Examine Financial Impact and Harm of Breached Patient Information

This crossed my desk this week, and I jumped on it. I look forward to continue to develop the RISK models, while controlling the Theater. First up, to help the group understand that HARM is not just due to financial impact. This is not news to Medical Device manufactures, or Healthcare Providers; but it does seem to be a specific focus of this ANSI group.  This broader definition of HARM has been a big discussion in the IEC/ISO 80001 discussions, and even there it isn't fully understood.

ANSI and Shared Assessments Launch Initiative to Examine Financial Impact and Harm of Breached Patient Information

http://www.ansi.org/news_publications/news_story.aspx?menuid=7&articleid=2835

New York, NY, March 23, 2011 – Healthcare organizations are struggling with two key concerns today: how to protect patient information and how to better understand the financial harm caused when protected health information (PHI) is lost or stolen. A new project – led by the American National Standards Institute (ANSI), via its Identity Theft Prevention and Identity Management Standards Panel (IDSP), in partnership with the Shared Assessments Program and its Healthcare Working Group – has been launched to explore the financial impact of unauthorized PHI access. The goal for the “ANSI/Shared Assessments PHI Project” is to identify frameworks for determining the economic impact of any disclosure or breach of protected patient data.

The ANSI/Shared Assessments PHI Project got underway last week with a meeting of its advisory committee. The initiative brings together professionals from across the industry: data security companies, identity theft protection providers and research organizations, legal experts on privacy and security, standards developers, and others.

This effort will culminate in a report targeted at those responsible for and entrusted with protecting and handling PHI. The report will help inform the healthcare industry in making investment decisions to protect PHI, as well as improve responsiveness if and when this patient information is breached. 

Rick Kam, president and co-founder of ID Experts, is chairing the initiative. “Organizations that are custodians of healthcare data are grappling with how to calculate their risk exposure when PHI is lost or stolen,” commented Kam. “The ANSI/Shared Assessments PHI Project will inform their investment decisions to protect PHI and will provide guidance on how to respond if this data is compromised.”

The group plans to tackle the problem by identifying existing legal protections related to PHI, defining points of compromise in the healthcare ecosystem where there are risks of exposure, and assessing the financial impacts of the disclosure of PHI. A survey is also contemplated to support the fact-finding process.

Industry experts are invited to participate in the next meeting, via a two hour conference call on April 7, 2011, from 12:00 p.m.– 2:00 p.m. Eastern. Interested parties can send an email to idsp@ansi.org to join in the work effort. There is no fee to participate and most of the work will take place via conference call over the next few months.

The initiative is made possible through the generous support of the following organizations: DriveSavers Data Recovery, Inc. (premium sponsor) and Affinion Group, Center for Identity Management and Information Protection of Utica College, Direct Computer Resources, Inc., Europ Assistance USA, ID Experts, and ZOHO ManageEngine (partner sponsors). Additional sponsors are welcome; see sponsorship opportunities.

About ANSI

The American National Standards Institute (ANSI) is a private non-profit organization whose mission is to enhance U.S. global competitiveness and the American quality of life by promoting, facilitating, and safeguarding the integrity of the voluntary standardization and conformity assessment system. Its membership is comprised of businesses, professional societies and trade associations, standards developers, government agencies, and consumer and labor organizations. The Institute represents the diverse interests of more than 125,000 companies and organizations and 3.5 million professionals worldwide.

The Institute is the official U.S. representative to the International Organization for Standardization (ISO) and, via the U.S. National Committee, the International Electrotechnical Commission (IEC), and is a U.S. representative to the International Accreditation Forum (IAF).

About the Shared Assessments Program

The Shared Assessments Program was created by leading financial institutions, the Big Four accounting firms, and key service providers to inject standardization, consistency, speed, efficiency and cost savings into the service provider assessment process. Through membership and use of the Shared Assessments tools (the Agreed Upon Procedures and the Standardized Information Gathering questionnaire), Shared Assessments offers outsourcers and their service providers a faster, more efficient and less costly means of conducting rigorous assessments of controls for security, privacy and business continuity. The Shared Assessments Program is managed by The Santa Fe Group, a strategic consulting company based in Santa Fe, New Mexico.