What can Developers do to Better Protect PII?

How to Better Protect Personally Identifiable InformationA client of mine recently asked me if I had any Web development related tips for dealing with Personally Identifiable Information (PII). With this being an information security 101 type question, I had to think about it for a bit. It then occurred to me that the things that put PII at risk are the very security flaws I come across in practically every Web security assessment I perform.

Here are the biggies that I shared with him – things that should be on your radar as well:

  1. By all means give users the option to set strong passwords. It’s so frustrating to see big companies with huge marketing budgets that pride themselves on security not allow you to use something as simple as special characters or numbers in your passphrases!
  2. Don’t even give users the option set passwords such as abc123 or 123456. Sadly, I see this a lot. They’ll certainly do it if you let them.
  3. Disable autocomplete in login forms to prevent people who have unsecured laptops (i.e. no full disk encryption) from exposing their login credentials when they lose or have their laptops stolen. It’s not foolproof but it can help.
  4. Enforce SSL across the board – everywhere on the site, period.
  5. Disable all test accounts in production after development, QA, functional, and security testing have taken place.
  6. Take care of your session management. Never ever let old sessions be re-used and always check each session to ensure it’s legitimate.
  7. Validate your input! Arguably the biggest oversight that leads to exposed PII is SQL Injection. Input validation also helps with cross-site scripting, URL redirection and other input tampering that can impact PII indirectly.
  8. Segment your data environment to the greatest extent possible. Put databases on separate servers, separate VLANs or behind separate firewalls to keep out the riff-raff, especially on the internal network.
  9. Study the OWASP Top 10 and other tools available at owasp.org. These resources can be extremely helpful for developers and QA professionals yet it’s rare for me to meet anyone in development or QA who has ever even heard of OWASP. This needs to change.
  10. And finally, look at studies such as the Verizon 2012 Data Breach Investigations Report and you’ll see that most security flaws are simple yet priceless… to the attackers.
Share this post

Leave a Reply

Your email address will not be published.