Maybe you have noticed it. Privacy is an issue. A bit strange since there are only 11 days left until the new EU General Data Protection Regulation (GDPR) will become fully enforceable throughout the European Union.

So before end of May 2018 all organizations that process data of EU citizens must comply with this General Data Protection Regulation. Determining how to design and improve your systems to meet the GDPR is not straightforward. A common way to take security and privacy measurements to comply with the GDPR is to use secure services and trusted infrastructure components.

Vulnerabilities are at hardware,firmware, virtualization, middleware and application layers. Data leaks caused by blindly trusting security services of other system should be prevented. Since creating IT systems and especially IT security and privacy aspects is technical very complex many companies use IT vendors and consultants in the hope that they known what they are doing. However a common pitfall is that most IT vendors are still not using OSS building blocks for building secure systems when possible.

When it comes to privacy you need openness on all aspects. Everyone with the required knowledge should be able to determine how security & privacy risks are mitigated by evaluating your architecture and the used software components. Openness is a key factor to security and privacy. OSS software that can be hosted on premise or on cloud environments is well positioned to ensure privacy when it comes to your digital footprints. Free Software is probably the only way to ensure that. For security and privacy in the end it comes all down on (a bit) trust.

  • Do you trust the engineers who claim to have the knowledge for making a good design?
  • Do you trust the software components that are used?
  • Do you trust the infrastructure that forms the underlying platform that is used for hosting all of the crucial services?

One thing that often is neglected it that nobody knows the inner details (security by obscurity) of the used infrastructure components. Knowing all the details about a (Cloud)platform, operating system, or network services is however close to impossible. So you need trust somewhere. However security and privacy defense based on trust only is not the best way to design a system. So there are key principles for creating a decent security and privacy architecture. Some principles are:

  • Don’t trust infrastructure.
  • Apply defense in depth.
  • Minimize the attack surface
  • Fail safely.
  • Run software and infrastructure components with the least privilege.
  • Avoid security by obscurity.
  • Keep security and privacy simple (So NO! Complexity).
  • Detect intrusions and record compromise.
  • Do not trust services (of others).
  • Establish secure defaults.

Of course when you do not trust infrastructure components or services the consequence is that every application or API-call needs to authenticate and authorize every action. But doing security and privacy in a decent way to minimize risks has a price. So make make sure you known what risks you are willing to take and which risks you want to mitigate by using more complex security and privacy measurements.

The “defense in the depth” principle is often violated, as well as the principle “not to trust the infrastructure”. Most companies and engineers are not fully aware of the risks they take by trusting infrastructure components of others. Following ALL the above security and privacy principles when improving or creating IT systems is a good start and approach to be compliant with the GDPR ‘privacy-by-design’ requirement.

This blog post will be added (after rewrite) as an extension on the ‘Open Reference Architecture for Security and Privacy‘. We are working on an renewed version. Please join us!

Don’t trust infrastructure
Tagged on: