codesecurely.org

Mirror, mirror on the wall which is the securest of them all? Part Deux

The story so far … And now for more of the adventures of Jack Bauer! ;).

So since I posted the first of this series I have to come to realize a number of key things:

• There's seemingly people that agree with me at least partly that if nothing else "Securability" must be a first class player
• All this who is more secure than who doesn't always make sense
• The word securability is actually and surprisingly so not a word! (not if I have anything to do with it though J)
• Lastly but perhaps most importantly I got pointed to a very interesting read by my co-worker Roman Hustad and that's where we will start this post.

The OLPC (One Laptop Per Child) is an endeavor to provide (every?) child a laptop – each costing about a 100 bucks. Now this is an effort in itself involving hardware engineering to what operating system will run on the machine and so on. One of the things this team has taken up on to itself is building security into the system from the ground up. None of this patch work and design augmentation etc. I believe these guys really get it. While I did post my Securabilty post a week or so before I ran into this I must say I couldn't say it any better:

<quote>

To provide an example, consider the Solitaire game shipped with most versions of Microsoft Windows. This program needs:

* no network access whatsoever

* no ability to read the user's documents

* no ability to utilize the built-in camera or microphone

* no ability to look at, or modify, other programs

Yet if somehow compromised by an attacker, Solitaire is free to do whatever the attacker wishes, including:

* read, corrupt or delete the user's documents, spreadsheets, music, photos and any other files

* eavesdrop on the user via the camera or microphone

* replace the user's wallpaper

* access the user's website passwords

* infect other programs on the hard drive with a virus

* download files to the user's machine

* receive or send e-mail on behalf of the user

* play loud or embarrassing sounds on the speakers

The critical observation here is not that Solitaire should never have the ability to do any of the above (which it clearly shouldn't), but that its creators _know_ it should never do any of the above. It follows that if the system implemented a facility for Solitaire to indicate this at installation time, Solitaire could irreversibly shed various privileges the moment it's installed, which severely limits or simply destroys its usefulness to an attacker were it taken over.

</quote>

They go on to describe their threat model and cover how one by one they have attempted to mitigate the threats uncovered as part of this model. They warn you that this does not mean their system is going to be completely infallible – heck they have even considered what would and should happen in the event of failure. In many ways these smart folks stole my thunder – my follow on blog post was meant to be a case study on how to build a securable system folks – but I will gladly give it up since these guys have actually gone much further and built a real world system. Only time will tell if they will be successful but if I were a betting man I wouldn't bet against it.

So to recap then what are some of the key aspects for you to take away as you consider building securable systems:

1. Document your security requirements. Understand what it is that you are trying to protect. What is the attacker persona? Who are you up against? Bring back all of the The Art of War books you've read.
2. Use these security requirements to build a deep and detailed threat model – one that covers the requirements from above but also what the threats are to your system, what countermeasures you have (or will have) in place to prevent those threats from being realized and finally where are you vulnerable – what are those weak spots?
3. Use the threat model to govern your system development effort from a security perspective:
   1. Do the countermeasures you have or thought you had in place adequately protect you against the threats you thought they were going to protect you against? Have these been tested and exercised?
   2. How about the vulnerabilities you are left with? Have you made a conscious risk management decision to live with these vulnerabilities. What is the long term plan to deal with them? What happens if one of them get exploited? Do you have an incident management plan in place?
4. Plan for failure and hence engage in defensive design and development. One of those vulnerabilities above might come back to bite you or worse still an entire new class of vulnerabilities that we might have never considered before might suddenly be discovered and guess what you are vulnerable as hell – what happens next? This in turn comes down to a number of basic principles which are age old:
   1. Do you run with the least privileges needed to execute? Do you implement patterns such as privilege separation and compartmentalization?
   2. Even with least privileges do you explicitly turn off or refuse those you don't and will never need? Think Solitaire from the example above or iTunes (which should have access to my music folder and perhaps some registry keys at most! – more on that in a future post). If you run within the .NET environment do you run in partial trust, do you use features such as Security Transparency and RequestRefuse?, if you run as a Java application have you configured the security manager? If you are running on Unix are you creating a chroot jail? Are you setting your effective user ID to a low privileged user account and leaving all the high privileged stuff for the parent process?
   3. Have you tested your implementation and design against your threat model and security requirements? Does the "stuff" really work as expected? Have you looked through code to detect issues? Have you opened bugs for the stuff that doesn't work? Do you have a plan to fix those bugs?
   4. Will you fail securely if failure is inevitable? Have you even defined what failing securely means?
   5. Do you have the right amount of auditing and logging? Do you have an incident management and response plan in place? Has this planned been tested and proven to work or will get caught out when failure strikes the first time? Would you know whether to cut the red wire or the black one when something threatens to explode?

These last few bullet point is a good segway into the concept of Survivability.

<quote>

Survivability is the ability of a network computing system to provide essential services in the presence of attacks and failures, and recover full services in a timely manner.

</quote>

That's where the red and black wires come in – which are your most essential services? What can be turned off and the business will still survive? What does it mean to fail securely?

Finally, again the reason I believe this is important is because the true threats moving forward are not going to be to the web server running on your machine, they are going to be through the applications you use every day (think your email client, your word processor, your media player, your instant messaging client) to you and your identity, your social security number, your credit card information, your privacy! That's where I believe the OLPC folks have been truly innovative, have grabbed the opportunity and get it!