First step: Determine security requirements with the protection requirements analysis
But let's start at the beginning, because it's not about solutions, but about the questions: What specific needs do you have? What are your security requirements? A security analysis, also known as a VIVA analysis, is used for this purpose. VIVA stands for Core aspects of security:
- Confidentiality - Only authorized persons should have access to the information.
- Integrity - It should not be possible to add to, change or shorten the information unnoticed.
- Availability - The information should be available when it is needed.
- Authenticity - It should be ensured that the information originates from the source it claims to be.
Security therefore means much more than the confidential handling of information.
Finding the right dosage
In addition to the type of security requirement, it must also be clarified how high the protection requirement is. One option is to classify them into the usual categories:
- Public
- internal (e.g. "normal" working documents)
- Confidential
- strictly confidential
Ill-considered or excessive requirements can be counterproductive for security or have an impact on acceptance and costs, for example. The starting point here is the correct classification of content, as not all content is equally worthy of protection.
Why is such a subdivision important? Quite simply, the greater the need for protection, the greater the associated effort and often also the associated restrictions. Who wants to lock their normal work documents (classified as "internal"), which can easily be stored in the filing cabinet on their desk, in the safe? This is not only annoying and hinders work, but also quickly turns into counterproductivity.
Let's take the well-known game of "password rules": Continuous password changes and rules to enforce more secure passwords make sense up to a point. However, if the rules reach the employees' pain threshold, they look for ways out. For example, the password is written down and placed under the keyboard or even dangles on a post-it note at the bottom of the monitor - this doesn't help anyone.
The realization: It all depends on the proportionality of the means.
Why E2E-Encryption ?
The use of End2End encryption can of course be a useful tool. However, it should always be borne in mind that it is not a one-size-fits-all solution and can fail to meet actual security requirements.
But where does the End2End lie come from, especially in the context of cloud solutions?
- In many cases, there is no well-founded safety analysis and derivation of proportionate measures. Instead, reliance is placed on marketing statements.
- Cloud services are considered insecure and untrustworthy and therefore require special protection.
End2End encryption is indeed a sensible measure for securing untrusted offers if there is a corresponding need for protection. However, you may also need to be aware of the side effects mentioned above. Usability, functions and even security can be negatively affected.
How can End2End encryption have a negative impact on security?
Example: Every modern email system in companies has protection mechanisms against spam and dangerous attachments containing malware.
A cloud storage system with End2End encryption does not offer this option. The reason for this is the end-to-end encryption, which makes it impossible to implement appropriate protective measures at a central location. From this perspective, such systems tear a hole in a company's security architecture.
Not to mention other risks: Who guarantees availability, for example? Are there backups? These aspects should not be completely disregarded, even if there are assurances - after all, there is a mistrust of the provider.
What is the alternative?
The starting point should always be a safety analysis including the derivation of appropriate measures.
Assuming we are not talking about a high-security solution, a trusted environment is sufficient to replace e.g. End2End encryption with encrypted communication and possibly encrypted data storage. Two examples of this are
- Private Cloud - A company can also operate software itself on premise/in its own cloud.
- SaaS offers from trustworthy providers - If internal or confidential data is involved, SaaS offerings that have corresponding service level agreements (SLAs) and have appropriate certifications (e.g. ISO 27001, information security management system (ISMS)) can also be considered.
Conclusion - a way out of the End2End lie
The aim must be to find appropriate solutions. The basis for this is a comprehensive protection needs analysis (VIVA) including a protection concept (security design). In any case, it is worth taking a closer look to avoid ending up with a false sense of security that hinders business.
