Web Design and the Risk of PII

Not long ago the I was asked by a Board of Directors to work with a committee on recommendations for a new website for the organization.  The new site was intended to serve as a single point of access for all members of the corporation to get vital data and services to which they were entitled. In addition to this, the portal would double as a social media and PR hub with publicly released documents and media presented for use by the world at large.  The conception of features and workflow went quickly but security discussions were limited to non-specific talk about user verification.  This bothered me, and it should bother anyone who is ever asked to create a virtual hole through which PII could be disclosed.  The board, and much of the committee was initially adamant that users would need to be verified against two distinctly different databases.  From a technical standpoint this created some interesting problems that could be resolved with enough brain-power and money.  The real catch was that these the databases would be local to the server.  From a risk-management point of view this specific design was a bit of a nightmare. Let me tell you why.

Organizational Structure

The organization at the heart of this project was a small non-profit with only a few services to offer its members and many of those services required staff action to implement regardless of the portal’s intended use.  To be frank there was a distinct lack of automation in the back end, not that this is or was a bad thing.  The cost of automating the back end would have far exceeded the yearly cost of the employees who would have been replaced and the non-profit itself didn’t have the kind of liquidity that would allow for such an investment.  So why create an electronic front-end at all?  We live in an age where self-service is the norm and dealing with human being is considered to be “the last stop.”  So the organization was trying to make itself more user friendly while holding to an antiquated notion that verification must be done at the point of customer interaction (the website) rather than on the back end (the staff).  This meant allowing the website to access PII.  Placing the PII database on the server would be a more than nominal risk.  There was no financial benefit to the portal, only a convenience factor for the organizations members.  Would that convenience of remote verification and a service request that would again be verified and processed on the back end be worth the risk of potentially exposing PII?

Encryption Vs Security

There is a concept that floats around that encryption=security, which is both right and wrong at the same time.  This was the argument that was made during a few of the committee’s sessions about hosting the PII on the web server. Its a wrong argument mind you, as encryption alone isn’t enough.  Imagine you encounter two people having a conversation.

Person 1: “I am John Smith” (hands over a folder of personal data)

Person 2: Looks at data file to verify contents of the new file “I recognize you John Smith, how can I help you”

Person 1: “I need service X” (hands over more personal data in a file)

Person 2: Accepts the file and adds it to their big folder “Service X will be provided”

With the notion that encryption is security we decide to encrypt the conversation and now it looks like this:

Person 1: “fasdjhfklasfkjl” (hands over a folder of personal data)

Person 2: Looks at data file to verify contents of the new file “lkjpu97832kl@@”

Person 1: “lejrwfmkdasf” (hands over more personal data in a file)

Person 2: Accepts the file and adds it to their big folder “!()9084jflsds”

That looks like gibberish, but notice that person 2 is still holding onto all that data; and more importantly we can still see data being transferred.  If someone attacks Person 2 they can get a hold of that data without going after the user.  Even if that file was encrypted we’ve still lost it and and whoever took it is likely to find some data stored in the clear on the website that helps them pry useful info out of the file regardless of encryption.  In some cases the attacker might have been able to gather enough info about the encryption to get the key and then everything is unlocked.  We’ve all heard about a retailer that has been hacked whose response was that credit card numbers and other data were encrypted.  They still provide credit checks and other services as compensation because there’s data within data, and encryption is only invincible until a faster computer or better equation or smarter person comes along.  So is encryption enough to secure PII?  No, and not just on a local server.  So now the concept of security isn’t just about basic information security, but about design, and where the data is located.  In the case of the website the committee was designing the PII was decidedly less than secure.


Lawyers love this word.  I love this word.  You should love this word.  The issue here was the question of who is responsible if someone got member PII who wan’t authorized.  Was the organization indemnified (not well enough)?  Would it cost a lot of money (you betcha’!)? Would there be political fallout within the organization (absolutely)?  In the case of a data breach the only bad scenario is the worst case scenario for this organization.  Part of looking at the designs was to do a ROI analysis and we factored in the cost of a PII breach into the that.  We assumed a market rate for services like lifelock and ended with a an estimated minimum cost of around three quarters of a million dollars.  A non-inconsequential sum.

The End Result

The committee eventually came around to the idea that user verification conducted on the site was a bigger technical and liability risk than they would like.  A second design was created that removed the requirement for user verification but was functionally identical.  The new design also removed the original database complexities.  While some PII was recorded at the site it was relatively minor and amounted only to email addresses.  The Board of Directors received the committee’s work well and decided to follow the altered design, beginning the RFP process.

Design, features, and function have a direct impact on the security of corporate data.  Most companies know this and take steps early on to segregate their information and hide it behind a number of firewall and gateways; but not every company has experts on staff, or even understands how networks work.  In this day and age it may be surprising to think that there are so many people out there who don’t understand how technology works and make bad assumptions because of it.  The way to mitigate against knowledge gaps isn’t just to hire subject matter experts, but to hire people who can bridge the gaps between the SME and corporate leadership who may not understand the language the SME speaks.  The Board of Directors in this case had 2 people on the committee to fill that role.  Without them the project would have followed the original guidance and who knows where that would have ended up.