codesecurely.org : Security

Security Threat Level Down to Fuchsia?

rudolph — Sat, 07 Jul 2007 18:18:24 GMT

Last few trips I have flown I noticed the airlines (multiple) have started using metal silverware again – so metal knives etc? Did I miss some memo about the little knife on board not being a security threat no more? :P

P.S. Or did it dawn on the wise ones that seemingly make these rules that this security theatre was not really making anyone more secure?

Security Evolved

rudolph — Sat, 03 Mar 2007 22:50:12 GMT

It is interesting to see how security has transformed over the years. Back in the 80s it was pretty much that no one cared about it. Or more appropriately the only people that cared about it were the true technologists and the geeks – case in point being the Morris Worm which was primarily intended not to be a security attack but an experiment (gone horribly wrong) to measure the size of the Internet but more specifically the academic networks of the time. Then came the late 80s and 90s and suddenly security was on everyone's mind but in a weird kind of way – essentially we got caught with our pants down and this led to significant amounts of innovation (if you can call it that) and productizing that saw the birth of CERT, the first network based vulnerability assessment tool, the first anti virus software and the first network security devices. Essentially though this was as an era of a lack of knowledge i.e. there were very few "good" guys available who knew what it took to secure computer systems. It was also an era of increasing reliance on computer systems in general from health care to online banking, ecommerce, egovernment and so on… The primary reason for this lack of knowledge in my humble opinion was that it is generally regarded as a bad thing to talk about "bad" stuff. So the knowledge was thus left only in the hands of the "bad" guys!

The next era of security in my mind started with researchers and attackers alike beginning to look for vulnerabilities in released software. From buffer overflows in the 90s to SQL injection and Cross Site * today, this trend has continued. In the late 90s when people had begun to get their act together with regards to securing their networks with firewalls and intrusion detection systems, people starting exploiting vulnerabilities in accessible systems – primarily your web or FTP servers. This in turn gave birth to another slew of products – patch management! We saw first vendors arbitrarily releasing patches in response to exploits released or sometimes if you were lucky enough the exploit was released after the patch. Thus was born the entire paradigm of full disclosure – over the years this in my opinion has kept everyone honest and we have improved as community to a better system where we now see monthly patch schedules and such. This was also most likely the era when an entire career path of "information security" was created. Knowledge was now beginning to spread and in through Art of War style, it became important to understand the ways of the enemy if you were going to defend yourself. Hacking Exposed (the series but in many ways the original book) in many ways changed a lot of minds (created an entire genre I might add!) and it is probably one the biggest reasons for us at Foundstone to feel proud of the company and the people that are and have been there in the past.

At about this point vulnerability disclosures were going through the roof and vendors were truly being troubled with the lack of security in their products and applications. Releasing patches had a number of costs:

Reengineering and redoing work that was not done right the first time
Reputational costs of looking bad in public – being made fun of by your competitors etc.

This was probably one of the earliest points when simply going out and buying a piece of technology or tools (no matter what the marketing department tells you!) would not solve or eliminate the problem. It needed genuine commitment and effort from the inside in. We needed a concentrated on the people, process and technology of systems development. It took a while but companies such as Microsoft among others began investing in security throughout their SDLC processes and again if you put your biases aside for a few minutes you can see that this investment is paying off with fewer vulnerabilities and better security features in their products. Unfortunately however, this attitude was not universal and part of the reason in my opinion is that you often don't think you need something until it comes to bite you in the rear. A number of large software and hardware makers chose to completely ignore security and paid the price as focus shifted to them. Most importantly it was the companies developing line of business software and custom software that were perhaps the most lacking. But if you think about it these are also the makers of the your online backing software, your payroll system and your credit card processing systems.

Enter legislation such as GLBA and California SB 1386 and now suddenly companies had to invest into security or people got thrown into jail – important high ranking people at that! Again the tendency was to look for quick fixes – cheap and dirty. Unfortunately, such solutions rarely work for the specific purpose they are intended for but perhaps most importantly they treat the symptom and not the root cause of the disease. No effort was made to go after the systemic problems – in fact I would even venture to say people didn't see this as a systemic problem. Its only after paying the price of failing audits time and again or worse still being hacked time and again did organizations begin to turn around and see the light so to speak. However, the sad thing is many people are still looking for the quick and dirty fix – hoping a series of band-aids will cure the disease!

Fast forward to today and what are the security issues – identity theft, phishing, social engineering. Back in the 90s when you were hacked, I the attacker wanted you (and indeed the world) to know – I wanted my 15 minutes or 2 days or month of fame. Damn it! I had earned it by using my packet flooding skills! Web defacements were the ultimate rush. Today, in all my experience, attackers no longer want you to know, they want to quietly sit there and steal information, personal information, corporate secrets and national secrets – redirecting these to their databases.

What's the one common trend through all of this? We have always been reactive – following the attackers and their techniques. What are we doing to defend ourselves against this next wave of attacks? Are we truly anticipating and getting prepared? Do we even know what the next type of security issues are going to be? Are we building securable systems? Or are we waiting to evolve and innovate? Someone once said those that don't learn from history are doomed to repeat it – perhaps we in the security community should learn something from our pasts and security in general (outside of information systems) so that we are one step ahead next time instead of hundreds of steps behind.

Administriva: Wiki Updated

rudolph — Mon, 26 Feb 2007 06:55:07 GMT

Just a quick note that over the weekend I got a bunch of stuff over onto the Wiki. So far this is mostly stuff I wrote for Software Magazine. Main article is one Security Code Reviews which it turns out has been pretty popular – its usually in the top 5 Google hits when you search for security code reviews. More will be coming up on the Wiki soon. Again anyone else with the time or inclination to contribute contact me J - like I said I want to eventually have this site dedicated to being a Software Security Knowledge Base (Wiki) and move my personal stuff and thoughts elsewhere. All of this content is licensed under Creative Commons.

P.S. The Wiki software I am using is CS-Wiki which is really cool – especially going from Word to Wiki (probably one of the best I have seen when it comes to this and just adding content without learning special syntax) but bear in mind it is still in beta (and hence this wiki is in beta) so forgive any hick ups. Also I have already found a couple of security issues with the Wiki (nothing major – luckily its designed pretty simply and this site is running in partial trust!) but if you do run into anything else (while I complete my security review) please let me know.

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

rudolph — Wed, 21 Feb 2007 08:04:05 GMT

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:

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.
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?
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?
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!

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

rudolph — Wed, 07 Feb 2007 06:50:30 GMT

All too often I get asked questions such as:

Which is more secure Microsoft Windows <Put your version of choice here> or Apple Mac OS <Pick your version here>?
Which is more secure Internet Explorer or Firefox?
Are two tier architectures – where my database is accessible from my web server in the DMZ less secure than a three tier architecture where all database access goes through a middle tier?
…

Much debate along these lines has been seen recently with the public consumer release of Microsoft's latest OS offering in the form of Vista. The Microsoft bashers will point to the fact that Vista already has unpatched vulnerabilities and it has barely been released. On the other side of the spectrum, a lot of Microsoft marketing and a number of security experts will tell you that security was the number one feature in this release and that is precisely why you should upgrade. I would almost be willing to bet that for all the experts you will find that would be willing to put themselves on a life support system hooked up to a public wireless network and running on Windows Vista, you would just as many that would refuse to do so unless the operating system is Apple Mac OS X.

So what is the correct answer? Which "experts" does one as a consumer believe? Well I decided to look at some of the statistics that people like to throw around as backing data for their arguments. Secunia.com is a wonderful site at times like these – and if I assume (and perhaps wrongly so – but I think we can for argument's sake) that they are the one and only definitive source of vulnerability tracking on the planet, then the numbers below can be trested as absolute. Before I go further though, I want to extract a promise from you the reader, irrespective of what side of the fence you sit on – don't assume I am on one side or the other at least until you get to the end of this blog post (I promise there is a method to my madness and the wait will be worth it J).

Ok let's talk about pure numbers since numbers don't lie some would say. Consider this:

or perhaps this

From the looks of these statistics it would appear that Microsoft has had 43% more vulnerabilities in their Windows XP Professional offering as compared to Apple Mac OS X. And you can take that number and write article after article and post after post claiming Microsoft is a lot less secure than Apple. But then someone will turn around and say Microsoft has got their act together in recent times and have invested a ton of money into security (which they have) and offer something like the following as evidence:

vs. this

But I wonder if the Month of Apple Bugs had something to do with this?

And then off course you have those that say well this isn't even an argument worth getting in to because I run on IBM OS/400 which is by far the most secure operating system on the planet while offering something like this as evidence.

Well, try telling to that to the one administrator of an AS/400 machine that fell victim to the one vulnerability that was patched in November of 2006.

Hopefully you see my point now, numbers by themselves are meaningless as are how many patches are released on Patch Tuesday. The reason this is so because each vendor (Microsoft and Apple in this case) has their own risk assessment methodology and patch release process. While Microsoft tends to fix single issues per patch / advisory, Apple on the other hand will tend to bunch up a number of fixes into a single "patch". While one can argue for a more standardized approach, at a high level I don't have too much of a problem with either approach. What I care about is that patches get issued, and vulnerabilities get fixed.

So that really brings me to the main point of this post which is whether it even makes sense to talk about numbers like these and get into heated debates about whether X is more Y? In my opinion the main problem with numbers is that unless they are taken in context they can be made to say whatever the presenter wants them to say. Hopefully the examples above have provided some evidence of this.

I think the question we should be really arguing about is which of X or Y is more securable. There is a huge difference in my opinion about someone saying their operating system or application or browser is more secure and saying it is more securable. If you look at the most common types of attacks these days that go after end-consumers if it is things like phishing and identity theft. In light of this what I as a consumer care about is what operating system / application / browser makes it the easiest for me to protect myself and the hardest for me to shoot myself in the foot which I will inevitably do. That is my definition of securability.

So with that said let's talk about securability – I think Mac OS X and now Vista both have capabilities and features that make them far easier to secure than their predecessors – an example being not running everything as an administrator or user account control (UAC). I think by itself will help alleviate the "I shot myself in the foot" problem to a large extent. Off course I think there will be vulnerabilities and I absolutely do not think that a year from now the graphs for either operating system on Secunia will be empty. The reason for that is it is not an easy task to get rid of every buffer overflow or every format string vulnerability. What you can do is mitigate the risk – compile your code with stack protection, run with least privilege, use default deny and so on. I think to a large extent the major software vendors and certainly from what I can see – both Microsoft and Apple have seen the value in doing this and will continue to do this. But in code bases with that many lines of code (50 -60 million from what I hear but who's counting J) there are bound to be mistakes that have been made, oversights and just things done which at the time they were done were completely correct but security research has evolved and will evolve to prove those very things to be huge vulnerabilities.

So are we all done then – we cannot get any better? Well not really, I think the next thing to get right is to chop privileges down even further. Sure we have made it harder for malware to install a kernel mode key stroke logger on our machines but how about that phishing site or that JavaScript which runs in the background or that email client which receives an email containing a malicious script that reads my confidential files. I think that is where the next evolution of software security should be going. How can we create true application sandboxes (and I know this word has been used and misused multiple times) which restrict what an application can and cannot do based on only what they need to do. We have attempted to solve the security problem of an attacker damaging the underlying machine and the infrastructure (operating system, applications etc) but how about preventing an attacker from hurting the user him / herself. How about preventing my email client or my browser (even if these are running min my context or heck in the context of the administrator himself) from accessing my Microsoft Money or Quicken files unless I the user explicitly allow that access?

Well for my thoughts on a more concrete basis – stay tuned. To be continued ….

Full disclosure: I am a Microsoft Developer Security MVP and receive a number of benefits from Microsoft as a consequence. However, this post has nothing to do with that relationship or the benefits. I would like to think I was and am completely unbiased. I should also mention that I also am an owner of both a Mac and a PC laptop on personal level but do use primarily Windows for work.