Sunday, June 28, 2015

Guide for building an Encryption Policy: Encryption Implementations - part 3

16th century French cypher machine
As you can see in the image above, encryption means nothing if you don't actually implement it. The French cypher machine in the shape of a book dates from the 16th century and was owned by King Henri II which implemented a version of cryptography (Wikipedia source).

But what are the common practices today? In the first two blog-posts I have set out a baseline for the policies concerning hashing and encryption. I have described the various algorithms and stated which ones should be used and which ones shouldn't.

In this part I will look at the variety of different implementations and I will focus on the ones that are common today (and hopefully tomorrow).

The series of posts are divided over the following topics.

Encryption mapped on OSI-model

First I want to take a look in which phases of a data in transit and at rest encryption can takes place. This is important to know, but yet often overlooked. Management pressure often beholds comments like: "we need to do encryption" or "encrypt every network connection". The truth is that most likely your network is a complex network and applying encryption technique is nowhere as easy as like your management stating that you have to implement it.

For the purpose of this post I created a model that gives an overview on which places encryption can take place and in what form. After this model I will briefly explain the variety of options shown in the image. For the record, the image is released under the Creative Commons Attribution-NoDerivatives 4.0 International License, so please share it in every way you like.

Model of Encryption techniques in context to data in transit, in process and at rest
Model of Encryption techniques in context to data in transit, in process and at rest
Data has 3 stages it can be in. It can be in transit between two information systems, it can be in process within an information system and it can be stored (at rest) in an information system. All three stages have a different approach towards encryption. I will talk about the different stages of data from the OSI-model perspective.

If you want to know more about the OSI-model, click here. In the model above I have added three additional layers (after a debate with a colleague of mine) to the OSI-stack. Those are layer 8 Message, layer 9 Transaction and layer 10 Process. These layers represent the layers that are needed to actually submit a message to the Application layer. A process can contain multiple transactions, and a transaction can contain multiple messages.

A message is the actual data itself. Although (meta-)data in and of the transaction and process layer can be sensitive too. In this post I will focus on the actual message that is going to be transmitted to another node.

Data in Transit

Encryption of data in transit happens on the 3rd, 5th, 6th and 7th layer of the OSI-model. Where as layer 3 is information system independent (at least, it should be), layer 5 through 7 are more depended on what mechanism is chosen in the application layer. Important here is to know that they are different.

When applying IPSec for IPv4 or IPv6 in your network configuration you will encrypt the payload of every IP-packet. The header of every IP-packet is, for obvious reasons of delivery of the payload, not encrypted. There are also two modus of operandi here. One is host-to-host and the other one is gateway-to-gateway. I tend to say to go for host-to-host whenever possible as the route of encryption is the longest there. IPSec secures your data against unauthorized access on the wire. But anyone that is authorized to the network can see the data (makes sense I guess).

Transport Layer Security (TLS) is probably the best known protocol to encrypt data on the wire. It takes residence in the presentation and application layer. It is used in HTTP connections (the best known are the web-browsers), known as HTTPS and it is used for FTPS. Do not mistake this with sFTP which uses Secure Shell (SSH) to encrypt the data. SSH has some weaknesses prior to version 2. Secure Socket Layer (SSL) and every version of it is considered insecure, just as TLS 1.0 and 1.1 are. Do not use those protocols anymore!

In summary, TLS version 1.2 and SSH version 2 are safe to use. Therefore, HTTPS, FTPS and sFTP and other protocols based on TLS and SSH are also safe to use.

There is also the phenomenon of VPN (Virtual Private Network) Tunneling on layer 2, 3 and 7. In general every VPN tunnel is insecure when additional security measures are not taken. If you do not trust the underlying network of the VPN tunnel (for instance, the Internet), then you will have to take security measures in the VPN tunnel itself. These measures can be protocols like IPSec in conjunction to Layer 2 Tunneling Protocol (L2TP) or the use of TLS and SSH.

Data in Process

Data in process is the data that is processed by the information system (or business application if you like). It is everything between data-at-rest and data-in-transit. As far as I can see, there is hardly any configurable encryption in this stage. Although it is possible that when the information system reads the data it also encrypts it in memory.

Although this approach seems to me highly CPU and memory intensive and I doubt its usefulness for common business-practices here. And it is something the developers of such an application or the operating system it runs on needs to implement.

Data at Rest

Data at rest has a filesystem centric approach towards encryption, and a data centric approach. Let's start with the first one.

Filesystem centric approach is not about the data itself, but the storage it is stored in. It is about encrypting disks, partitions and volumes (that span multiple disks or partitions). It is also about an encrypted file in which the actual data is stored in the form of files and folders. And also your temporary files in the hibernation and swap space (pagefile) can be encrypted. These last two are especially important if you want to secure your environment for forensic analyses.

The data-centric approach is the encryption of the data itself. Storing passwords is probably the most common known variant of it. But it is also possible to encrypt entire databases or specific records and/or attributes in a database. The focus here is the data it self, and not the filesystem it is stored on.

There are tons of examples for implementation here to choose from. There is an extensive list of disk encryption software on Wikipedia. When selecting your tool for the job, consider your policy towards hashing and encryption. There might be also other corporate policies that state whether you should or should not use open source tools. There is no right or wrong here, other then it is not wise to use software which uses outdated algorithms.

Implementation and testing

Do not ever trust an implementation without testing. TLS, SSH, IPSec, and the others might be secure by itself, but these algorithms and protocols are implemented by software (and hardware in some cases). And software implementations might have (or probably have) weaknesses also.

Therefore, always perform proper testing before and after implementation and keep testing it at regular intervals as new vulnerabilities might be discovered and exploited.


I hope I gave a clear view on the variety of implementations of encryption algorithms without either going to deep or staying to shallow on this topic. In the last blog-post in this series I will summary all three other posts into one policy on how you can handle your encryption and hashing practices.

Did you see anything incorrect, or do you disagree for other reasons? Or do you want to share how you handle topics such as these? Please share your thoughts and opinions in the comments below.

This post has the tag: update, meaning it will be updated when new information becomes available and/or relevant.

Saturday, June 20, 2015

Guide for building an Encryption Policy: Encryption Algorithms - part 2

In part one of this blog-series we talked about hashing. This part is all about encryption. I will talk about what encryption is so the general concept is known, but then I will move on to a summarized encryption policy.

The series of posts are divided over the following topics.

Encryption versus Hashing

Encryption is, unlike hashing, an algorithm that has a two-way street. You can actually decrypt your message (or file, or whatever you want to encrypt). Encryption does not have a hash like hashing does, so it does not guarantee integrity of your data. It does protect the confidentiality of the message though. Please do keep this in mind. If you want to have confidentiality of your data and you want to safeguard the data's integrity, you will need to use hashing in conjunction with encryption.

But that is not all. Besides confidentiality encryption can also secure its non-repudiation. Non-repudiation is the fact that a party cannot deny that it has executed an activity. This can be very important to increase your audit and logging data to forensics level. But non-repudiation does not come by itself, you have to do something for it which I will explain later.

An overview on Encryption

Encryption can be symmetric and asymmetric. Symmetric encryption can be based on either stream-ciphers, or block-ciphers. Asymmetric encryption is either based on discreet logarithms or based on factoring the products of large primes. See the figure below which displays this schematically.

Cryptographic Systems (CC)

Symmetric Encryption

Symmetric key algorithms use the same key in both encryption and decryption process. This technique provides confidentiality. It does not provide non-repudiation.


Stream-ciphers are based on generating an infinite cryptographic key-stream and it encrypts a bit or a byte at a time. Stream-ciphers is used when the amount of data that is being sent is unknown.

Algorithms (excluding niche variants, patented and specific use algorithms) that are stream-ciphers:
According to current standards (dated April 4th, 2016) are as follows.
  • Deemed insecure*:
    • RC4, Salsa20
  • Deemed secure, but uncommon:
    • HC-128, HC-256, Rabbit
  • Deemed secure and common:
    • ChaCha20
ChaCha20, HC, and Rabbit can have a variety of key lengths.
  • 128 and 256-bit
Full list of stream-ciphers can be found on Wikipedia.


Block-ciphers are roughly the same as stream-ciphers, but instead of using bits or bytes to encrypt it uses blocks of data. This is best used in situations where the amount of data to send is pre-known. There are multiple modes of block operations (to which I won't go in detail), but you can see the differentiation below.
Algorithms (excluding niche variants, patented and specific use algorithms) that are block-ciphers:
According to current standards (dated April 4th, 2016) the situation is as follows.
  • Deemed insecure*:
    • BlowFish, DES, MacGuffin, RC5, ThreeFish, Triple DES
  • Deemed secure, but uncommon:
    • CAST-128, CAST-256, RC6
  • Deemed secure and common:
    • AES, TwoFish
AES, CAST, RC6, and TwoFish can have a variety of key lengths.
  • 128, 192 and 256-bit
In any case, I would advice to go for the maximum here (whenever possible), which would be 256-bit. Although 192-bit should be enough also for the foreseeable future.

Full list of block-ciphers can be found on Wikipedia.

Asymmetric Encryption

Asymmetric has some form of a key-exchange with such a result that a different key is used to encrypt and decrypt a message. This technique provides confidentiality and non-repudiation. Confidentiality is provided when the sender uses the receiver's public key to encrypt the message. Non-repudiation is provided when the sender's private key is used to encrypt a message. If you need both confidentiality and non-repudiation the sender needs to double-encrypt the message with the private key of the sender and the public key of the receiver.

Key Agreement

Asymmetric uses a key agreement protocol to exchange the public keys between the sender and receiver of a message. There are a variety of key agreement protocols.
The most generally used protocol is the Diffie-Hellman Key Exchange protocol.


According to current standards (dated April 4th, 2016) the situation is as follows.
  • Deemed insecure*:
    • ECC, ElGamal, RSA (1024-bit)
  • Deemed secure, but uncommon:
    • RSA (3072-bit)
  • Deemed secure and common:
    • RSA (2048-bit)
RSA can have a variety of key lengths.
  • 1024-bit (equivalent to 80-bit symmetric keys)
  • 2048-bit (equivalent to 128-bit symmetric keys)
  • 3072-bit (equivalent to 256-bit symmetric keys)
In any case, I would advice to go at least for the 2048-bit variant of RSA. RSA with 1024-bit key should be prohibited and with sensitive data the key should be 3072-bit.

The Security Policy should be...

  • Symmetric Encryption
    • Stream-ciphers
      • None (due to patenting).
    • Block-ciphers
      • AES: at least 192-bit key-size, but preferably 256-bit
      • TwoFish: at least 192-bit key-size, but preferably 256-bit
  • Asymmetric Encryption
    • Key Agreement: Diffie-Hellman
    • Algorithm: RSA, at least 2048-bit key-size, but preferably 3072-bit.


It has become quite a post, although in the end the policy is relatively small. In the next posts I will talk about some implementation guidelines of Encryption in the next post. In the last post a will gave a proper summary of everything I will discuss in all posts in a readable view.

What is your point-of-view on this topic? Do you see any errors or do you have any questions? Please do comment and let's learn from each other!

*) Insecure can mean totally insecure, or 'only' when certain terms are met that the algorithm gets insecure. It can also just be a theoretically insecurity rather than a practical one. The main message here: if you want or need to use this algorithm proceed with extra caution and testing.

This post has the tag: update, meaning it will be updated when new information becomes available and/or relevant.

Thursday, June 18, 2015

Why do I use .eu as TLD for my blog?

Thinking about which Top-Level Domain (TLD) you use for your blog, personal- or company-website is very important. On one side you have the obvious reasons like the market you want to reach and the language you will use on your site. If you are aiming for your own country, you will probably settle for TLDs like .us, .nl, .uk, .de, et cetera. But if you target internationally (or multiple countries) you might also consider TLDs like .com, .net and .org.

Then there is also the fact that you might want to secure future TLDs by claiming them, just in case you want to expand to other countries or go international altogether. In essence, the perspective here is mostly business and its current and future business plans.

But did you consider the ability of seizuring domains by governments? Because this might seriously disrupt your business.

Top Level Domains and U.S. control

Wikipedia has an extensive list of Top-Level Domains and for the obvious reasons I am not going to repeat them here (Wikipedia does a way better job there). But lets take a look at the following list with the best known TLDs.
  • .com
  • .org
  • .net
  • .int
  • .edu
  • .gov
  • .mil
The TLDs .int is reserved for situations like international treaties. And the TLDs .edu, .gov and .mil are explicitly reserved for U.S. organisations (like military, governments and universities). The remaining TLDs .com, .org and .net are for commercial and organisational use and are also available to the rest of the world.

But all these TLDs are under the control and jurisdiction of the United States and therefore the U.S. has to power to seize any domain-name associated to it at once, sometimes without a court-order and without any damages being compensated for to the 'owner'.

So, if your hosting is for instance in Germany and you have a .com TLD, your site can be taken down by the U.S. for (probably in your opinion) no good reason. Your website would still be available under its IP-address or one of your other domain-names, but the specific domain would be offline (likely forever).

There is an extensive article on (Uncle Sam: If It Ends in .Com, It's Seizable) which describes this ability of the U.S. in more detail with examples.

The fact a .com, .org and .net address can be seized by another government than my own is one reason that I did not choose for one of those three. The same applies to TLDs from other countries. Germany has control over .de, Belgium over .be, et cetera. The Dutch law also does not apply there. This is the way this is designed.

But why not the TLD .nl?

You might question now why I did not choose .nl (from The Netherlands, the country where I live). The very reason for this is the fact that my potential reach of visitors would be limited mostly to The Netherlands. I could ignore this fact and just put out English blogs on it. But ask yourself, how often do you visit a .nl domain? Or a .de? Or a .us? I hardly visit the last two for instance for (probably) no specific good reason other then the market the website is serving.

So, I cannot choose from the three public TLDs and I cannot choose for TLDs related to specific countries if I do not want other countries seizing my domain-name. I also cannot choose my own country's TLD because I don't want to bind myself to a specific country and 'exclude' all the rest of the world.

And this is where .eu comes in...

The TLD .eu is one of the few that is not bound to a country but to a supranational organisation (.nato is for instance the other one, teusink.nato probably would not happen -- frowny face here). It is international, it is under control of a government that is represented by my government and the EU law applies here. Whereas my own country's TLD is focused on domestic websites, .EU tends to be focused to and for entities in the EU, but also internationally.

And it cannot be seized by any other government, without taking the appropriate legal steps in the EU.

But what about hosting?

I have chosen on purpose a Dutch hosting provider (could be any EU hosting provider b.t.w., but why not support my own economy?). So my hosting and DNS would be Dutch and would therefore fall under Dutch law and procedures.

But what about Blogger?

And here is the one disadvantage of all considering my blog. I use many Google products (I did read the privacy and security policies of Google by the way), and Blogger is one of them. I know it is an American service and that it is most likely hosted outside the EU. I know I do not have any legal protection from my government here.

It would be a sad day if this blog would be put down by the U.S. (or Google, it is a free service after all). But that is not as harsh for me as losing my domain-name, to which I tie my identity more than a blog hosting provider.

I could build my own blogging solution of course, but I lack time to keep patching it and I am not confident enough at present moment to outsource such a (i.m.o. delicate) job to a company inside the EU. Wordpress, for instance, has also a Cloud option so they do the heavy lifting of maintenance. But it would also be a non-EU based company and then Blogger would do the job just fine for now.

Was this thought process really worth it?

In regard to my own blog, likely not (although I really really wanted a .eu for the reasons of a international oriented domain-name that is under control of the EU or my own country). It was a nice thought exercise about this topic though. I believe I can better help businesses now on questions such as these.

Have you ever thought of this? Would you make a different choice now, or are you happy the way things are now? There is no right or wrong here, there are choices and consequences. Nothing more.

Thank you for your time to read this and feel free to drop a comment! I would appreciate it and I certainly will respond to it.

Monday, June 15, 2015

Guide for building an Encryption Policy: Hashing Algorithms - part 1

Are you a Security Officer and familiar with the question what is the baseline or policy for encryption? Or are you an engineer who has asked that very question? Or are you a power user that wants to learn more about setting up an encryption policy? As an IT Security Officer I have faced a similar question in the past, and I will try to answer it in this serie of blog-posts. Keep in mind that I talk mostly about the what here, not the how.

I have searched online allot about this topic and I hope I curated the right bits of information. Have to say, good encryption books are expensive and its content are mostly very detailed. Besides that, it is still a rather complex topic to deal with because it has many angles to approach it. In any case, always consider the protection of data first, before jumping to a solution like encryption. There are more ways to safeguard data and encryption just might not solve the actual problem you need to solve.

And be aware, an algorithm can be 100% secure, while the implementation of the algorithm can make it incredibly vulnerable. When choosing an implementation consider the fact that it can be weak and that it needs to be tested thoroughly.

The series of posts are divided over the following topics.

General approach to Encryption

Applying encryption gets cheaper, but it is still not always free and often not the default. You will have to think about why you want to apply encryption, where you want to apply it and how long the data needs to be secret. If it needs to be secret for 1 day it might actually be smart to choose an algorithm that is more easy on the CPU-cycles. But if it needs to be secret for 10 years you might make a different choice altogether.

There is also the Kerckhoffs's principle. This principle basically says that the security of an encrypted message is not based on the secrecy of the algorithm, but on the secrecy of the key and the key only. This is important. All common algorithms follow this principle and it is key that this is the policy. Only publicly tested, open algorithms that follow the Kerckhoffs's principle should be used. Due to this principle, I left out all encryption algorithms that are patented.

When you look at the variety of encryption and hashing algorithms you honestly do not have that many choices. Yes, you can choose a variety of key-lengths and in some cases a different encryption level and some other settings like block-modes. But I tend to say that creating too much diversity in your own ecosystem just makes encryption more expensive administratively speaking, than when you choose a certain baseline. And don't forget you need to test every option you choose.

The General Policy should be...

  • All chosen algorithms are open and publically known for its security.
  • All chosen algorithms need comply to the Kerckhoff's principle.
  • An algorithm should not be chosen when it is either theoretically or practically compromised/cracked.
  • The chosen algorithm should be sufficient enough to keep the data secret, for as long as it needs to be secret.
  • Always follow the principle of "comply or explain". When it is not technically possible to use a better encryption or hashing, you might downgrade. But do this wisely with proper Risk Management and testing.

An overview on Hashing

Hashing is a way to 'fingerprint' a message. A message can literally be a message, but it can also be, for instance, a file. This fingerprint is a string of characters and numbers. Example: 77c5b98cd533621c15d996723999d19d6c09513f54fddd2d1bdb32c08b6307b6 is the fingerprint for The fingerprint is normally called a hash. This hash is unique to, in this case, If I would generate a hash of (mind the capital T here), then it would generate a different hash. You can test it out on the webpage of David Ciamarro (

In other words, with hashing you can check if your message is sent or received intact. It checks the integrity of the data. And that is all that it does. It is not an encryption, and a hash cannot be unhashed. It is always a one-way street. You can never return from the fingerprint back to its original message.

The different algorithms

There are a variety of different hashing-algorithms out in the open. The ones below are the most well-known (excluding niche variants).
According to current standards (dated April 4th, 2016) the situation is as follows.
  • Deemed insecure*:
    • MD2, MD4, MD5, MD6 and SHA-1
  • Deemed secure, but uncommon:
    • BLAKE, BLAKE2, RIPEMD-160, RIPEMD-256, RIPEMD-320 and SHA-3
  • Deemed secure and common:
    • SHA-2
SHA-2 has a variety of configurations. Three configurations are the most relevant concerning the quality of security of the hash. Those are as follow.
  • Block size: at least 512-bit, but preferably 1024-bit or higher
  • Output size: at least 256-bit (SHA-256), but preferably 384-bit (SHA-384) or higher


The phrase salting is commonly used in conjunction with hashing. Although hashing is often used without salting, it is extremely advised to be used when it comes down to storing passwords or pass-phrases. Salting is the process of adding random data to a message you want to hash (in this case, the password). Salting makes it allot tougher to use crack tools to either guess or crack hashes, because it appends unpredictable data to a hash before it is stored in a database or in a file.

The best practices to use with salting is the fact that every salt is unique, randomized and that it is not being reused. And the salt itself should not be too short. A good method to follow here is that when the output size of a hash is 256-bit, which is 32 bytes, you need a salt of 32 bytes. And the last bit is not to double hashing or use multiple hashes. Proper salting with an up to date algorithm is secure enough.

For allot of details about salting and hashing passwords, please check this blog-post Secure Salted Password Hashing, by Defuse Security.

The Hashing Policy should be...

  • Hashing algorithm: SHA-2.
    • Block size: at least 512-bit, but preferably 1024-bit or higher.
    • Output size: at least 256-bit, but preferably 512-bit or higher.
    • Security: at least 128-bit, but preferably 256-bit or higher.
  • Salt a message before hashing when used to store passwords / passphrases.
    • Every salt is unique, randomized and not reused anywhere else.
    • Every salt is as long as the output size in bytes of a hash of the message.
  • Only use one hashing technique for one message.


That is about it when talking about the General Policy and Hashing Policy. In the next posts I will talk about Encryption and a couple of common implementations of Encryption. In the last post a will gave a proper summary of everything I will discuss in all posts in a readable view.

What is your point-of-view on this topic? Do you see any errors or do you have any questions? Please do comment and let's learn from each other!

*) Insecure can mean totally insecure, or 'only' when certain terms are met that the algorithm gets insecure. It can also just be a theoretically insecurity rather than a practical one. The main message here: if you want or need to use this algorithm proceed with extra caution and testing.

This post has the tag: update, meaning it will be updated when new information becomes available and/or relevant.

Saturday, June 13, 2015

Technology will 'disappear' in the future

Whereas I am a very technology minded person, my wife is kind of the opposite. If it were up to her, we would go back to horseback riding and carriages. Obviously light will come from candles (which is way more cozy) and life will be less fast as it is today.

I always say than that technology will become very different then it is now. People won't stare at their phones anymore and no annoying humans that take pictures with a full size tablet computer. Screens will be practically gone and everything will be maximum automated and interacting with computers will be taken to a whole next level.

Technology as we know it, will 'disappear' in the future.

Start of a common day in 2045

You wake up in the morning without pressing your alarm snooze button, because there is no more need for that. While scratching your head you head for the shower. When you walk in the shower it switches on and it is already exactly the temperature you like. When done you do what you normally would do and head towards your kitchen. Your coffee or tea is ready and you make your breakfast. The fridge sends you a notification that you are running out of milk and that it has ordered a new supply from the grocery store.

There is no need to check for the weather or traffic jams. The umbrella handle is not glowing red, meaning it will not rain when you are gone, and traffic jams is something that was normal 20 years ago. You stretch out, finish your breakfast, take your coat and step outside.

When outside you see that your automated car has arrived and step in. It recognizes you, sees your calendar and automatically knows you need to head to your office. You lean back, close your eyes and start working. While you are being driven you receive a phone call. It is your spouse and you decide that you will answer your phone. The second after this thought the call is answered.

You have arrived at your office and you are stepping out of the car. The car is driving itself to either its next customer or charging unit. You walk in and are heading towards your meeting. It is an international company and you are having a conference call (well, that's how people used to call in back in the 10's) with colleagues all over the world.

In the meeting room there are no screens, no microphones and no speakers, well, as we knew them in the past anyways. Everyone is greeting each other and the first callers are starting to join in. They appear in the augmented reality of each other and the meeting starts. Everything that is being sad is transmitted from each individual to every other one, also to the people not physically in the room.

After a long session you do some 'paper' work while relaxing in the sun and head home early.

How realistic is this story?

There are a couple of visionaries that state that this could really be the future. I always say, the coming 5 years will change as much as it did in the past 10 years. That is called the The Law of Exponential Growth / Accelerating Returns (the link is a long read).

In 2014 Google announced that they will launch a smart contact lens that can measure your blood sugar levels and controls your medical devices accordingly. It powers itself from static electricity on your eye. But it gets way more interesting when you look at the news-post in which scientists explain how to implement nano-devices in the brains of mice. When done, they can influence the electrical currents (neurons) that flow inside the brain of the mouse. And this is just 2015. Imagine that every two years these kinds of technology get better exponentially. Every two years the technology is twice as powerful and reduced in size significantly.

The 'disappearance' of technology

If microchips do get twice as powerful each year, if technology can shrink to blood-cell level, and if the world is getting ever more interconnected, yes, then I do believe that such a story as above will become reality. Technology will become so small and so integrated in our lives that you can hardly see it. It will become even more an extension of ourselves, than it is already today.

Communicating through your mind with other people on the Internet. Sensing each others senses and hearing each others voices can be achieved. Perhaps our consciousness someday will merge in some sort of a Khala.

We will see what will happen, it is hard to predict how the world will change when these types of tech will come to market. But the most important question is: are you ready to change if needed?

Tuesday, June 9, 2015

Is the 2 crew-members policy after Germanwings air-crash really effective?

Most aviation authorities have implemented the new policy that there must be at least two crew-members (one of which is at least a pilot) in the cockpit at all times from now on. The reason for this new policy is the Germanwings air-crash on March the 24th of 2015. Is this policy effective in regard to the cause of the crash? I believe it is not, although I believe that the policy might work in a different situation. In this blogpost I will explain from a risk management perspective why I take this point-of-view.

Little disclaimer here; I am no aviations expert, nor do I claim to be. But I do know the Risk Management methodology and based on the information known to the public I look at this specific topic.

First things first...

I was horrified when I heard the news about this crash and even more when I heard what caused the crash. The fact that 150 lost their lives in the crash because one of them felt no other escape in life than to end his during the flight made me feel sad. Sad for the victims, and sad for the people that cared for them.

This topic is still rather new and is even, at the time of this writing, under investigation. I write this blogpost with the sorrow that the bereaved ones must feel in my mind and heart. If you are one of them, I wish you strength and I hope you will find your peace in the times ahead.

The facts known today

In short these are the facts in regard to the actual crash itself.
  • The co-pilot suffered from mental illness and his doctor stated that he was not fit for work.
  • There was no loop-back of the doctor's decision to the employer of the co-pilot due to the German law. Neither on the initiatives by the doctor, the co-pilot and the employer the medical diagnosis was asked for or shared.
  • The captain had left the cockpit and then the co-pilot locked the door from the inside.
  • The captain could not override the lock with the secret PIN, because the co-pilot disabled that too.
  • The door could not be opened with force as designed due to the 9-11 events after which these types of doors are mandatory. I find it a bit harsh knowing that a plane went down because of a control to prevent terrorism.
The source that explains the crash in detail can be found on Wikipedia Germanwings Flight 9525. For this blogpost of mine, the statements above are the most relevant from a risk management perspective.

I will continue to follow this topic and update the blogpost when needed.

The "solution"

The solution that has been implemented through a policy is the fact that at all times there needs to be at least two crew-members in the cockpit. And one of them also needs to be a pilot. The general thought here is that having a second member in the cockpit is preventing the fact that a pilot can become a danger to the airplane and its passenger by locking the door and taking over control. But if someone really wants to down a plane, is this control really effective? I think it is not that hard to take out the other crew-member first, before starting with whatever such a person plans to do.

Is it useless that a crew-member is present in the cockpit when one of the pilots leave for a second? Certainly not, because the other pilot might become unwell and thus the collegeau can warn the rest of the staff. On the other hand, how likely is it that the person outside of the door cannot unlock the door with the PIN in such a situation? I think not likely, because there is no incentive for the other pilot to block the PIN code right before becoming unwell. Nonetheless, the policy might prevent an unfortunate accident.

Probably the main reason might be the fact that the aviation industry wanted to restore the trust in their pilots by doing at least something. Truth to say, of the somethings that can be done, this something is at least not invasive for anyone.

A solution

I believe that a solution to prevent air-crashes like these are not to be taken inside the plane, but rather outside of the plane. The investigators have found a doctor's letter stating that the co-pilot was not fit (mentally) to fly. It is important to know that it is forbidden by German law for employers to obligate personal staff to share such medical information. And the main reason here is privacy.

I can understand that people should not be obligated to share any medical data with their employers. It might have negative trade-offs for personnel that suffer from a difficult time in their lives. But as with many things in life, I think that there is a 'but' here. A statement of a doctor about your ability to work is something different then a statement of a doctor about your ability to work and why.

The real solution here is that we should debate that for critical jobs like pilots at least a "fit to work" statement should be given by a doctor. Especially when you called in sick because of life changing events that can leave their scars. The why of the "not fit to work" is not relevant to an air-plane company, but the fact that a pilot can fly or should not can fly is. And implementing some regulations about job security for a pilot after a temporary "not fit to work" is an important control. The reason for this is to lessen the negative trade-off for personnel with such a solution. It encourages pilots to be honest, it enables employer to help their staff, it enhances air-safety and restores trust wherever it's needed.

In summary

The following can be said in summary concerning threats and their treatments.
  • The locked door: helps to prevent intruders entering the cockpit.
  • The PIN to open a locked door: helps to prevent a pilot of becoming locked out.
  • The blocked PIN to open a locked door: So the pilot in the cockpit can lock the door when the PIN has been compromised.
  • The second crew-member in the cockpit: can aid when assistance is needed when a pilot becomes unwell.
  • Sharing "fit to fly" statement from a doctor: helps to determine if a pilot should work or not.
Keep in mind that no solution can guarantee safety for the full 100%. Safety and security are no absolute values.

Thank you for your time to read my blog! What do you think about this topic? If you want to share your thoughts, please do so.

Sunday, June 7, 2015

The chilling effect in a sauna...

Receiving a chilling effect in a 80 degrees somewhat sauna, is that possible? Well, that depends totally on your perspective. If you think temperature wise, you probably won't receive a nasty cold chill. But when you think about a Peeping Tom sitting right next to you might just change your mind.

The reason I talk about privacy in context of a sauna is because of my wife told me a story recently. She went to a sauna, enjoyed her time there, but was bothered with a man looking at her. Thankfully nothing out of the ordinary happened and she enjoyed her evening, although she came home early.

The very fact that my wife was bothered with a man looking at her, in a sauna, seems strange at first. People look at each other in a sauna, right? But when you think about it, it actually isn't. It is even fundamental to the core of us being human and the non-written rules that apply to society every day. Let me take you through some thoughts of mine about this topic.

What is 'nakedness'?

In case of the sauna the nakedness is as literal as it can be. But there are other ways you can be very naked. Think about your doctor's appointment, when you get a massage, when you are screened by your employer, or when you try to get a positive financial status. There are more examples of course, but the point is that someone other than you is able to see more of you than that normally would apply in other situations.

It is very important that the one that is being 'naked' feels secure. And the more 'naked' you are, the more you need to feel secure. I will get back to that later.

Seeing versus Observing

So there is seeing, looking, and observing. As with the man in the sauna, it is obvious that people in a sauna see each other. We might even look at each other. Most people are probably okay with that. But things start to get creepy when someone is observing (a.k.a. staring) at people. A non-written rule has been broken and thus we get the nasty chilling effect and shiver right out of the sauna. Well.... in some cases perhaps.

When does seeing ends and looking begins?

This is for the most part about control, relatively speaking. When you are laying in a hospital recovering from surgery you are being observed by the hospital staff. You most likely are nowhere near being bothered about that. That has to do with the sense of control. To the very least, you most likely did comply to the situation at hand or will do so when you have been recovered. I tend to say that hospital staff is not observing its patients, but it is looking after them with the help of machinery that gives them data to execute that task.

But when does looking after ends and observing begins?

You can be seen, or being looked after, or you can be observed. Observing in this context is different then the looking after of hospital staff. Observing is never in the interest of the one being observed. It is always in the interest of the one who is observing (this statement is stripped of nuance on purpose). In the case of the sauna, the man was observing my wife. He was not just seeing her and certainly was not looking after her (in her interest). The situation was not in her control and it was in a situation that she was more naked than she would have been in another situation.

Lets take, for the sake of the argument, that observing is fundamentally wrong. But why is it wrong and what does it trigger?

The Chilling Effect

When you are 'naked', you need to feel more secure and when you are being observed you will feel less secure. But not everyone feels the same when he or she is 'naked' and does not feels observed as quick as others. This is because we are all unique and experience the world different from one another. But what is the common ground here?

The common ground

If you feel 'naked', you will probably need to have control over the situation. The more control you have, the more secure you will feel. The more you are being observed, the less control you have. When you have less control than you feel you need, you will feel insecure. And that is the common ground that applies to everyone.

And chances are relatively high that when you feel to much insecurity, you will start to behave differently than you normally would. And that trigger is called the chilling effect. In the case of the sauna, my wife went to a different one and she got home earlier than usual. And thus my wife had the chilling effect in the sauna because she behaved differently that she normally would.

Privacy and Surveillance

I know observing is needed to make society more secure. Suspects are being observed (remind my statement here: not in the interest of the one being observed) for criminal activities. Therefore, I am not saying that surveillance in its whole is wrong, I am saying that mass-surveillance (observing groups of people) is fundamentally wrong. Targeted-surveillance (observing specific individuals) on the other hand is, with a legal justification and court order of course, justified and an effective measure to catch criminals and terrorists (again, only with a legal basis!).

Targeted-surveillance of a country's own populations should be done under the jurisdiction of the (federal) police and targeted-surveillance of foreign populations should be done under the jurisdiction of the intelligence agencies. We should even be very conservative about applying mass-surveillance to allied or even friendly states.

Mass-surveillance ultimately chills entire populations and what will happen next is just a history book away.


In my opinion, above is the reason why observing in the interest of the one that is observing is fundamentally wrong. It will trigger the chilling effect (eventually) of the one that is being observed. And thus it alters behavior of individuals or groups which leads to situations in which non of us will feel secure as described in books like '1984' and 'A brave new world'.

Let me end with a quote about privacy that sums it all up.

Privacy is more about control than it is about secrecy. Bruce Schneier, Schneier on Security (2008).

And now I am curious about what your thoughts on the subject are. Please feel free to share them so we can talk about it.