Baking Security into Software

Mar 29, 2017 | Security Products and Services | 0 comments

Today, in the best case, most software implements security and privacy as just one of many competing requirements along with functionality and usability. In the worst case, security and privacy are an after-thought—designed and installed to satisfy minimal regulatory requirements, user expectations, or avoid negative software reviews.

That will all change—at least for software used within the European Union or for software or systems which stores the data of EU companies and citizens—by May 2018. That’s when The EU General Data Protection Regulation (GDPR) comes into force. GDPR was inspired by Ann Cavoukian, the former Information and Privacy Commission of Ontario; her office developed the seven principles documented in Privacy by Design. Those principles include:

  1. Making privacy issues proactive, not reactive; preventing breaches, not remedying breaches.
  2. Treating privacy as the default setting
  3. Embedding privacy into design
  4. Not seeing privacy as a trade-off with other considerations, but viewing privacy as a foundational concept to make software better for all other features.
  5. Managing privacy throughout the application lifecycle.
  6. Privacy requirements can be independently verified.
  7. The interests of the individual are kept uppermost in the architecture.

The goal of the regulation is to prevent data breaches and to minimize the impact should a breach occur–admirable goals given the recent troubles of Target, Ebay, Adobe, Yahoo, AshleyMadison, and a myriad of others (to get a sense of the prevalence of data breaches, click here).

The new regulations incorporate software design principles along with business practices to manage this risk. For example, “data minimalization” means that only the minimal data required to provide service to a customer should be collected and then retained in a secure system. Even then, data should be tightly coupled to its use so that only those elements of stored data required for a given function should be shared with that function.

The original intent of the data must be honoured and not expanded. For example, if a business stores birth date to help authenticate customers, then it can’t broaden that intent to then use birth date for demographic profiling.

The subjects of the data must also be informed of how their data will be collected, processed, stored and reported. This information must be independently auditable.

To be ready, most companies will need to change their governance from the ground up. Initiatives (including those managed by the PMO) will need to conduct Data Protection Impact Assessments as part of their Privacy Impact Assessments. Data needs to be categorized and assigned a sensitivity. Policies need to be written and approved and monitoring and compliance protocols implemented. These practices need to have a high level of maturity, repeatability, and consistency.

It won’t be easy or quick, but not only will it be the law, it will also help companies stand apart from their “also ran” competitors.

Check Out These Related Posts



Submit a Comment