Secure by Design: A Case Study

But first if you need quick refresher as to the fate of the Death Star

This is where the problems in design started to go wrong, the small thermal exhaust port. A weapon capable of obliterating a plant is bound to produce a lot of residual heat as a by-product. And that heat needs to be vented; otherwise, you have an army of sweaty henchmen in white plastic armour queueing non-stop for the 4 available showers. To solve the problem, engineers put in an exhaust port that was only two meters wide on a space station that has a surface area of 80 million m². Quite an impressive feat of efficiency! But this is a pretty sensitive part of the infrastructure, after all it leads directly to the power plant. If something goes wrong here, KABOOM! But it is tempting to rationalise the danger away, ​“It is a tiny little hole in a gigantic space station, no one will ever find it, so we don’t need to worry about it.”

Secure by design thinking would start with the requirement that your system should be properly protected even if the intimate details of its construction are public.

The same principle applies to building a messenger app like Siilo. Our app is available to the public for download. That means it is open for scrutiny from potentially anyone with tools commonly used by cyber security experts: static code analysers, reverse compilers, debuggers, web proxies, and many others. A design must be able to withstand this scrutiny because the app is exposed to the world. One of the many mechanisms used by Siilo to achieve this is that we do not rely on secret information such as a master key which is included in the application, a so called factory password. The pin code which a Siilo user defines is used as input to a https://​en​.wikipedia​.org/​w​i​k​i​/​K​e​y​_​d​e​r​i​v​a​t​i​o​n​_​f​u​n​ction This generates a unique secret which cannot be discovered by analysing the application itself (because the key came from you) and it also ensure that even us (Siilo’s engineering team) cannot use a built-in secret to access your data.

The next flaw that contributed to this station’s demise stems from its policy on door locks as evidenced by ease by which Luke Skywalker (Mark Hamel) and Han Solo (Harrison Ford) were able to wander around the station in their attempt to rescue the princess. Only after they have initiated a firefight as part of their jail break are doors lock and start to require security codes.

Secure by design is secure by default.

If a configuration setting has choices the default one should be secure. The Death Star is a military installation during a time of war, all doors on board should lock automatically, not only when the alarm is sounded. A good example of this in the Siilo Messenger is the camera option on Android. Many Android devices come with Dropbox syncing software which makes a copy of all photographs the user takes with the system’s camera and uploads them to make sharing them easier. In the case of the typical user that is a nice convenience, but not for doctors who need to protect their patient’s privacy. Because detecting the presence of these types of services is difficult and sometimes downright impossible we built an alternative camera where we can control the output and prevent copies from being made. And this custom camera is on by default so as to provide the most secure option out of the box. If we did not do this then it is highly likely that a user with one of the ​“auto-syncing” camera would be unknowingly spreading their data until they discovered the existence of this feature.

Another messenger which markets itself to healthcare workers has two modes for messaging: one uses end-to-end encryption and offers a strong security stance. But this same app also has another mechanism for sending messages which relies solely on transport layer security.

Messages sent via the second means can be read not only by the intended recipient, but also the app provider and any attacker that is capable of executing a man-in-the-middle attack. Further exacerbating this is the decision to make the less secure method the default for most chats. This pushes the burden onto the user to understand the application and alter their behaviour based on whether their communication is being sent under the more most secure mode or not. It is far too easy to mention something sensitive by accident during the normal flow of conversation.

Siilo is built with the notion that all messages should be treated as highly confidential and thus remove the burden from the user of understanding what uses of the app are protected and which are not. Secure by design is primarily an attitude of minimising assumptions. Both about a would hacker as well as the manner in which your users will engage with your application. Both parties will surprise and astonish you with their perspective, so it is best to be prepared. This philosophy does make building certain aspects of Siilo more challenging, such as our web messenger (https://​web​.siilo​.com). But it also better adheres to the rules set out by the GDPR as well as the spirit of healthcare guidelines pertaining to patient confidentiality.

Cheers,

Keith, Siilo Architect