Dr. Heiderich, the topic of data security is of extremely current interest. Can you even recommend companies with a clear conscience to use a messenger?
In principle there are no reasons against it. It of course depends on which software the company uses. First, you should determine: What positive effects does the company expect? For example, faster communication. What negative side effects should be suppressed – such as too much workplace distraction? Those responsible must clearly define what data may be exchanged via messenger. It is also important to think about the long-term tasks of the messenger. Do you only want to be able to communicate or also even browse or export already exchanged messages after many months? What about secure file sharing, how to manage participants, or how to integrate external users? If the requirements are clear, the software research can be done, then come testing and review of suitable products. At least in this regard the topic of security plays an important role. It must be clear which requirements exist and how they are implemented by the respective software.
How do you define security?
There are many aspects to security. For example, if a company uses third-party software, it will naturally want to avoid that company readily being able to read these messages. It often depends on the country in which the provider’s servers are located and which laws apply there. The Internet service provider can also be considered a security risk. In this case, good transport encryption is relevant. Or is it about individual employees gaining unauthorized access to the boss’s messenger account? Security is very complex.
What should a secure messenger be like?
The classic is end-to-end encryption: the data exchange server cannot see the content of the message. Only the messengers themselves, installed on users’ devices, have the keys. All other parties involved in the transfer only see useless encrypted text. It’s like a letter in a sealed envelope.
The same requirements apply to messages saved in one location. These may only be accessible to authorized users. If, for example, the database of all exchanged messages falls into the wrong hands due to a hacker attack, at least the texts of the messages would still be protected against unauthorized access.
It gets more difficult with metadata. These can also be stored encrypted. But someone who can eavesdrop on the encrypted traffic, is often able to easily access this data. Although there are solutions, they are difficult to use in productive operation.
In most cases it is sufficient if the texts and attachments are encrypted. It is also important that the messenger is not too generous with the exchange and storage of metadata. Here, the principle of minimalism and the recommendation to avoid any form of unnecessary data richness apply. Because the more data that is exchanged or stored unencrypted, the more likely it is that an attacker can derive information from the encrypted texts even without a key.
How can you check whether the guaranteed benefits actually provide more security?
There are many possibilities. Planning and specification are of central importance: Which security and threat model is the Messenger subject to? Which risks should be bypassed, which security promises should be kept? These are complex questions. But answering them is fundamentally important for reliable software. Ideally, this security and threat model is available in the form of a published document and users and customers can view and discuss it before making a purchase decision.
The software development is then about following the model on an architectural and technical level. There is often a catalog of requirements for the programmers. After all, they need to know which direction to work in, even if they do not know all the details of the security and threat model.
Then it’s up to quality assurance. First by internal and then external tests – a task for penetration testers, auditors, appraisers, and often university research groups as well. These are often based on the security and threat model. Otherwise, they run the risk of overlooking important risks – or complaining about problems that aren’t really any at all. Of course, the creativity of the testers remains important. A true attacker also rarely adheres to the rule book.
Which parts of a messenger do you analyze?
As many as possible. The test team needs as much insight as possible to estimate the attack surface. This usually includes the messenger clients as well as the message log. Then of course the team has to examine the servers and their applications. In short, all parts of the software architecture that could potentially be exposed to an attacker’s input need to be tested. From the security and threat model, it is often possible to deduce exactly where investigations must take place.
Modern and complex software often also uses third-party libraries, open-source components, and other externally-created tools. Again, the testers have to check for security vulnerabilities. Because software can be programmed so securely that a mistake in the third-party library can destroy everything.
It is important that the tests take place regularly and as needed. Software is usually a product that is subject to constant change. After significant modifications, a test must always be performed on the affected parts. The publication situation and the threat situation are also changing. This must be kept in mind by both the test teams and auditors. Software that is still considered secure today can be vulnerable tomorrow. To avoid operational blindness, changing teams should conduct regular inspections.
What did you investigate at SIMSme Business?
In this case we examined all security-related components and placed special focus on the mobile applications, the web client, the protocol itself, and the server-side components. The individual parts were completely available to us, we were able to examine the system in its entirety and cover the usual applications through our tests.
What kind of attacks do you simulate in a test: man-in-the-middle attacks or similar?
We focus less on a list of predefined attacks than on different attacker models. Then we form an overview of plausible attacks and test the application. On the one hand, we comply with existing standards, but we do not limit ourselves to them. Instead, we look at the application in its context and consider how we can carry out individualized attacks specifically tailored to the use cases and peculiarities of the software.
For example, when it comes to individual attacks, we inspected the message format and examined it for less obvious or undocumented features. Among other things, this was done in the web client using state-of-the-art debugger technologies, specially configured emulators for the mobile clients, and scanning tools for servers and domains.
What are the results of your investigations for SIMSme Business?
The test results of SIMSme Business are pretty good. We’ve done half a dozen test runs now. The number of findings decreased from test to test and in particular in the last rounds, the team had to work hard to report anything worth mentioning. In our estimation, the security level of SIMSme Business is above average. Security is actually understood in the design and development process of the messenger and SIMSme Business is on a very good path with regard to security – as you know, you never reach the goal with IT security.
Dr.-Ing. Mario Heiderich
The IT security expert was, among others, Security Researcher for Microsoft and is the founder and CEO of Cure53. The Berlin-based company specializes in penetration testing for online solutions as well as security analysis and investigation of malware. Cure53 consults on security aspects of IT architectures and crisis response after an IT attack. Since 2011, Cure53 has been conducting penetration tests for various IT solutions from Deutsche Post AG.