The question of taking advantage of a third-party vendor or developing public key infrastructure (PKI) within our your organization is a pretty tough question that doesn’t seem to have a clear-cut answer.  Each method has its own pros and cons that I’ll try to outline for you here, and there are a lot of factors that could go into this decision.

Some of the good points on sourcing a public key infrastructure through a third-party vendor could include:

  • Guarantees and service level agreements on uptime and availability of the infrastructure they are providing your organization.
  • Pricing is often based on volume where larger organizations can take advantage of better rates than organizations with smaller user populations.
  • The majority of companies out there providing this kind of service often have very thorough disaster recovery and business continuity plans that help to ensure that what you’re paying for is always available and remains as secure as possible.
  • These vendors can also supply key management services that are streamlined and efficient to help minimize the overhead costs associated with implementing and sustaining the program.

Bad points of using third-party vendors to implement PKI could include:

  • You’d have to trust an outside agency to handle a business area of your organization that, if compromised, could be very costly to your company.
  • You’ll
  • You’d most likely have pay per-user fees.

Research seems to indicate that implementing a solution in-house can be far more costly up front than taking advantage of a third-party solution.  That being said, in the long run, it may be less expense because the only costs associated with the project would be maintenance and sustainment costs long term.  Also keep in mind that if your company experiences heavy growth in personnel in the future, the cost of your PKI would not significantly change if managed in-house.  By implementing a PKI program yourself, you’d also maintain control of how the program is implemented and would not have to necessarily trust anyone outside of our company with something so integral to the overall security posture of your information and resources.

There have been a lot of studies on this particular question, and they do not all agree on a suggested implementation plan.  I suppose the questions that need to be seriously considered prior to making a decision would include:

  •  Do we have the capital to invest in an in-house solution at this point in time?
  • Can we support the implementation of PKI, and do we have the expertise in-house to stand something like this up?
  • Are there vendors that can provide this service to us at a reasonable and affordable cost to our organization?
  • Do we expect the size of our employee population to increase or decrease significantly in the foreseeable future?

It has been my experience that the primary accomplishment of compliance endeavors is to keep the notion of security and risk management at the forefront of both technology and business management within an organization.  I’ve worked in and around HIPAA, FISMA, and PCI, and they’re all too high level and nebulous – making them all but pointless.

To pick on one, just as a for-instance,

PCI DSS 2.2 (v1.2) states, “Develop configuration standards for all system components.  Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.”

This is an impractical and not overly useful compliance requirement.  It’s so over-simplified that it’s all but meaningless.   Ensuring that an organization has “a process or architecture” is not the same thing as ensuring that that process or architecture is relevant and effective.   That’s the fundamental problem with FISMA,

Do you have an incident response plan or a disaster recovery plan?  Yes.  Well then you’re solid.  Nevermind that your incident response plan consists of running antiquated anti-malware software and calling it a day, or your disaster recovery plan is comprised of user guides and installation manuals from 6 versions back.

Compliance efforts are good, though – even though much of the work is really just spinning wheels to appease some over-arching governing body.  Whether it’s the Feds for FISMA, or VISA for PCI, it’s easy to meet the letter of the law of compliance and still have an insufficient and flagrantly deficient security program/posture.  Again, to me, the biggest benefit of compliance mandates is that it keeps information security and privacy practices on everybody’s mind.  And, if companies take it seriously and don’t merely treat compliancee efforts as a paper drill (as many, or most, do), compliance efforts really can provide benefit.

One last thought.

IMO, the focus of securing information HAS to be on the users and information handlers.  So much is made of configuration and policy and procedure.  All of which is necessary and valuable.  However, you’re only as good as  your weakest link.  Steve Riley of MS (http://blogs.technet.com/steriley/) made a good point when he wrote, “I don’t know where to direct my ire—at the spammers who litter the Internet with their spew or at the people who still get duped by it.  Spam would wither away if everyone just ignored it.”

The point is that if people wised up and understood the risks, threats, and attack vectors, compliance would come naturally, and the organization’s security posture would be greatly enhanced.  Until companies understand the value in compliance efforts and take it seriously and don’t just “go through the motions”, resources are better spent by focusing more on  users and less on compliance.