Data Breaches and Privacy Violations Aren't Just About Identity Theft

Chris Walsh over at the EmergentChaos blog had a piece the other day about some of the research they are doing on breach disclosures and what we can learn from them. I made come comments about data breaches as they relate to identity theft and at the time was pretty well convinced that what matters about data breaches is just identity theft.

After reading a follow-up comment from Chris and Dissent, and then the next piece by Adam -
It's not all about "identity theft" - I think I need to regroup.

Adam made the point that:

Data breaches are not meaningful because of identity theft.

They are about honesty about a commitment that an organization has made while collecting data, and a failure to meet that commitment. They're about people's privacy, as the Astroglide and Victoria's Secret cases make clear.

This is a very good point and one I'd lost site of in my previous comments. Protecting privacy is about the implied or explicit agreement between the data provider and the data repository/protector. A breach of this agreement constitutes a privacy violation, regardless of whether the law requires disclosure.

One of the problems with current disclosure laws is that their focus is entirely on identity theft. SB-1386 (and most if not all of the other disclosure laws) only kick in if your personally identifiable information and private identifier (bank account number, SSN, CC#, etc) is released as well. The end effect of this sort of disclosure regulatory regime is a focus not on privacy but on identity theft. As Adam rightly points out a lot of damage can be done through privacy violations without requiring the possibility of identity theft.

Adam listed two obvious examples of data disclosures that had nothing to do with identity theft but that nevertheless were violations of privacy agreements made between the data owner and the data custodian. Another would be AOL's release of search data.

I'm toying with a few thoughts on how you can modify the existing US regulatory regime without undesired effects. The US is distinctive from other the EU example for our relatively lax privacy regulation, but there are at least a few consumer friendly results that go along with it such as cheaper financing, etc. Trade-offs abound and we don't make decisions in an informed fashion about almost any of them. But more on that later when I have a little more time to think.

Banning Programming Languages to Fix Problems?

Michael Howard had an interesting piece the other day on the SDL blog and also gave an interview about some similar topics. The subject I'd like to address is the banning of certain things during the development process and the theoretical and practical aspects of it. I'd like to show that banning function calls and enforcing annotations as a coding practice is reasonably far down the path to saying that C/C++ isn't such a good programming language from a security perspective and that to achieve higher levels of assurance we need to go further down that road.

I'd like to touch on a few points in this piece:

• The SDL vs. Legacy Code
  
• Banning Programming Constructs, Functions, and/or Whole Languages
• A Sliding Scale of Assurance

The SDL vs. Legacy Code

One of the things I'm struck by in Microsoft's SDL book is how pragmatic it is with respect to making software more secure. They point out repeatedly in the SDL book that products have been delayed and features scrapped because they either weren't secure, or couln't be made secure. While I can't argue with them about whether they've done this, there are at least a few places that we can point out a less than stellar track record of reducing feature sets to improve security. Web Browsers and how Windows does file associates come to mind as big security vs. feature wars that the feature folks seem to have won.

Michael and the other folks at Microsoft have done a ton of good work in creating, refining, and implementing their secure software development methodology, SDL. The SDL however reflects the realities of the Microsoft situation - millions of lines of legacy code. No one with that much legacy code can afford to start over from scratch. Anyone who suggested writing the next version of Word in All C# would probably get a swift kick. So, the Microsoft security folks are left with taking the practical approach. Given the fact that there is a lot of legacy code, and given that they aren't going to make a wholesale switch to another programming language, what is the best they can do in C++.

I think this is a fair approach but I don't really believe for a minute that if you asked one of the security guys there what programming language they want new things written in they'd pick C++ over C# for anything other than things like a kernel.

Banning Programming Constructs, Functions, and/or Whole Languages

Michael said in his recent piece:

In all of our SDL education we stress the point that .NET code is not a security cure-all, and we make sure that developers understand that if you choose to ignore the golden rule about never trusting input no language or tool will save you. Using safe string functions can help mitigate risks of buffer overruns in C/C++, but won’t help with integer arithmetic, XSS, SQL injection, canonicalization or crypto issues.

The key point is that languages are just tools; anyone using a tool needs to understand the strengths and limitations of any given tool in order to make informed use of the tool.

One final thought; in my opinion, well-educated software developers using C/C++ who follow secure programming practices and use appropriate tools will deliver more secure software than developers using Java or C# who do not follow sound security discipline.

I can't argue with Michael's point. I also don't know a lot of people in the security world that believe eliminating C/C++ automatically makes you secure. I do know quite a number of people though that make the good case that programming in C# or Java significantly reduces the exposure to certain classes of vulnerabilities and overall results in more secure software when using a develop trained in security.

WhiteHat Security's numbers of the general presence of web application security vulnerabilities per language seems to bear this out. In general applications written in ASP.NET and Java have fewer security vulnerabilities in them due to language constructs and secure coding frameworks.

I think you only have to look at what Microsoft has done with banning certain functions and requiring annotations to see that they have already taken some steps in the - C++ is bad - direction.

Why do they ban certain function calls such as strcpy, etc? Is it because the function inherently cannot be used safely? No. The reason is that its tremendously hard to use safely, and by removing it from the programmers options and replacing it with something that is easier to use, they improve the security of their software.

Why do they do annotations? They do them so that their static analyzers have an easier time in ferreting out certain classes of security defects.

If we could train developers to use all of the features of the programming language correctly, we wouldn't have to worry about either of these things. We'd simply do training and get on our way. The reality is that we cannot rely on developers to use certain portions of the language properly. We've shown repeatedly that certain function calls are the root of the vast majority of the security vulnerabilities out there. Most of the function calls that Microsoft has banned are ones that have been found to result in buffer overflows.

If we take as our starting position that developers can and will make mistakes, and we're wiling to enforce certain rules on them to constrain how they can use a programming language, why not take the next step and ask what else we can do to improve the security of the code we deliver?

There are several other areas of C++ that are problematic from a security perspective. Memory allocation comes to mind. The number of flaws we see from misuse of memory allocation is huge. Why not switch to a language that makes it fundamentally harder or impossible to have these kinds of issues?

Take the annotations Microsoft is using to hint their static analyzers. What these amount to are lightweight programming-by-contract constructs that we use for after-the-fact analysis rather than just forcing them through the programming language and calling violations errors. why not switch to a programming language that forces annotations rather than treating them as an after-the-fact construct?

A Sliding Scale of Assurance

In the end what we have is a sliding scale of assurance and functionality. Processes such as the SDL that mandate processes but don't require us to switch tools only get us so far down the assurance path. It is further than many/most companies are willing to go and credit to Microsoft for making such an effort. At the same time there are things the SDL doesn't necessarily do:

• Enforce the use of tools and programming languages that are more likely to reduce security vulnerabilities
• Eliminate software features that are truly problematic from a security standpoint and yet users have come to expect

If we want the SDL to be about delivering fundamentally more secure software at higher assurance levels, then it must mandate certain programming methodologies that result in higher quality code. Without these sorts of mandates we're still just putting band-aids on our existing software development processes.

Assurance comes at a cost. Development costs, testing costs, etc. When we switch tools that eliminate certain classes of vulnerabilities both remove the effort that developers would spend on securing the code, and also on the time the testers spend looking for certain classes of defects. In the end this is what Microsoft has done by removing certain programming constructs, they just haven't made the slightly bigger jump to another programming language for reasons I've already explained above.

Upshot

What I think this comes down to is use C++ if you must to muck with legacy code, but please don't do new development there. From a security perspective its going to be a lot more expensive if you do.

More on Software Liability

About five weeks ago Symantec messes up their AV signatures and accidentally classified some Windows system files as viruses. The files were only part of the Simplified Chinese version of the OS, so presumably this didn't get as much testing as a regular configuration.

Yesterday it was announced that they would compensate those folks who got hammered with some compensation.

I'm going to be very interested to see how this plays out, whether the lawsuits move forward, etc. This is a pretty clear example of harm done by Symantec, and certainly not intended behavior. Not clear whether this falls into the "didn't test enough" category of mistakes or what. Perhaps they bypassed their internal processes to release these signatures? Either way I bet they are hoping they have a good audit trail internally to show exactly how/why this happened.

I'll be watching this one to see whether any of these folks persist in their lawsuits and whether this ends up making any case law about software liability.

On Bad Post Titles

Sometimes you start writing an entry intending to cover a subject a certain way but by the time you're done you've sort of switched gears but you already wrote the title and you forget to go back and fix it.

Rothman pointed today to my post from the other day "Building Effective Metrics." He rightly pointed out that the piece isn't really about metrics. I think he's slightly off the mark though on his statement that I was writing mostly about risk management.

I think the point I was making was about culture change and secondarily about risk management. The old story/analogy about a frog in boiling water is at least slightly appropriate. Though when I went to look up the story I found out more than I wanted to on the Wikipedia article for "boiling frog."

If you want to achieve success in implementing new parts of a security program, you've got to start with the sustainable processes and make them routine before you can get an organization to actually make progress on reducing risk. Thats a really short synopsis....

The piece could probably have been better titled, so I guess I'll just try to do better next time.

Building Effective Metrics

The topic of metrics for Information Security comes up quite often. I've been in quite a number of situations where a relatively sparse infosec program exists and no metrics exist. The question often comes up of what types of metrics to gather first to measure program status, effectiveness, etc. And, when rolling out a new element of an infosec program what metrics to focus on first.

I've come to the conclusion that process maturity based metrics are the best thing to worry about when you're building an infosec program or a new feature of an existing program.

Let's take several areas of Infosec and examine my premise.

• Vulnerability Management (discovery and remediation)
• Anti-virus software
  
• Software Security

Vulnerability Management

When you're first starting to build a vulnerability management program you're worried about a few things:

1. Measuring existing vulnerabilities
2. Remediating vulnerabilities
3. Eventually, reducing the number of vulnerabilities that get "deployed"

Most people try to tackle these items in numerical order. They buy a vulnerability scanner, they start scanning their network, they come up with a giant list of security vulnerabilities, and then they try to tackle #2, remediation. They generally set the bar pretty high in terms of what they expect the organization to fix. For example, all level 5,4,3 vulnerabilities in a Qualys scan. They push the vulnerability report to the systems administration staff, tell them to go fix the vulnerabilities, and wait an eternity to hear back about the vulnerabilities, what has been done, etc. Usually they get upset that things are being fixed faster, that new vulnerabilities surface faster than they can close the old ones, and they either give up and start ignoring their vulnerability scans, or they get extremely frustrated with the admins and a constant battle ensues.

Instead, I like to tackle these items in reverse order of the above list:

1. Reduce the number of new vulnerabilities that get deployed
2. Implement a remediation process
3. Search for vulnerabilities and feed them into #2.

In my experience most people want to go a good job at what they do. They don't want to release systems with holes in them, have their systems get hacked, etc. Unfortunately they aren't security experts and don't know what to focus on. They need assistance and prescriptive guidance on exactly what to do and when to do it.

Step 1: Reduce the Number of New Vulnerabilities

Start with something like a system hardening guide and approved software list. You pick things like the CIS hardening standards and ensure that all new systems getting built go out the door with your hardening applied. In this way you cut down on the number of new vulnerabilities you're introducing into your environment.

Step 2: Implement a Remediation Process with Metrics

Work on a remediation process. Focus on elements such as:

• Who is responsible for requesting something be remediated
• Who is responsible for determining the scope of the request and its priority/severity
  
• What testing has to be done, and who must approve it in order to push something to the environment
• How do you track status through each of these items including time taken, roadblocks, etc.
• How much did it cost to fix each vulnerability
  

Building your remediation process before you start up the firehose gives you several advantages:

1. You can start slow at feeding vulnerabilities into the remediation process and get useful metrics about the costs of remediation.
2. You don't cause undue friction with the operations staff by asking them to take on too much too soon.
3. You have a well-established process for fixing any/all vulnerabilities you discover.
   

Once you've got this process created you can measure how effectively you're remediating any given vulnerability you discover. You have process metrics for your remediation process, rather than an ad-hoc best effort situation.

Step 3: Search for Vulnerabilities and Feed Them to Your Remediation Process

One you have a repeatable remediation process, you're ready to start feeding the process new vulnerabilities. In an organization that isn't used to routine patching, turning off services, remediating vulnerabilities you can't start out with a firehose of vulnerabilities to unprepared staff. The best approach is to use the metrics you've created in step-2 and be selective with what vulnerabilities you ask to be fixed. Once you have the process in place you can choose to stat with a subset of your vulnerabilities - your example your Qualys level-5 vulnerabilities. Ramp up slowly to the organization so that you can adequately measure the impact of your changes, the value they are providing, and the costs of remediating.

Get people used to being accountable for fixing vulnerabilities, for testing the fixes, and for measuring the results. Once you have that in place you're free to ramp up the security level you want to achieve in a measured fashion.

Eventually, once you finally have a handle on these three steps you can move on to more advanced metrics such as:

• Average time to remediation
• Overall vulnerability score

Until you have the first three pieces in place though focusing on your overall risk/vulnerability isn't that interesting. Even if you don't like the score, you're never going to get it lower without a repeatable process in place to remediate.

More on process related metrics for Anti-virus and Software Security in a later post.

Microsoft's "The Security Development Lifecycle" - Chapter Five

Chapter 5: "Stage 0: Education and Awareness"
Chapter 4 here


The authors credit roughly speaking, two things with the success of the SDL at Microsoft:

1. Executive support
2. Education and Awareness

Arguably they couldn't have achieved #2 without #1 but its interesting that they rank education and awareness as highly as they do in the SDL, given how much we've read lately about how successful most companies are/aren't in the general security awareness campaigns.

One interesting point in the introduction to the chapter is the reminder that secure software isn't the same as security software. Secure software is software that is resistant to attack, security software is software that is intended to specifically address a security concern.

The chapter has a history of security training at Microsoft. Based on the descriptions of training even before the formal SDL Microsoft was spending considerable money on training and development of its engineers. My guess is that if you've already got a corporate culture of training and education, implementing the specific training required for the SDL is going to be a lot easier than it would be at a place that doesn't already take training that seriously.

The chapter also has an overview of the current training courses for secure development available at Microsoft. I'm hoping that their future plans include making these public even on a for-fee basis so that the rest of the world can benefit from some of the work they have done.

One the sections in the chapter is on the value of exercises/labs as part of the training. They added a lab section to their thread modeling class and feedback scores went up and presumably the student's understanding of the materials as well.

Having attended and given several security training sessions I can definitely recommend this approach. I've had software security training from both Aspect and the old @stake folks and both classes had an interactive lab component. I took away a lot more from the courses than I have from most of the other security classes I've ever done.

One other interesting section in this chapter is Measuring Knowledge. At the time of the book's writing Microsoft didn't have a testing or certification program in place for their developers. I haven't had a chance to catch up with the SDL guys to see what their take is on the new SANS Software Security Initiative. I'll be interested to see how the SSI stuff shakes out and Microsoft's involvement.

Overall its interesting to see how much attention and dedication Microsoft has made to the SDL from a training perspective. The costs of the training alone in an organization the size of Microsoft is going to be enormous.

If you don't already have a robust internal training program in place in your organization this chapter does give a few hints on how to build one o the cheap. At the same time the chapter is more about the structure of the Microsoft training program than exactly how to go about building one. At the end of the chapter you're fairly convinced that you need a robust training program, but if you don't already have one you're going to be searching for a lot of external help to build one.

How I Got Started in Security and the Value of a Mentor

So, A few people out there have been blogging about how they got their start in security. I figured I'm exactly the sort of exhibitionist that would post that sort of thing, so here goes.

Warning: This entry is long and probably more than a little boring and self-indulgent. You've been warned..

I've been doing paid IT work for roughly 14 years. I got my start doing it for pay as a student at the University of Chicago in the main student computing lab. I was doing basic PC, Mac, and later Unix administration. I had a pretty strong Unix background from a few years I spent as a student at RPI where student computing was an exclusively Unix affair.

After working at the University computing lab as a regular worker I was put in charge along with a colleague of running a new cluster of SGI Indy machines. Our job was pure Unix system administration of 9 SGI machines. We were responsible for all aspects of system administration and I learned very early on that doing system administration at a University is rather different than doing it in most other environments...

• Permissive culture and lack of definitive policies
• Security not a priority except insofar as it caused the machines to be unavailable.
• Insider attacks are at least as prevalent as outsiders

So, I cut my security teeth in that environment. Even though I was officially a Unix admin, I spent 50%+ of my time on security concerns. I even brought up one of the first semi-official kerberos realms at the UofC. Only about 5 of us used it at the time, but it sure did teach me a lot about distributed authentication.

One person I'd like to single out for how much he helped me in learning about security is Bob Bartlett. When I first started doing sysadmin at the UofC Bob was relatively new to the main computing group. Part of the University ethos and culture is a respect to educating, training, and mentoring. When I was just a student I used to go and hang out in Bob's cube area when I had some free time to see what sorts of things I could pick up on. Bob was the most amazingly patient guy I ever met. No matter how many stupid questions I asked, crazy schemes I came up with, he weathered the storm and never told me to stop coming around. I learned a lot about Unix security, the value of lots of layered defenses, how to do forensics of a compromised machine, etc.

Its amazing how much value you can get out of a good mentor. How they can show you ways of thinking, ways of working, how to interact with other people, etc. I can't say I learned all of those lessons and I'm certainly not a Bob clone, but of all people he's probably most to blame for me being in security today.

I spent two more years working at the UofC maintaining the main interactive unix machines for the campus. I talked a bit in an earlier post about how I don't think we've come that far in the last 15 years, but maybe I'm just jaded.

I then spent 4 years at Abbott Laboratories working in the pharmaceutical research division doing Unix admin. I wasn't officially in charge of security but since I was roughly the only person in the whole group that knew a lot about the subject I became the firewall administrator, ACE server administrator, in charge of network security monitoring and forensics, etc. I brought up the first network IDS there using first Shadow and then NFR.

The area I worked in was highly regulated so I got my full dose of filling out logbooks, worrying about audits, etc. It helped in our paranoia that Abbott had a quite a number of adverse regulatory issues during those times which made us that much more serious about security. That said the regulations that apply to the pharmaceutical business aren't that different that other regulations such as PCI. They are supposed to guarantee a certain level of security, but half the time they just result in a lot more paperwork, etc.

After 4 years at Abbott I left to go work for a software company in downtown Chicago to be the sole security person. I was responsible for all aspects of security except physical. I spent 5 years at CCC working on pretty much everything security - Policies, Procedures, SOX, Firewalls, IDS, Application Security (coding standards, threat modeling, application pen testing), vendor relationships and contracts, etc.

The scope of the job was great but unfortunately the industry they were in wasn't in need of the kind of serious security I was really looking to do. So, I started looking and eventually moved to the Bay Area to take a job with a large financial services firm. I don't like to talk about who it is, but if you use google and linkedin it can't be that hard to figure it out.

I think one of the main skills I bring to the table is my background doing a lot of different IT work for a lot of different types of environments. I worked for a University, a heavily regulated pharmeceutcal, a software company, and a financial services firm. I've done everything form desktop support to large system unix admin to software security work. I think its both breadth and depth that are to be valued in Information Security. Hopefully I've got some of both but I guess you be the judge.

Microsoft's "The Security Development Lifecycle" - Chapter Four

Chapter 4: SDL for Management
Chapter 3 here

Chapter 4 is about ensuring the success of the SDL through management support. As such its really the first chapter that I think starts to address some of the core issues of the SDL. This chapter makes a lot of sense in relation to Dave Ladd's post from the other day about culture change.

There are a few key takeaways for this Chapter:

• Management support is critical for implementing a software security effort
• Continuous messaging, reinforcement, recognition for a job well done, and training are all a part of the management support and culture change
• The SDL can add 15-20% overhead when it is first implemented but considerably less thereafter.

Chapter four again includes some background on what drove Microsoft to implement the SDL. Without throwing cold water on the four main reasons outlined:

• Customer complaints
• Actual attacks
• Press coverage - bad PR
• Frequent patching required diverting developers from new products to maintenance

I think another concern is liability. Microsoft's position as a monopoly in the desktop space makes them much more liable than other software companies might be. Regardless of the specifics of the list, all of these point to a purely economic analysis for why Microsoft chose to go down the SDL route. The SDL isn't in place merely because a bunch of smart developers thought Microsoft should develop more secure software. The SDL is in place because Microsoft management made the decision that the benefits of the SDL outweighed the costs of its implementation. This is a key point in gaining and sustaining management support.

Now a review of a few specifics of the chapter where I think they got it right and/or I have a few small comments.

On page-44 they discuss the vulnerability rate in Microsoft products post-SDL and the improvements seen. Similar to earlier chapters they claim that the discovered vulnerability rate has gone down and try to correlate that remaining vulnerabilities in the codebase. I'm not sure I agree with this assessment methodology. The jury is still out on 0day attacks, people not releasing vulnerabilities in certain key pieces of software, etc. Forensics data isn't widespread either as it relates to attack vectors. Most companies aren't very public about exactly how they were attacked, what vector was used, etc. So, we're a little blind on exactly how many attackers there have been against SQL-Server 2000sp3. Perhaps Microsoft has better forensics data than other folks because people actually report to them hacks?

Another point made is that as Microsoft's software has gotten harder to attack the attackers have focused their energy elsewhere. Its like the old joke....

Two guys are in the woods and they come across an angry grizzly bear. The bear starts to chase after them. One guy says "I'm sure glad I wore my running shoes today". The other guy says "It doesn't matter what shoes you are wearing, you can't outrun the bear." The first guy responds "I don't have to outrun the bear - I just have to outrun you."

On page-48 the section "Factors That Affect the Cost of SDL" they discuss the costs for existing vs. new development. One assumption that seems to be baked into their analysis is that implementing the SDL is an all-or-nothing sort of endeavor, and that roughly speaking it happens all at once. While it doesn't change the costs to implement over a long term or short-term, much of the language of the book seems to speak as if the SDL springs into being all at once.

On page-50 in the section "Rules of Thumb" they give the estimate that the SDL can cost 15-20% in initial implementation costs but less thereafter as a product matures. I'd be interested to know how many positive side effects they see from SDL implementation that aren't directly security related. Many elements of the SDL enforce a certain rigor on the development process that might not exist otherwise. You can't do proper threat analysis without good architecture documentation. And, the architecture documentation has to be accurate or the value of the threat analysis is going to be lower. In organizations that don't have a robust software development process to begin with I'm guessing that the artifacts of the SDL provide considerable value outside of security.

My only complaint so far about chapter four is that they don't spend more time discussing metrics. Key to gaining and retaining management support is demonstrating the effectiveness of the program. Chapter four has a limited section on SDL metrics and I can see that some chapters have explicit sections on metrics while other don't. The metrics provided in Chapter four aren't very extensive and they are sort of meta-metrics about the SDL - so we'll see whether this is covered in more detail later.

Questions About Software Testing and Assurance

Measuring assurance in security is difficult. On the one hand we'd like to be able to objectively measure the work-factor an attacker must expend in order to successfully attack something. Unfortunately it is the rare case where we have this level of certainty for the work-factor. Only in situations where the work reduces to breaking a cryptosystem can we have any true estimation of the work required to break our software, and this of course relies on proper cryptosystem operations from the code and operational (key management, etc) perspectives.

James Whittaker's recent piece on the Microsoft SDL blog about "Testing in the SDL" is quite interesting when looked at through the lens of assurance, which is what he says he is describing:

Security testing has been – and will always be – about assurance, that is, assuring that the product as built and shipped has been thoroughly tested for potential vulnerabilities. Bug detection and removal will continue to be important until a time in the future comes when we can deploy provably secure systems. However, we’re likely never to get to such a future without learning the lessons that testing is teaching right now. Anyone can write a system and call it secure – it’s only through watching real systems fail in real ways that we learn to get better. Moral of the story – testing is by far the best way to show us what we’re doing wrong in software development.

What is so unfortunate about this statement is that James is correct. In the vast majority of cases we simply can't reduce any element of the software to a purely objective measure of work-factor for an attacker. We're generally still so bad at writing software that we end up designing security in - but in the end - rely on testing to give us any certainty about the quality of the software we've created.

We lack the ability to analytically evaluate software from a quality and/or security perspective and we're left with the crude approximation that is testing. Its sort of like needing to to an integral of something and discovering that the function has to be calculated numerically and so you're left with an approximation rather than a closed-form solution. You know that no matter how you try you're just getting an approximation of the answer and that is the best you can do. The real world is like that sometimes but oh to have the certainty that a simple equation would give you.

I think the one saving grace here is that we know that reusable components are a good approach to solving this problem. Robert Auger wrote a nice piece on this titled "The Business Case for Security Frameworks." In it he argues that reusable security frameworks are a great initial defense against insecure coding practices. I'll agree wholeheartedly and on top of that throw in that once you start using frameworks like this, you hopefully reduce your testing burden to new code and new attack vectors rather than going over the same ground again and again. James I'm sure knows this all too well.

There has been quite a bit of discussion about exactly this sort of analysis at Microsoft with respect to Vista and how its newly created and properly engineered code will fare over time against attackers. Despite recent bogus claims to the contrary - Vista seems to be holding up pretty well.

What I'd still love to have though is an analytical way of measuring code quality and/or work-factor for attack to have a "real" measure of how resistant to attack a piece of software is. Schneier has been writing forever about an Underwriter's Laboratory for security. I wish I could feel more confident that we are getting closer to having an answer to this type of question.

Blogger Stupidity - Only Not the Kind You Think

I posted last night about a problem with my feed and questioned whether the problem was with Feedburner or Blogger. Turns out the problem was with a blogger - me.

In Blogger an item is created and titled based on the original title you give it. If you subsequently edit the title you end up creating a brand-new entry rather than overwriting the original item with a new title.

So, I ended up with two identical items last night except for the title. Its kind of counter-intuitive that blogger does this. In most tools the instance of something you're editing doesn't change just because you change the title. Turns out that in blogger they've turned that on its head.

Not sure why it needs to work that way, but it does - and now you've been warned.

Feedburner or Blogger Stupidity?

So, I wrote a blog entry earlier tonight and spelled the title wrong. Looks like feedburner picked it up twice. I really only wrote one entry about the SDL Chapter Three.... I didn't really write another entry about Chapter Thre

I haven't yet determined who to blame for picking this up wrong. My guess is that feedburner is keying on title rather than URL for the blog entry, something perhaps they could see their way clear to fixing.

Microsoft's "The Security Development Lifecycle" - Chapter Three

Chapter 3: A Short History of the SDL at Microsoft
Chapter 2 Here

Chapter 3 is mainly a history of the SDL at Microsoft. While interesting for a historical perspective, the main bits from a security knowledge perspective are:

• Developing the SDL was a long process and meant a lot of culture change at Microsoft
• Developing the SDL took an iterative approach and evolved over time

What I found most interesting about the chapter was the bit of sleight of hand as regards Microsoft's lack of security in Windows-95 and other close in proximity releases. The authors say:

Windows 95 was designed to connect to corporate networks that provided shared file and print infrastructures and to connect to the Internet as a client system, but the primary focus of security efforts was the browser - and even there, the understanding of security needs was much different from what it is today.

I can interpret this statement two ways:

• Charitable: We've know more now than we did then or reasonably could or should have known then, and so didn't incorporate a lot of security features and process into Windows 95.
• Uncharitable: We didn't pay a lot of attention back then to security. We could have and should have but we didn't. As such our understanding was less than it really should have been and we did a crummy job with Windows 95.

I'm inclined to believe the truth is somewhere between these two points. I don't want to point fingers at anyone in particular about it but the idea that an operating system ought to have some security built into it, and that the Internet or networks in general could be scary places wasn't exactly unknown in the mid-1990's. It isn't as if computer security was invented in 1995 or something after all. At the same time other single-user systems weren't necessarily worse than Windows 95 either, they just didn't have the presence that it did.

The only other complaint I can have about this chapter surrounds the vulnerability measurement metric they use to measure software security in a few of the examples. A difference is shown between SQL Server 2000 and SQL Server 2000 SP3. The statement made is that while SQL Server 2000 had 6 vulnerabilities reported and handled over its lifecycle up to SP3, SQL Server 2000 SP3 had only 3 vulnerabilities reported in the next 3 years. Unfortunately at this point of the book we haven't yet covered software security metrics so until I get there I can't make a strong methodology complaint. Using this sort of statistic seems a bit misleading to me however. Sure vulnerability reduction is a key metric, but reported vulnerabilities isn't necessarily the key metric to focus on.

More thoughts on training

My wife pointed out a very interesting article to me yesterday that she'd come across while reading Richard Dawkins's site. The article was about a lack of training/education in medical schools and how this lack of a basic understanding of evolution is at least partially to blame for drug-resistant bacteria.

I also read Dave Ladd's excellent piece, "Oil Change or Culture Change". Dave says:

Furthermore, many of the processes used by SDL (and other methodologies) are generally acknowledged as effective in identifying and mitigating security threats. Pondering this notion is what lead me to my realization about culture change, and prompted a question: If this stuff has been around for awhile in some shape or form, why aren’t more people doing it?

Dave's point is that we're not dealing with new knowledge here for the most part. We're dealing with a failure in education. In my previous posting about security training and what training is important I mentioned I'd had a conversation with Gary McGraw. Reading the pieces on Dawkin's site and Dave's piece made me remember something else Gary said that I think is very appropriate. I'm paraphrasing here so I hope I'll be forgiven but when I asked about the source of the problem Gary responded with an answer about your first engineering vs. first CS class.

Engineering Class: Professor opens class showing video of horrible engineering accident. Maybe something like the Tacoma Narrows bridge or the Challenger accident. In ominous voiceover - "If you don't study hard and do a good job, you could build something like this. People could die!!!!! Don't mess up, this is serious stuff."

Computer Science Class: Hello, look at this cool stuff you can do. Let's write a program that prints "Hello, World".

I think Gary is right. The culture we're trying to change is corporate culture, but it is equally computer science and programming culture. In a sense we have a chicken and egg problem. Until we have more companies demanding to treat software development as an engineering discipline, our universities won't be motivated to turn out students that treat it as such. And until schools start turning out software engineers rather than software developers we aren't going to have the talent necessary to get corporate culture change.

I don't know that we're at some sort of crisis point for software development education, I'd hate to be that melodramatic. At the same time I think what we're seeing is a disconnect between the realities of what it means for software engineering to exist as a true discipline, and our capability of achieving it. If we started with the mindset that it is engineering we're doing rather than "development" then we might stand a chance at making some progress.

I'll be interested in knowing the differences that exist at different university programs in CS and or CSE to see whether I'm wrong. Maybe there is broad support for a CS curriculum based in engineering rather than development.

Time for a bit of research on different CS programs and their focus.

Analyzing Software Failures

A few months ago I wrote a small piece called "Most Web Security is Like Finding New Ways to Spend the Loot."

I was thinking again about this topic and how best to contribute to the security world, and how much good finding new attacks does versus finding new ways of defending against things.

I'm reminded of accident investigations in the real world. Airplanes rarely crash. When they do, its something noteworthy. We have an organization called the NTSB set up to investigate serious transportation accidents and they investigate every plane crash. Why investigate all airplane crashes and not all car crashes? Because airplane crashes are pretty rare and we believe we probably have an anomaly and something interesting to learn by investigating an airplane crash. The same cannot be said about car crashes. They are simply too frequent and too "routine" to bother investigating.

When we think about civil engineering and failure analysis we don't generally spend a lot of time on every roof that caves in at a cheap poorly constructed strip mall. We spend a lot of time investigating why bridges fail, why skywalks fail, etc. These are things that were presumably highly engineered to tight tolerances, where a lot of effort was spent or should have been spent to ensure safety and where nevertheless something went wrong. We start with the premise that by examining this anomaly we can learn something that will teach us how to build or design better the next time around.

In software security its pretty amazing how much time we spend doing the opposite. How much time we spend analyzing applications that were poorly designed, that were never designed to resist attacks, prevent disasters, etc. We seem to never tire of finding a new security flaw in myspace, yahoo, google mail, etc.

What do we learn from finding these vulnerabilities? That we don't in general design very good software? That we have fundamental flaws in our design, architecture, and tools that cause these failures? We've known that for years. No new analysis is going to tell me its hard to design a high assurance application in PHP. We already know that.

The types of vulnerability and attack research that interests me are those that actually show a brand new type of attack against a piece of software that was well written, had good threat analysis done, where the developers, architects, and designers really were focused on security and somehow still left themselves vulnerable to an attack.

It isn't necessarily that these are rare situations. Microsoft Vista has had a number of security vulnerabilities since its launch despite the best efforts of Microsoft to eradicate them. Analysis like that provided by Michael Howard about the ANI bug in Vista is what we need more of. We need more companies with mature secure software development practices to tell us why bugs occur despite their best efforts. We need more people to be as open as Microsoft is being about how the best designed processes fail and we need to learn from that to get it better the next time around.

In the transportation world this is the role that the NTSB plays. The NTSB shows us how despite our best efforts we still have accidents, and they do it without partisanship or prejudice. The focus of the investigation is root cause analysis and how we can get it right the next time around.

I read this same idea on someone's blog recently as applied security breaches. They proposed an NTSB sort of arrangement for investigating security breaches so that we get this same sort of learning out those situations. If anyone can point me to the piece I'll properly attribute it here.

Along these same lines we ought to have an NTSB equivalent for software security so that we can learn from the mistakes of the past. Bryan Cantrill at Sun and I shared a small exchange on his blog about this topic related to pathological systems and I referred to Henry Petroski and his work in failure analysis in civil engineering. Peter Neumann's Risks Digest is the closest we come to a general forum for this sort of thing in the software world and I'm always amazed (and depressed) by how few software engineers have ever heard of Risks, much less read it.

Why is it that so few companies are willing to be as public as Microsoft has been about their SDL, and how do we encourage more companies to participate in failure analysis so that we can learn collectively to develop better software?

About the Host?

Mr. Hoff had a piece yesterday that was thought provoking but I think he failed to mention a few concepts that further make the point he was trying to make.

I think a piece missing from his analysis is one related to threats and types of security you're trying to achieve.

The question of network-level security controls vs. host-based security controls can be made in the context of a corporate network, the Internet in general, but it can also be made in the case of someone like an ASP.

If we take the case of a large ASP of some sort - Google, Yahoo, etc. we find that firewalls are already just about useless. Except for PCI requiring them, I doubt most people would even bother having their webservers behind one. They'd probably prefer something lighter weight such as an ACL or whatnot. I'm allowing in only 2 ports (80 and 443) anyway and if I just don't run anything else on the systems in question I don't get a lot of benefit out of the firewall, etc.

When I start looking at my threats though I'm left with 2 primary threats.

• My users
• Their machines (and associated malware)

Network security controls don't help me much against either of these when I actually want the users to interact with my web application. And, for both my users and my sanity, we'd better hope they have good host security controls in place while they are accessing my site, their bank account, credit card accounts, etc. If they don't, network security controls aren't going to do a whole lot of good.

Sure, you might ask how they got infected with the malware in the first place, but I'm betting that a firewall or other network security device suitable for the end-user wouldn't have helped a lot in this situation either.

I'm not arguing that network security controls don't have a place, but the higher up the stack the attackers push, the less effective certain network security controls are going to be.

Vulnerability Management for Custom Software

Writing last night's post about security evolution got me thinking a bit about vulnerability management and how best to handle it for custom written software.

In general vulnerability management you can get a lot of traction using a network-based scanner along with local scanning using user credentials. This technique which is not prevalent in most mainstream scanners gives you decent coverage for standard software, configuration settings, etc. It can even give you the heads-up on a vulnerability in a version of a library you're using, especially when you easily report the version via banners and/or via standard library locations on a filesystem.

Managing vulnerabilities gets substantially trickier though when you move to homegrown software. Keeping a proper inventory of every library, toolkit, configuration setting, algorithm, etc. you use and then being able to watch for vulnerabilities in them is quite tricky. Network vulnerability scanners like Qualys or nCircle will do a pretty good job banner grabbing, detecting versions on certain toolkits, connections, etc. What they can't tell you though is that you're using a buggy version on libz or libxml inside one of your own applications.

How do you handle situations like these?

In general I resort to managing an inventory of tools I have in use at any given time and using vulnerability alerting services to tell me about new vulnerabilities in those toolkits.

I imagine there has to be a better way to do this. I'd really like to be able to list the toolkits I have in some more generic format that vulnerability alerting services and/or vulnerability scanners are capable of understanding and telling me about vulnerabilities I may have. Rather than going through screen after screen of tools in my vulnerability alert service to configure my alerts, I'd like to be able to publish a list of software/tools in use to them (including versions) and then have them alert me when they know one of my components has a potential security flaw.

Sure, I'll still have to validate the vulnerability announcement. I'll still have to see whether my implementation, technique, etc. is vulnerable to the specific exploit, but at least I'd get a trimmed down list of things to worry about without going nuts.

Anyone ever seen a service for doing this or considered creating a module for any of the standard vulnerability scanners? I think it would be a valuable service and would save me and others a lot of time.

Security Evolved or Security Ignored?

I was reading a piece by Rudolph Araujo and it struck me how his analysis of the evolution of security is both spot-on, and also ignores quite a number of factors that I think are important.

Rudolph's point is that security is reactive to security threats and we develop security practices and defensive techniques only in reaction to attacks and new threats. I'd argue that warfare isn't all that different. In fact, I'm not sure of too many areas where there are attackers and defenders where this isn't the case. At the same time I do take issue with a few of his pronouncements that we're always reacting.

I started doing network and system security in 1994 or so. I was administering a network of SGI Indy systems on a college network and had to secure them against both outsiders as well as insiders. Some of the techniques we used to secure the machines and know our systems were good:

• Automated configuration management (homegrown tools)
• File integrity checking (tripwire)
• Restricted Shells
• Known-good builds (done by hand)
• Hardened defaults (services off, extensive logging enabled)
• Wietse Venema was a god, is probably still a god. Logdaemon and tcpwrappers were some of the best tools ever for securing a network.
  
• Network forensics via TAMU netlogger
• Automated log monitoring tools (home grown)
• Keeping up with patches
• Remote port checking (strobe)

Looking at the list above its pretty amazing both how far we've progressed, and how little in 13+ years. The number of truly new and useful tools for managing and securing systems just hasn't gone up that much. We knew back in 1994 that we needed to have automated configuration management, file integrity monitoring, hardened builds, etc. We knew we wanted good logging, network forensics, etc.

• How much different than tripwire in 1994 are file integrity monitors today?
• How much better is system logging than is was then?
• How much better are network forensics than they were then?
• Has anything gotten any better?
  

Maybe one reason we don't evolve is that we keep trying to reinvent the wheel in the security product space rather than just tuning tools we already have. Pretty much every item I list above is a major component of a tool we use today, but now I can buy it from 10 different vendors with a lot of hype, configuration options, and pretty much the exact same functionality you'd have used 13+ years ago. Is that progress? I'm not so sure.

I think the problem that is actually being highlighted is that is computers, like in car design and fashion, what was old is new again over and over.

Most of the components above get added together and get called NAC or autonomous systems.
We take networking scanning and such and add in a bit of vulnerability data and we get vulnerability scanners. Sort of useful, but maybe if I just turned off ports I'm not using and didn't have such a complicated setup the problem would fix itself.

For the most part we know what we need to do, we know how the attackers are going to attack, we've just spread ourselves so thin that we can't actually defend against them anymore.

We've seen the enemy, and it is us. The fundamental thing that needs to evolve isn't the technology, its our use of it. As we're growing our use of technology, pushing the technology further and further, we're coming to understand the human limits of running it.

Now that I'm helping manage security for a much larger organization 13+ years later I'm not worried (all that much) about new and novel attacks, I'm worried about tracking and managing the assets I have, how they are configured, managed, monitored, etc. I'm worried about who is using what data when, whether they are copying it, sending it, releasing it, etc.

Where we need the evolution is in systems that work better from the beginning. We need to make sure that the same old security problems don't keep coming up again and again and again.

• I need operating systems that ship without all services turned on.
• I need operating systems that let me easily set a security policy, and alert me to deviations.
• I need operating systems that monitor their integrity, tell me about deviations, and let me automate alerts.
• I need common logging across all of my devices so that I don't need a super complicated SEM to manage and interpret everything.
• I need a flying car

Ok, I threw the last one in because its always on everyone's wish list. What I'm getting at is that my wish list hasn't changed in more than a decade and I'm still waiting.

So, while in the end I don't necessarily disagree with Rudolph on the reactivity point - maybe things are even worse than he thinks. We've spent the last 15 years making pretty much zero progress on anything.

Microsoft's "The Security Development Lifecycle" - Chapter Two

Chapter 2: Current Software Development Methods Fail to Produce Secure Software
Chapter 1 Here

Chapter 2 of the SDL book focuses on other development methodologies and how successful they are in addressing security concerns and in actually delivering secure software. The premise is that existing software development methodologies don't produce secure code. The authors don't quite make the controversial claim that they cannot produce secure code, but that they don't in practice.

You could of course extend this claim to showing that pretty much nothing produces secure code since we both can't define and are reasonably sure it doesn't exist. Let's stick to their unstated premise though - current software development methodologies aren't focused enough on security to produce secure code. This seems like a more straightforward and fair reading of their intent.

Four claims are examined:

• "Given enough eyeballs, all bugs are shallow"
• Proprietary software development methods
• Agile software development methods
• Common Criteria (CC)

One slightly problematic issue with these 4 items is that they aren't all of the same type. The Common Criteria, while it is a method of specifying and testing for requirements, was never positioned as a mechanism for the development of secure software. It was positioned as a way to specify the security requirements for a system and evaluate whether they have been met.

That said, I can't find any fault with their analysis of the flaws of the "enough eyeballs" approach. We've seen again and again in regular products, open source or not, that lifetime of product and number of people working on it doesn't necessarily reduce bugs except in the presence of a methodology and requirement/goal to specifically do so.

Other than their potentially flawed analysis on the Common Criteria (and I'm willing to admit I'm not the expert on CC intent/design) I can't say I took much away from this chapter. We know that current software development practices are flawed, and I'm even willing to believe the MS-SDL is better - I wouldn't be reading the book otherwise.

.bank TLD - Still not convinced

I read Mikko's response to the .bank TLD criticism and I think I still have to take issue with a few of the things being proposed. Rsnake already had a nice writeup as well, hopefully I won't duplicate too much of it.

Mikko says:

People are stupid and would not notice such a new address scheme.

The main point of such a new TLD would not be that users would suddenly get a clue and would learn to read the web addresses correctly (although for those who do read the URLs, this would be obviously be an improvement). The main point is that it would allow the users' software to work better. Security software and browser toolbars would essentially have a "white list" to work with.

My main problem with this argument is I'm not at all clear on what software is going to do.

• Not let you visit non-.bank sites?
• Not let you enter your banking password on non-.bank sites?
• Strip links in email that don't say .bank?

I'm not sure that having a new domain gets us anywhere in actually stopping phishing, people getting fooled by this sort of thing, etc. It doesn't help with email security since you'd still have to sign email, you'd still need SPF, etc.

To Rsnake's point:

Now that you’ve read it, here are my thoughts. Yes, .bank will solve some heuristics problems. No, it won’t solve all of them. Banks hiring external marketing departments, regional divisions, loan offices, etc… etc… that all are owned by the parent will not be able to afford their own .bank TLD and will not be protected. Piggybacking off the parent URL is an equally bad idea for XSS phishing attacks. And if the banks allowed external organizations to piggyback how wold that solve your problem of extended validation of the site?

I face this issue all of the time. I don't want to host third-parties on my core domains for multiple reasons including cookie security. I do want them to have an EV cert (silly, but policy) and yet I still want people to semi-trust them. None of this is solved by having a .bank domain.

I'm just not sure what type of attacks this new TLD really prevents. If someone can give me a type of attack that it prevents I'll start thinking more seriously about it.

Microsoft's "The Security Development Lifecycle" - Chapter One

I started reading Microsoft's "The Security Development Lifecycle" a few weeks ago but got distracted and didn't finish. I figured I'd start the book over from the beginning and write commentary on a chapter-by-chapter basis. Hopefully this is useful if only for my own record keeping.

**********************************
Chapter 1 - Enough is Enough: The Threats Have Changed


Chapter One is an overview of why security is important, why everyone needs to be concerned about it, but specifically developers. I already buy the premise so the first chapter isn't exactly a hard sell. That said - I do have a few sections I find interesting and/or controversial.

Overall I agree with the definitions and distinctions made between Security and Privacy as concepts. Drawing this distinction isn't all that useful though for the general SDL practitioner. Its kind of a sad commentary on who the assumed audience is that the authors have to give this definition at all in the book. One disconcerting piece of this section though is their attempt to justify the SDL based on Privacy but not Security concerns. Justifying the SDL and software security in general is an extremely lengthly discussion and the subject of much debate about how much security to bake in, how many defects to fix, etc. Privacy is a big buzzword now though especially in places that are heavily regulated. Its a big stick just like SOX was 2-3 years ago to get management attention.

In their section on Reliability they mention an OpenBSD security/reliability item in BIND back from 2004. The OpenBSD team categorized the issue as one of reliability back then, and the authors appear to agree with this assessment. Little did they know this topic would explode again recently with another OpenBSD defect that the OpenBSD folks would try to categorize as a reliability issue but many folks disagreed. I have to say that I'm clearly in the reliability issues can be security issues camp and so I disagree with the author's position on this topic. I also disagree with their assessment that no major vendors distinguish between reliability and security concerns. Plenty of vendors post plenty of reliability patches that fix defects that aren't directly exploitable to cause an outage. If something can be exploited to cause both, it is both a reliability (availability) and a security defect.

In the next section on quality I'm a little confused. The book is supposed to be about securing software, but again takes a break and examines security failures in general.

In their section "Why Major Software Vendors Should Create More Secure Software" they take a bit of a jab at Apache based on the progress they finally made in shipping a more secure IIS. While they properly point out (I didn't check it, taking them at their word) that Apache had more security vulnerabilities/defects than did IIS in 2006, they make the leap that these were the cause of more compromises on Apache. Proper configuration management, ease of configuration management, and "secure by default" configurations go a long way towards achieving security and are part of the job of shipping "secure software." But to claim that the differential in Apache vs. IIS attacks is due solely to security defects is perhaps pushing the point a bit much.

Overall Chapter One is a decent start to the book though it moves between too many subject areas to focus on them enough in the space alloted. I know it gets better from here on in (I read ahead) but I think the intro could have been a little tighter.

Identity Theft Protection the Next Racket?

I saw a post by someone in security the other day asking whether anything could trump NAC as the big thing in security literature, conferences, etc. The only thing these days that is coming close is data disclosure protection tools. Things like Tablus, Vontu, etc.

In the consumer space things are a little different as to how vendors want to get a slice of the consumer's wallet. It used to be Anti-virus, then it was personal firewalls, and finally it was spyware detection and prevention. Based on recent trends I think there is an up-and-comer in the area of identity protection.

I previously blogged about Lifelock and just yeterday about Guardid. Seems like everywhere I look there is someone pitching a new product to protect the average consumer against identity theft. Even the banks and credit card companies are in the picture.

So, as a new thread on the blog I'm going to try and write about any of these I come across, good or bad, to see what we can find as this topic starts exploding.

If you know of any solutions in this area being marketed to the individual consumer as a protection device or service, let me know.


Follow-up: I started doing a little more research after I wrote the above and came across this article from Money Magazine back in August 2005 - The ID theft protection racket. I'm obviously not the frst person to notice this trend. The article makes for an interesting read actually, though it only reviews a few products. I think I will still do product reviews on things that look especially interesting from either a positive or negative perspective.

Snakeoil or Legitimate Product?

A friend forwarded me a link for the "ID Vault" asking whether it is bogus or not. After reading through the site I honestly can't tell whether this device is well intending or a complete waste of time.

The ID-Vault is a USB token with secure storage for passwords on it. For only $30 you get a token that can store 30 usernames and passwords and automate your logins to major financial sites with a single click and you entering your self-selected PIN. Quite pricey for the ability to store 40 usernames and passwords, but so far so good right?

As I look closer at the site though I start to get a little more disturbed. They keep talking about smartcards and such and they may actually use something like gemplus uses on their cards. But I'm not sure I see the point. All over the Guardid site I see all sorts of claims about this token being two-factor authentication, about how it will prevent identity theft, and how its tremendously secure as compared to typing in your password. All this is, is a token that auto-populates a web-browser with your username and password...

Several facts are clear:

• The card isn't really a smartcard. It doesn't appear to do crypto operations itself, and even if it does the data it is passing back and forth are usernames and passwords.
• The card purports to be more secure than typing in your username and password, but the threats it protects against (namely - malware) can read any of its data also. So, at best its a band-aid and as soon as it becomes popular the malware writers will target it just like the do other applications.
• There aren't any documents about how they protect against brute forcing the PIN.
• This token costs a lot for probably not a large increase, if any, in security.

Now, if folks like Citibank and others started actually issuing certificates you could store on your smartcard and authentication doing actual smartcard type things such as challenge-response, maybe this sort of things would catch on. There are already a large number of people in that field though and I don't think the Verisign, RSA, and Alladin folks are sweating Guardid much.

If I had $30 to spare I suppose I'd buy one of these silly things and do a real evaluation but it just doesn't feel worth it.

What Kind of Training is Important?

I was reading an article recently by Dave Ladd of Microsoft about security education vs. security training and it got me thinking about a conversation I had with Gary McGraw the other day.

We were discussing whether Ajax really represents a new attack vector. Gary was discussing the flaws as they relate to developers not understanding that they are pushing state to the client and that most of them don't understand the vulnerabilities of the client-side state they are creating.

I argued that the same is true for many web developers who don't have a firm grounding in technology fundamentals and use tools such as Struts for web development. Tools like Struts and other MVC web architectures abstract developers from how the web actually works are pretties it up for them in frameworks that let them pretend they are writing client-only applications. Most of the flaws that something like Ajax presents are just a new twist on "don't trust the client."

On the one hand this technique is amazingly productive from the developer point of view. They can develop according to well known ideas, constructs, and let the frameworks handle the fact they we're dealing with the web, HTTP, DNS, etc. Ideally developers shouldn't have to understand every bit of the technology stack they are using to get their job done.

The problem comes when these frameworks and this developer mentality meets the world of security. In security the fundamentals of the technologies being used actually are important, do determine what a developer can do, and expose vulnerabilities that a developer has to specifically understand in order to avoid.

When we think of training people on web application security we usually start from security first principles, but we don't usually start from technology first principles. We teach developers threat modeling, security requirements analysis, attack vectors, etc. What we often forget to teach them though are some of the technology fundamentals about the tools they are using.

I can't even begin to count the number of discussions I've had with web developers who don't understand HTTP basics, what the protocol actually looks like, what cookies really are, how browsers handle them, etc. They don't understand TCP/IP, DNS, ethernet, etc.

Without the basic understanding of things like the HTTP protocol, the fact that it truly is stateless, how cookies help graft state on top of it, and so on, a developer can't possibly hope to do a realistic job of threat analysis against their application. And if they aren't responsible for any of the low-level parsing of that type of data, they are never going to properly frame the discussion based on first principles.

When it comes to security education vs. security training, I'd prefer to start with the basics so that everyone is speaking the same language. As such, I think any good training program on security will include either formally, or informally, a number of sessions on technology fundamentals.

At most of my previous employers we started brown-bag lunch sessions to do basic knowledge transfer to everyone. Things like DNS-101, HTTP-101, Crypto-101, TCP/IP-101, and so on. We found that almost everyone with a desire to do the right thing and learn either attended if they didn't know the material, or was interested enough to ask questions afterwards to make sure they were up to speed.

These sorts of informal education sessions are invaluable for building credibility of the security folks, spreading knowledge throughout an organization, and creating a culture where knowledge is valued and respected.

Doing classes like these also helps with the security training you want to do as well. Once a sufficient number of folks are versed in the same basic vocabulary, its a lot easier to teach the advanced concepts and expect that they can apply their new background knowledge to more advanced things like threat modeling.

Under or Over Specify Security Requirements

In having a discussion today with a colleague about security architecture and SDL governance it struck me how hard writing proper security requirements is.

If you look at a standard such as PCI it jumps all over the place from high-level strategic (prevent intrusions) language to exacting specifications of how long passwords must be and what encryption algorithms and wireless security mechanisms must be used.

Compare PCI to another fairly comprehensive standard such as ISO-17799 and you'll be surprised how high-level and imprecise the ISO standard is.

In developing a set of security policies, standards, and then working with teams to specify project specific requirements we're often torn between specifying the goals we want to achieve, and the exact mechanisms and implementations that we believe will meet those goals.

The larger the organization gets the less often you'll get to be involved in a given project, interact with a given team, etc.

Its a tough balance to strike however between the security organization over specifying and under specifying.

In general we want to have fewer components, solutions, etc. to audit, have assurance over, etc. At the same time trying to standardize everything, especially in a development organization, risks killing the exact innovation you're trying to encourage.

There are certain cases where a regulation or auditor is going to force a certain standard on you that seems too specific to be in a high level standard or policy but which nevertheless is mandatory. This is why you find some many policies that specify exact encryption algorithms, exact wireless security mechanisms, etc. In a regulated arena you really don't have a choice but to make these standards.

Given my choice though I'm torn on where to draw the line between specifying basic security properties that each product/feature/system must meet, and writing requirements and standards so specific that only one technology or solution could possibly be judged compliant.

Preventing Software Security Liability Through Development Methodology

After reading the Theories paper by the badsoftware.com folks... I wanted to focus on the "Technological Risk Management" piece of puzzle. Let's assume for a minute that the "Fault" model of software liability won't work and evaluate then what constitutes effective "Technological Risk Management."

If we take the risk management approach we still need to determine what constitutes effective risk management in the software development lifecycle. We need some metrics to judge what SDLC models work for improving security, and which don't.

Reading through Howard and Lipner's SDL Book they make the categorical claim that though the SDL isn't necessarily the only way to improve software security, it is proven to work.

It gets me thinking about how we can create effective ways of measuring software development processes for their security oriented results. If we can, then we can start to baseline SDLC methodologies according to their security-risk-reduction potential to class them into good/bad/ugly and start to make decisions about what software we buy based on software development methodology alone.

That said, in all processes there is a lot of wiggle room. It is possible to write horrible software at the CMM-level-5 because the specifications aren't useful or the underlying idea is flawed. CMM-5 doesn't guarantee good software, it just guarantees we understand the process that created it.

There are several software specific SDLC's, I think I need to do a comparison of them to fully appreciate the differences between them before I can make a valid comparison.

• Microsoft SDL
• Cigital Touchpoints
• OWASP CLASP

Gary McGraw of Cigital has a nice blog entry giving an analysis of how their process differs from Microsoft's. I think one of these days I'm going to have to meet with the Cigital folks in person to get their take on appropriate approaches for a proper security development model for large online applications. Seems like in Gary's piece he doesn't believe that Microsoft's SDL is necessarily well-suited to the website environment.

I'm inclined to believe that all three of these approaches will yield good results if applied with some discipline and flexibility regardless of the underlying application. The problem is I can't try all three throughout my organization - so again I'm stuck making a non-empirical choice.

Software Engineering Disasters

I was reading Richard Bejtlich's blog piece on engineering disasters the other day and I started thinking about software engineering disasters. And by disasters I'm not thinking of things that were commercial flops, but rather things that were highly unreliable.

Risks Digest is chock-full of stories of software failures but I'm a little more interested in regular commercial software that is/was a complete failure. Things that simply never worked as desired, crashed more often than you could count, corrupted your data more often than you thought was possible, etc.

With that in mind my two top mentions for this category are:

• Windows ME
• Legato Networker (circa 2000/2001)

Windows ME I don't think needs a lot of introduction. The Wikipedia article does a good job of explaining why PCWorld called it the 4th worst tech product of all time.

Relatively high on my list, and a friend of mine's, is Legato Networker. Networker is a system backup program that once rivaled Veritas Backup software in the enterprise but has since shrunk. The thing I remember most about Networker was its main catalog daemon that seemed to crash pretty much every chance it got, and in doing so would completely corrupt the backup catalog forcing you to restore a previous version form tape. It got so bad we started calling the daemon the "Catalog Corruption Daemon" since that seemed to be its sole purpose in life.

I'd be interested to see what other pieces of truly abysmal pieces of software we can come up with that simply never worked as promised.



http://taosecurity.blogspot.com/2005/09/engineering-disaster-lessons-for.html

Don't Let PCI turn into FISMA

When I attended the San Jose OWASP meeting a week ago Bernie Weidel gave a briefing on PCI compliance related to Web Application Security.

During his presentation he talked about how to get involved with setting/influencing the PCI standards themselves. I made a remark that even if we all got together and weakened the standard as part of the PCI governance process, the Card providers (Visa, MasterCard, etc) would simply revert to their own standards. Bernie looked shocked that a security person would recommend weakening a standard. To a large extent I stand by my remark and perhaps it can best be explained in relation to FISMA.

Much has been written on the flaws in the FISMA approach which focuses too much on paperwork-level compliance and not enough of effectiveness of controls, and leeway to implement appropriate controls for a given environment. Richard Bejtlich even has an outline of how things could be improved.

In light of complaints about FISMA I think we can learn what to do and not to do with respect to PCI. The folks over at Ambersail even asked "What would you change?"

For me - the biggest things I'd change would be related to flexibility in implementation of a security program - and much more explicit linking of the PCI standard and the auditing guidelines. Nothing is more frustrating than trying to implement a proper security program, and having to constantly go to one's auditor and explain a new set of controls being explored, have them turn around and get clarification from Visa, and finally get back to you about whether Visa approves.

Just like in the FISMA case where folks spend a lot more time documenting than they do an actual security processes, PCI has the possibility of failing this way.

I work for a rather large financial services firm. It is in our best interests financially to exceed PCI security requirements in almost all cases. If I do this and create my own documentation, controls, etc. around achieving a level of security I consider appropriate, each new regulation and standard that comes out is simply more overhead for me. It doesn't add to my security, it just forces me to fill out more audit documentation, spend more time and money on auditors, without adding anything to my bottom line from a security perspective.

Unified/universal standards are often the solution to this problem, so that I can pass one audit, and provide those details in the same format to all of my partners to demonstrate compliance with their security requirements. What I don't need are multiple overlapping standards that cost me extra money without improving my security.

You can argue that most merchants and processors aren't going to comply without a stronger standard with lots of mandatory audits and control points. And you may be right. But from the seat I'm in more mandatory audits simply costs me money that I could better spend on improving my security, not on auditors and paperwork.

More on how companies use weaker standards and federal standards to weaken state-by-state approaches in a later post.

More on Software Liability

So, I finally got around to doing some more research on the topic and there is quite the treasure-trove of information out there.

Its funny how many problems and issues is computing and computer security have been thought of before and you just have to go looking. In the area of computer security someone once said to me

All the good work on computer security was done in the 1960's, everything since then has just been relearning old lessons.

So, as I was saying I started doing some research on the topic and besides the more recent Schneier pieces about it I've found some much more formal treatments of the issue. And by "research" I really mean - google search for "software liability."

Back to the story. I found a couple of interesting links about it:

• Bad Software: What To Do When Software Fails.
• Stanford Class on the issue.

There are others, but those should be a good start for reading since the badsoftware.com site has a ton of data.

Makes me remember that I ought to register for the Workshop on the Economics of Information Security coming up in June. In the end it comes down to an economics argument, and possible some finely nuanced questions. One little snippet I'll quote from the bad software folks relates to something my friend Adam sent me on this subject.

I think this is one of those problems that is inherent in general purpose tooling… screwdrivers, hammers, and the like. Maybe the PC and the general purpose SW on it are like a screwdriver/hammer/pliers kind of kit. And it’s difficult to hold the mfr, the hw store, or anyone else liable for general mayhem you perform with a tool. Only really specific things, like the head of the hammer flies off in the most traditional use, etc. On that analogy you could perhaps establish “traditional use” standards, like a std C lib has been around long enough that is has to protect against certain kinds of buffer overruns. It’s so classic it’s like putting a nail in a wall. But that wouldn’t help you with anything new… ?

The interesting reply comes from the badsoftware folks...

I won't explore the nuances of the definitional discussions here. Instead, here's a simplification that makes the legal problem clear. Suppose we define a defect as failure to meet the specification. What happens when the program does something obviously bad (crashes your hard disk) that was never covered in the spec? Surely, the law shouldn't classify this as non-defective. On the other hand, suppose we define a defect as any aspect of the program that makes it unfit for use. Unfit for who? What use? When? And what is it about the program that makes it unfit? If a customer specified an impossibly complex user interface, and the seller built a program that matches that spec, is it the seller's fault if the program is too hard to use? Under one definition, the law will sometimes fail to compensate buyers of products that are genuinely, seriously defective. Under the other definition, the law will sometimes force sellers to pay buyers even when the product is not defective at all.

This is a classic problem in classification systems. A decision rule that is less complex than the situation being classified will make mistakes. Sometimes buyers will lose when they should win. Sometimes sellers will lose. Both sides will have great stories of unfairness to print in the newspapers.

Second problem with the fault-based approach: We don't know how to define "competence" when we're talking about software development or software testing services. I'll come back to this later, in the discussion of professional liability.

Third problem: I don't know how to make a software product that has zero defects. Despite results that show we can dramatically reduce the number of coding errors (Ferguson, Humphrey, Khajenoori, Macke, & Matuya, 1997; Humphrey, 1997), I don't think anyone else knows how to make zero-defect software either. If we create too much pressure on software developers to make perfect products, they'll all go bankrupt and the industry will go away.

In sum, finding fault has appeal, but it has its limits as a basis for liability.

I hope I haven't quoted Cem Kaner too much here, seems like this is reasonably fair use...

A few things to think about anyway. More when I've done a little more reading.

It can't be done

I feel that I'd be remiss in my duties if I didn't respond to my previous post on Preventing HTTP response splitting with request/response identifiers? with a clarification that it can't be done.

It reminds me of a scene from the movie Awakenings...

Dr. Malcolm Sayer: I was to extract one decagram of miolyn from four tons of earthworms.
Hospital Director: Really?
Dr. Malcolm Sayer: Yes. I was on that project for five years. I was the only one who believed in it, everyone else said it couldn't be done.
Dr. Kaufman: It can't.
Dr. Malcolm Sayer: I know that now, I proved it.

So, I proposed my little scheme for preventing HTTP Response Splitting and Amit Klein was nice enough to point out all of the flaws in my argument and scheme. I don't feel like a beaten man though. In all fairness the HTTP protocol and HTML are lacking a whole bunch of security features that makes certain attacks all but inevitable - or at least not preventable through architectural means...

Look for more crackpot security schemes here in the near future.

Security metrics and developer training/certification

I was reading up on the new SANS Software Security Institute and its an interesting concept. One debate that been raging for a long time though, is the question of what types of certifications we want for certain things...

• Multiple Choice
• Multiple Choice + Freeform answer
• Both of the above plus a hands-on component

In the case of secure programming I'm fairly committed to a hands-on component of any sort of certification. Partially its a question of basic knowledge versus application. I'll be interested to see whether we have a way of benchmarking how good the code is that certified developers write vs. other people.

It occurs to me that the SANS certification might be more useful for those reviewing code for security flaws, rather than those writing code. We're not asking the test-taker to produce anything, but we are asking them to review code in the test and find/explain flaws. When it comes to hiring time I'm more likely to consider this a meaningful cert for those who want to do reviews, pen-tests, etc. rather than those I want to write secure code. Or, more precisely, its more of a standalone credential for the tester/reviewer than it is for the developer.

On to a slightly related topic - Metrics.

One of my current problems is determining how I'm going to measure the success of my application security program. What sorts of metrics do we care about? A few things that spring to mind are:

• Defect rates (per lines of code, module, etc)
  
• Individual/group error/defect rate
  
• Success of process at catching defects in either arch/design/implementation early
• Code/site coverage using standard toolkits/frameworks for things like input validation, output filtering, etc.
• Remediation time for defects

Management speak/philosophy tells us that we get what we measure. What we hold people accountable for, and how we create incentives, determines what people produce. With that in mind, how do we structure our metrics to get the outcome we want.

I think unfortunately that its going to be an experiment of putting in place some metrics, seeing how they influence people's behavior, and then modifying them on an ongoing basis to get the results I want. One critical aspect of this approach of course if that you need to have easy to gather metrics that don't require a lot of human intervention to generate. Otherwise you can't do a lot of iteration over it.

More on this as I think of it. Reading through Microsoft's SDL book right now and hopefully I'll get a few ideas there.

Identity Theft Protection?

A friend sent me a link today about an Identity Theft Protection service called Lifelock. http://www.lifelock.com.

I'm not sure what to make of the service, and I'm not sure I understand what regulatory regime it operates under.

They claim to aggregate multiple freely available services for protecting yourself from identity theft, etc. Its an interesting idea, though its unfortunate that the state of affairs in the US for data and personal privacy is that I have to pay money to protect myself from identity theft, rather than all of the onus being on the people already holding my data not to mess things up.

Since a friend sent this to me, I'll quote his mail and then give what I think are reasonable answers...

This is interesting … do you think their model is credible?

The obvious vulnerabilities to me seemed like

(1) lifelock going out of business

(2) lifelock employees or affiliates compromising you

(3) a criminal learns you are a member and either

(a) also gets your phone physically or (b) gets your number transferred to a new phone account somewhere else, which can be done remotely with the phone acct number and ssn.

Then opens an account and, acting as you via your phone, allows the action.

(4) criminal compromises whatever token you use to identify yourself to lifelock, then calls up (or log in), pretends to be you, changes the contact phone number to a new number, and he’s off to the races

1. Entirely possible. It isn't clear based on past internet company bankruptcies exactly how the disposition of their private data was handled. Since they aren't necessarily regulated as a bank, money transfer agent, phone company, etc. it isn't clear to me exactly what regulations would apply to them, who buys them, etc.

2. Entirely possible, and hard to evaluate without knowing a lot about how they run their internal operations. I met some folks who ran security at MBNA and they were pretty over the top. Dual-control for everything, no one with root on Unix machines, etc. Whether they do the same thing or not is certainly be an interesting question.

3. Stealing phones, etc. is a risk for most people that rely on this sort of thing. As I've written about before in this blog about 2FA for certain financial service providers, its a hard problem to solve. Banks are required to eat the losses if they get defrauded this way, not sure what would apply in the Lifelock case. It is a current problem for most folks though that if someone has access to your physical mail for example that they can intercept lots of out of band communications destined for you, thus leading to impersonation.

4. Impersonation via cracking of authentication tokens isn't unique to Lifelock. What isn't clear is what your remedies will be when your information gets stolen. Assuming their service actually works, even if your information is stolen you'll get alerted to misuse of your identity, at least for certain cases.

What most disturbs me about the service though is that I need to purchase it at all. In other countries (notably places in Europe) there are already services provided by banks and credit firms that notify you every time your report is pulled, every time someone wants to get credit in our name, etc.

In the US we don't have equivalent protections, though they have been discussed at least briefly as part of the whole identity theft and breach notification regulations going round in most states and at the federal level.

Lifelock reminds me of the service the phone companies provide you to block telephone solicitation. They will put a block on your line so someone has to listen to a special recording, put in a code, etc. before they get connected to you. What is amazing is that the telephone company is the one selling your information in the first place, and now you're paying them to stop their customers from calling you. Pretty nice protection racket if you can get it.

At least Lifelock isn't a division of Experian.