The CodeGuard Blog

After a long hiatus, I’m back at my blog again.  Sorry for the absence, but there were a number of reasons, many out of my control.  Nevertheless, I only try to bother other people when there’s something interesting to talk about. I’m sure none of you are lamenting the fact that you have a few extra hours available for other activities.  At least I hope not.

Today, I’m going to talk about a report I recently read from Coverity.  It’s called the Coverity Open Source Integrity Report 2010.  Each year they scan open source software for vulnerabilities and publish the results.  This year they included Google’s Android operating system in their scan.

There are a couple of things that I liked about the concept and process behind this report.  First, I have to be clear about one thing.  Showing hits from a scan tool does not mean that vulnerabilities exist.  Think of this as a patient showing symptoms of a disease.  It takes additional diagnosis to verify that the disease does exist.  However, with that knowledge, I think it’s helpful for the industry to have someone scanning large software projects for potential vulnerabilities. I’m certain that it helps Coverity improve the quality of their static analysis tool.  At the same time, publishing the results helps us establish baseline metrics for other projects.

A few years ago, I worked with an engineer who was asked to assess a large internal software project for a customer.  As part of the project, he benchmarked the software’s static analysis score against two similar sized projects in the open source community. This turned out to be a valuable benchmarking mechanism and simplified the decision on what to fix.  In many ways, we humans are better at making comparative analyses instead of independent assessments without a comparison.  If you want to test this theory, go out into an open field and throw a ball as far as you can.  How far did you throw it?  Now perform the same test on a football field. It will be much easier to estimate the distance.

Back to the report.  They compared Android to conventional open source software, saying that Open Source has an average vulnerability rate of 1 vulnerability per 1000 source lines of code (KSLOC).  This only represents security bugs, so it sounds reasonable.  Android’s average was 0.47 per KSLOC. 

Now, if I were writing a book, I’d get into the vagaries of the measurement process and what percentage of those vulnerabilities might actually be exploitable.  But this is a blog post, so I’ll get to the point.  If you are just getting started in the business of software security and need to talk to management, this kind of thing can help.  Starting with a static analysis tool and having a benchmark, you can begin to measure your own software and figure out how it compares to open source.  If you use a lot of open source software in your projects, you can probably estimate the amount of vulnerabilities introduced by that software and get a rough measure of the risk.  If the security of your software turns out to be much worse than software built by volunteers, tell that to management. If it comes out at release showing less than 1 vulnerability per KSLOC, say that too, but also look at the severity.  If nothing else, proposing this  kind of testing may be enough justification to purchase a copy of a good static analysis tool.  Then you will at least have a rough idea of the size of the software security job in front of you.

Having the work of years boiled down into a single statistic that you can use with senior managers will make it easier to manage up in your organization.  Managers like simple baseline measures and rules of thumb.  Once you have management support for your program, then the real work begins.  Good luck.

Jim Molini, CISSP, CSSLP

Another group of computer security sages has evaluated the information security situation worldwide and proposed finding and training more technical security professionals.  You can find the CSIS report here.  Look back on the history of information security and you’ll find that this is at least the 6^th crisis in human capital we’ve faced.  The emphasis this time (as has been stated before) is on hiring and training technical professionals who can perform security incident response and defense against the escalating attacks on national infrastructure.

I have to admit that my first reaction to this document was to think that they are saying, “The pipes in our building have been leaking for years.  We have to find more plumbers!”  It seemed that they were saying that finding more humans to address technology problems was essential.  I’m not sure that we have the option to scale our human resources like this.

They compare the crisis to 19^th century medicine, but there is a flaw in that argument. We didn’t engineer the 19^th century human.  I’d say that the problem is more similar to the early 20^th century automobile manufacturing process.  Henry Ford solved the problem of escalating complexity of manufacturing by standardizing and componentizing the design.  We should do the same for Internet security.  I’ve already talked about an idea for Digital Borders.  There are other ways to significantly reduce the number of attacks coming across the wire and it’s clear that we could cut the amount of crime in half with the money we’re currently spending on monitoring alone.  Some people will scream, but that’s the Internet. Right?

I wish people would speak more about ways to solve technology problems with technology, but I guess I’m an inherent optimist.  We could engineer our way out of many of our security problems, but I will also admit that it’s probably easier to just hire more plumbers.

Of course, it is also summertime and this is a blog, so I’ll answer the other side of their argument in my next post.  In a couple of days, I’ll address their concerns about the current state of certification.  In the meantime, please let me know if you agree or disagree with my first take on the issue.

Jim Molini, CISSP, CSSLP

I’m on vacation near St. Louis, working on the family farm for a few days. (Yes, I enjoy driving tractors and fixing fence in my spare time. It’s a big change from the day job.) So, with a few spare minutes, it’s about time that I updated the blog. Thanks for waiting.

I have a conundrum for all of you.

If a foreign nation parachuted soldiers into St. Louis, Missouri and started invading homes, I’m pretty certain that the US government would send in the military to defend us. That’s because it’s an attack on the homeland. However, if we use the Internet model, they’d tell those people to call the Saint Louis Police Department and give them the URL for a web page on how to defend oneself from foreign invaders.

Doesn’t that sound strange?

With the US government spending more than $10 billion this year on Cybersecurity – for the US government – isn’t it time they talked about protecting the rest of us?
So far, much of the protection money was spent on plans to fence off government networks. We’ve heard lots about fencing off government networks from people like Richard Clarke. To me, it’s like building a castle, while the peasants live outside. Is that what we want from our government?

I recommend that we discuss a more comprehensive option, called Digital Borders. I wrote about this back in 1997 in an article called “Electronic Borders: Defining and Protecting National Networks” for Computers and Security magazine, here. (I changed the name because of conflict with another type of border technology.) I’m posing the concept again, since the open Internet has failed to bring harmony to the digital world.

Digital Borders are nothing more than a way to define the territory of any individual nation on the Internet. Usually, that space would be defined as the logical space owned by servers and network connections located in the physical space of any nation. In that regard, those IP addresses are governed by that nation’s laws. Knowing about where your national interest begins and ends makes it easier to enforce laws and to keep foreign interests from interfering in your local business. If the government will do this for itself, why won’t it do the same thing for the rest of us?

Any government can get started with a digital border by licensing all data connections that transfer data to and from locations outside the physical borders of that nation. Yes, this is additional regulation, but it only affects those entities that make direct connections outside the nation. From that point, the people of the nation should decide how much control is exercised over those connections. Filtering known malware and attacks is a simple step that would do lots of good for the average Internet user.

I am not advocating a massive and intrusive firewall, similar to the one used by the People’s Republic of China. The level of control is a matter of public policy and should be debated in any nation that considers the concept. However, I’d at least like to have the debate. It’s time we stopped fooling ourselves about the risks of an uncontrolled Internet and began seriously discussing a comprehensive plan for protecting ourselves.

Jim Molini, CISSP, CSSLP

One of our readers recently asked me an interesting question.  He asked for recommendations about preparing for the CSSLP exam.  It was a good question and I figured I’d add a blog post, based on my answer.  So here it is for everyone:

There are several good ways to study for the CSSLP.  These days everyone is also interested in saving money, so I’ll outline an approach that requires minimal investment on your part.   

The preparation process should involve reading, learning, and practice.  Reading is a good place to start and there is no shortage of information about software security.  We’ve been doing software security for many years, so the principles are available online.

For Sale:

If you can purchase books, I’d recommend these:

The Security Development Lifecycle – by Michael Howard and Steve Lipner.

Software Security: Building Security In – by Gary McGraw

For Free

For free resources, you may want to read:

The State of the Art Report (SOAR) on Software Security Assurance is here.

There is general information available at the “Build Security In” website here.

Microsoft has a great set of security resources on the developer site, either at MSDN or available through the central security page here. 

To be fair, I looked for free how-to material at IBM and RSA on the same topic, because I respect their security programs, but did not see the same kinds of documents.  Most of the stuff I could find was intended to market a product or service offering.  If you think I missed something, please let me know and I’ll update the post.

OWASP talks about the top web threats here and that might help understand more about vulnerabilities.  Their development guide is also helpful.

I’ve compiled a few important papers on software security here on the site.  You may find that they will provide some additional perspective on major issues we’ve faced over the years.

—

All of these resources should help you get started.  I would also recommend looking through the domains and then selecting areas where you want to do some review.  If you work in the area of software, it would also be a good idea to review your own practices and look at how yours compare to those in the references.  This will help you to learn the reasoning behind the recommendations and should help you pass the exam.

Additionally, if you’re preparing and feel like you’re stuck, there is another commercial book, called the CSSLP Prep Guide by Alex Fry and Ronald Krutz.  I’m ambivalent about this one.  On one side, it contains many data points that might help you cram for the exam.  If this is your style, the book might help.  One the other side, I’m not sure that it’s very helpful beyond cramming for the exam.  I didn’t see good explanations of strategy or for why you might apply one approach over another.  I didn’t see any informed guidance or luminary insight that a practitioner might find valuable.  It seemed to be a compilation rather than a text.  From that perspective, I’m not sure that that it’s more valuable than Wikipedia.  To be transparent about this, I received a complimentary copy from the publisher, but as you can tell, I’m not a big fan of their approach.  Please make your own decisions.

Practice

Finally, practice, practice, practice.  You can practice at work by reviewing the SDLC inside your organization.  You can practice on your own by participating in security forums or working on open source projects.  You can practice with associates at some of the security professional societies. 

If you are not able to find a local community, participate in one of the online communities.  You will find developer communities for every major development language and large projects may start threads on software security too.  Working through Google or Bing would provide the best and most up to date information.

All of these things should help you get ready for the exam with a minimal financial investment.  For any of you who might be preparing for the CSSLP exam, good luck and stay in touch.  I’d like to know how it turns out.

Regards,
Jim Molini CISSP, CSSLP

This is the second in my series on Google’s threat to exit the People’s Republic of China.  You will get more out of this post, if you read my original post below.

OK.  Some people think I’m being too harsh on Google for their threat to stop filtering search results and exit China.  So here’s a bit more detail on my thinking.

I’m not mad at Google, I’m just astounded by their hubris.  Google, an 11 ½-year-old company, used a blog post, a 12-year-old Internet phenomenon, to threaten the government of China, which claims the heritage of a 2,231-year-old unified society and a 12,000-year-old culture.  So this little tiff sounds like a small child threatening a very old man on the street.

More significant is the fact that Google apparently does not understand Asian culture well enough to understand the consequences.  That’s what has gotten them into this political rat hole.

Most educated Chinese have a strong sense of history (like Koreans, Japanese, and other Asian people).  Many of them can tell you the names of allies – and traitors – during wars of the Three Kingdoms period, almost 2000 years ago.  Although their understanding of recent history has been distorted by political factions, it hasn’t affected their memories.  Yes, you might say that the G-men are doing a service for the little guy, but the man on the street does not appear to be as interested in full disclosure as the owners of a large search engine.  Funny how that works, isn’t it?

So after the accolades that Google received from the press for their initial threat, I have a feeling that one of the adults in the room talked to the management team about the enormity of this decision.  I’m sure that someone told them that this could be a 100-year decision.  It’s hard for me to imagine the Google CFO looking at a plan to exit the world’s second-largest economy for more than a generation.  It will be hard to maintain a P/E ratio on a stock that’s already 26 to 1 when the largest growth market on the planet is permanently out of reach.

China is taking its own path to modernization.  In the book, “The Elephant and the Dragon”, by Robyn Meredith, the author says that China is trying to follow Singapore’s model, where economic freedom is achieved with tight political control.  Whether we like it or not, it’s hard to imagine that any single person or company will change this.  Maybe that’s why Google is spending so much time being quiet about their recent threat.

Thinking more deeply about this, I have a feeling that this could be an early indicator of Google’s impending fall from greatness.  Hubris, lack of discipline, and externalizing problems are signs of early stage decline, according to a talk by Jim Collins.  Maybe we’re seeing a bigger problem here.

I’m not a big fan of someone who gives a nice speech and then fails to follow through.  However, I could forgive Google for backing away from this threat.  How about you?

Jim Molini, CISSP, CSSLP

Like most of you, I read about Google’s recent threat to exit China over an alleged hacking incident.  Apparently, Google found someone breaking into its network to steal intellectual property and monitor Chinese dissidents.  Aside from the spectacular headlines, I don’t expect much to come of this.  Call me jaded, but this sounds too much like public relations and too little like corporate direction.  In short, if you really think that Google will leave China for more than a month, I have a bridge I’d like to sell you.

I’d be happy to be proven wrong.  I hope that Google succeeds in convincing the People’s Republic to change their stance on censorship.  But I’m not holding my breath.  If Google leaves China and stays out, I will apologize a dozen times to the “Don’t be evil” guys.  But let’s not get ahead of ourselves.

Aside from the really great PR that Google received for threatening to stop censoring searches, I wonder if there is another reason for this sudden bout of indignation.  Could it be related to the recent revelations about Google’s click through practices?  Could it be that the lid was coming off this percolating scandal?  (BTW, thanks to Ryan Naraine for his blog post on this one.)

I had started this post after reading the initial reports, but shelved it, saying that I was being too cynical about another player in the IT industry.  I told myself to be more trusting of a company’s altruistic intent.  Then I read the post by Evgeny Morisov and realized that maybe there was a story here.  If the cynics are right, this would be much more devastating to Google’s image than any of the individual problems they face right now.  Regardless of their reason for making this threat, there is a big difference between waving the gun around and actually pulling the trigger.

But how could anyone tell if the g-men are really sincere?  I guess we’ll have to see how they respond to China’s recent dismissal of their request.  It’s been 24 days since they threatened to stop filtering searches.  That should have been enough time for them to figure out how to flip the switch.  Maybe we can wait until March 15 for them to make their final decision.  More on the decision in a future post.

Maybe people should start to push them forward toward this epic decision.  That’s the ticket. Let’s encourage Google to “do the right thing” and see how they respond.  Is anyone taking bets?

Jim Molini, CISSP, CSSLP

How often have we heard that before?  That’s what Radiant Software said about their Point of Sale (POS) terminal software in an interview with an Atlanta newspaper.  Radiant is being sued by several Southern restaurants for insecure POS implementations that cost each of them thousands.  Check out Wired.com’s article for a good technical overview of the situation.

So let’s take a look at the claims in the article.

1. The software allegedly stores all data from the mag stripe.  That’s a serious security problem if the data can be retrieved, because it would allow an intruder to duplicate a card.  Since only a small amount of magnetic stripe data is needed for a transaction, it’s especially bad if the software allows the data to be stored unencrypted.  I’ve seen many systems that fail to adequately protect card data and that’s why PCI standards were issued.
2. Installation security failures.  You can say that this is not the software maker’s fault, but the software maker will have to show that they provided secure configuration guidance to installers.  Anyone who’s built security software knows it’s important to provide installation and configuration guidance.  It’s very hard to build software that can be installed by a stooge.  If the software maker had provided installation guidelines that advised against broad back doors, it might have a better chance in court.
3. The vendor was arrogant.  Well, I’m not sure that one qualifies as a security failure, although arrogance is a lot more likely to piss customers off.  So this one is probably not going to make it through triage.

I can imagine that Radiant Software will say something like, “These were just a few of our systems, so it’s all the fault of the incompetent installer.”  It will be interesting to see if the court accepts that argument.  It will also be interesting to see how software maker and integrator defend themselves in this lawsuit.  If the claims are true, this case could serve as a precedent for future lawsuits of this nature.

Finally, if you build financial software and especially if you build POS software, PLEASE use the PCI standard and then call all of your integration partners to let them know that administrative back doors with common passwords are a really bad idea.

So what do you think?  Is any piece of software vulnerable in the hands of a bumbling installer?  Or should a financial software maker always define an operating environment that is resistant to attacks and train support personnel to configure the system correctly?  Where does the responsibility end?  I’d be interested in your comments.

Jim Molini, CISSP, CSSLP

I beat myself up this morning. It happened as I was reading the latest Microsoft Security Update Guide.  The guide has some charts from FIRST’s Common Vulnerability Scoring System (CVSS) on the severity of security vulnerabilities.

I realized as I read through the document that we are still in the very early stages of software security awareness.  Looking at the charts you will notice that more than 50% of discovered vulnerabilities are considered high severity.  Moreover, more than 50% of vulnerabilities are also considered low complexity exploits.  This means that anybody with time can still write software that breaks some kind of application running on your PC, or Mac, or Linux box, or phone.

That’s probably not big news to anyone who reads this blog.  So I’ll tell you why I really beat myself up.  It’s because I suddenly realized how futile it is for me to complain about cybercrime.  Some people will always try to break whatever we build.  It’s apparently coded into human DNA.  Additionally, it’s really hard to prosecute someone in St. Petersburg if they break into a system in St. Louis.  You know all of this too.

I’ve finally figured out that the ONLY thing we can reasonably do right now to significantly reduce hacking is to build more secure software.  This is based on the data.  

Hacking hasn’t slowed down in the past 5 years, it’s continued to increase.  However, the most notable trend we’ve seen is that the exploits have moved away from targeting the OS and toward applications.  Buffer overflows are less common as we’ve used tools to correct those problems.  Now it’s SQL Injection and Cross Site Scripting.   We are also seeing that the easiest way to compromise a machine is not directly through the OS, but through an exploitable driver. 

None of the changes in hacking have been driven by a law enforcement initiative.  It’s all been driven by more secure software.  That shouldn’t be a surprise, but it should be a call to action.

I promise that I won’t ever say “Why can’t we all just get along?” when it comes to attacks over the Internet.  Even though the original inventors of the Internet seemed to assume that fiction, it’s been proven wrong for more than 30 years.  Instead, I’ll begin asking every developer I know to build stronger software so that we can protect against the inevitable side of software – the cracker.

Jim Molini, CISSP, CSSLP

Whether they are stealing credit cards or breaking into banks, criminals have made things like SQL Injection attacks into “the new buffer overflow,” meaning that SQL injection is one of the most prevalent vulnerabilities on the net today.  Lots of people on the Internet will tell you how to fix a web page that is vulnerable to SQL Injection and many tools can tell you when you have a buffer overflow vulnerability.  These things are good, but they are attacking the problem piecemeal.  If you’re managing software security inside an organization, I have another idea.  Attack it earlier in the lifecycle, preferably in the Requirements and Design stage.

Like many buffer overflow attacks, SQL Injection relies on a system’s willingness to accept input that falls outside the scope of an acceptable data specification.  In short, it’s garbage, posing as tonight’s entrée.  If you put controls in place to sniff out the garbage, you can protect yourself from many of the bad things that happen to web sites today.  This also goes back to my running theme about addressing security throughout the lifecycle, instead of isolating your effort to the coding or test phase.

If you’re curious about the vulnerabilities discussed in this post, here are good links to basic info on SQL Injection and Buffer Overflow.  (Thanks Wikipedia.)

As you can see, these attacks (and others) rely on applications that fail to verify input.  The problem here is that most application designers don’t spend a lot of time specifying input and subsequently, don’t spend a lot of time designing input verification mechanisms.  For example, a person’s name might contain a hyphen ‘-‘ or an apostrophe (‘).  They are not alphabetic characters, but they are the only non-alpha characters that would reasonably be part of a person’s name. Right?  Believe it or not, some people use numbers in their names.  However, very few people use the backslash ‘\’.  Knowing this, we can specify rules about the name field in the requirements phase of our application design.

Take this single problem and multiply it by the variety of input fields in the standard web application.  If you attempt to solve the problem piecemeal, you will waste a lot of time.  For that reason, it’s better to design an input processor that can verify the basic information received by your application and also check for garbage that might damage your system.  How is that done?

First, you define the types of input you need and specify the range of values that may be assigned to specific fields.  Does any numeric value need to be larger than 32 million?  Can you differentiate between short strings (up to 256 bytes) and long strings?  Do you need to canonicalize any of your input data, such as for URLs?  If a specific input value will never need to record ‘\’ ‘/’ ‘%’ or other known escape characters, can you legally scrub it from the string before passing it along? 

In the design phase, design some form of input verification routine that will use available system calls to fix data before it is passed along to the application.  Input validation should be something that is consistent and parameterized so that the calling routine can provide meta data about the destination field.  Doing so will give you a more robust way to reuse the code.

Once you know what you need, don’t build it all yourself.  Different development environments provide tools to help with this.  Look at input validator routines for .NET or possibly using Strategy Patterns in Java or PHP.  Whatever you implement, try to stick as close as possible to your specification.  That way, you are less likely to allow garbage into your application.

Once you’ve built an input validation process, test this mechanism with fuzzing tools to make sure that it performs as advertised.  You might also consider extending this routine to include checking for naughty words or inappropriate submissions.  There are many ways to structure the functionality of this mechanism so that it improves the resilience of your application. 

If you follow these steps you are less likely to fall victim to the next attack.  As you can see, many input problems we see today result from our unwillingness to specify and validate input.  Start this process earlier in your SDLC to be sure that you don’t get bitten by the same set of bugs.

Jim Molini, CISSP, CSSLP

I’m in Boston to speak at the Embedded Systems Conference and it will give me a chance to talk about security with a variety of software developers.  Reaching devs and dev managers is important, since they are critical to the success of any security program.  Here are a few of the questions I’ll try to answer:

1. We’ve been writing software for more than 50 years.  Why haven’t we made more progress on the security problem?  Security is one of the most difficult software problems we will face in the next 40 years.  This is primarily because security is not just about telling a computer how to behave.  If it were, we’d have solved it by now.  Instead, security is a constantly changing battle with intelligent humans who are working to break what we have in place today.  If it were just about telling a computer to behave in a specific way, we would be finished by now.  However, we find that there are other smart people trying to defeat any new mechanisms we implement.
2. Why are there so many security bugs in software today?  I believe that security bugs reflect our security development practices of the last 15 years.  Most developers weren’t trained to design or build secure software, so it was easy for them to make mistakes.  That is an education problem.  Additionally, most of our security work has been focused on testing (pen testing, ethical hacking, system security scanning, etc.).  In short we have built an industry around the concept of “penetrate and patch.”  That’s no way to build secure software.
3. What can we do now?  In the US, there’s an old saying that goes “When you’re up to your ass in alligators, it’s hard to remember that you originally came in to drain the swamp.”  In other words, urgent problems often distract you from important problems.  We need to continue killing alligators while we spend time draining the swamp.  In software terms, we should continue testing, since that’s what we are good at.  However, we must also build the long term fundamentals of a strong software security program.  In my talk I will describe four basic steps.  Those steps are:
   1. Assess the security risk of any software you develop
   2. Define a baseline set of security standards that will guide software development inside your organization
   3. Implement security testing for code that could be exposed to attack
   4. Foster a baseline set of professional security skills that are appropriate to the risk level inside your organization

This may be a lot to say in a 1 hour presentation, but awareness is one of the best tools in our arsenal. For most security people, it’s probably not rocket science.  The rocket science will kick in as we translate traditional information security concepts to the world of software development.  Stay tuned.

Jim Molini, CISSP, CSSLP

I just took one of those online “spot the security bug” challenges they offer here at Microsoft. It was written by Michael Howard and Bryan Sullivan.  You can find it here if you would like to test your knowledge of code security.  I don’t write code for a living, but wondered how I’d stack up against the experts. 

So how did I do?  Uhhh… I didn’t get a zero, but let’s just say that I still have some homework to do if I ever want to work for Michael.

I wondered about that for a while, because I’m really not that bad at security.  I can find a few of my peers who will say I did pretty well writing questions for the CSSLP exam.  So why did I tank this test?  It distracted me for a bit.

Then I went back to look over the questions again and found that many of them were targeted at Web developers.  I’m not complaining about the test.  It’s a great way to raise awareness among the community and I really appreciate the work they did in preparing it.  However, I’m starting to see that some of my skills are becoming stale.  Like some of you who may be reading this, I haven’t been keeping up with the very latest software development technology.  Sure, I still write code in C# or Java.  I still read and write C/C++, but I’m not that clear on the intricacies of Web form injection vulnerabilities.  Never mind Adobe Flash® or Microsoft SilverLight®.

As I started imagining retirement, I thought back to the places I’d worked over the past 10 years.  Most of them still used COBOL for critical business applications.  (That’s good because COBOL was the first programming language I learned.)  All of them had a few servers running Windows NT or Solaris 2.x somewhere on the network because they were unable to upgrade the software.  From that perspective, maybe I can still be of some use to society.  To preserve at least a little bit of my pride, I told myself there were still places around the world that could use my skills.  (BTW, here’s the original Dilbert comic on COBOL and dinosaurs.)

Believe it or not, I expect to see more innovation around software security for legacy apps.  As organizations port more legacy applications to the Web via SOA, source code analysis will become more important for applications written in COBOL and C.  My quick Web search turned up only one tool for analyzing the security of COBOL code.  That came from Fortify Software. 

As I continued to look around, I saw a large open space for software security professionals of every type.  The software world is not monolithic.  We need people who understand Web Services as well as those who are focused on internal apps for corporations.  We also need people who can apply security concepts across a range of software implementations.  As we are seeing throughout the industry, security problems start well before the coding phase.  Poor security requirements lead to poor software security just as poor design leads to a poor implementation.

I’m not saying that anyone can become a software security professional.  If you’ve never written any code, you will spend lots of time learning the craft.  However, it’s also clear that good security goes beyond good code.  Maybe there’s still hope for someone like me.

Back in 2007, I heard a speaker talk about planned updates to an ISO standard.  In his presentation, he indicated that one of his colleagues had asked him to update the ISO standard to include language on “Information Assurance.”  To make a long story short, the ISO standards couldn’t accommodate an update if assurance meant “Security.”  However, too often, we find that entire federal departments say the word “Assurance” when they mean “Security.”  The Defense Department is the worst offender.

Dictionary.com says this:

1. Assurance – a positive declaration intended to give confidence.
2. Security – freedom from danger, risk, etc. 

This problem is almost as old as the Unix operating system.  Back then, some bright people in the intelligence community began using the term “assurance” because a purist engineer told them that no computer could truly be labeled “secure.”  Obviously, this happened in the days before “portable computers” or “Service Oriented Architecture,” but I digress.

Instead of saying “secure systems,” they said “assured systems” (which was a condensation of “security assured systems”) to please the theoreticians and an entire industry grew up to support this thing they call “assurance.”  It was further shortened to “information assurance” at some point in the 1990’s.

Fast forward to the 21^st Century and we find that many aspects of computing must be assured.  Safety assurance is important, as is reliability assurance.  If we travel from “The Beltway” to “The City,” we must stop saying “assurance” and start saying “security.”  If you’re starting to feel like an edge router, you’re not alone.

All of this might be entertaining, if there wasn’t a real underlying problem with the misuse of this term.  It turns out that saying security when we mean security helps us to balance risks.  If assurance only means security assurance, how can we do tradeoffs between security and safety?  Can we ever have safety assurance if every one of our software developers is looking over his or her shoulder at the security group?  Even if we could, could we teach a computer to understand the nuance?

For example, how would you interpret the following business requirement?  “The system must provide high assurance for all valve management safety processes.”  If you read ISO 15226, it means that the safety systems have to work.  If you read the SOAR report or any of the major DoD Assurance directives, it means that your safety systems should not have read up or write down.  These are two fundamentally different things.

So let’s begin reclaiming the language that our global audience understands.  When you want security – say security.

Jim Molini, CISSP, CSSLP

Dan Kaminsky was back at BlackHat this year talking about an SSL hack that would allow a web site to spoof other sites.  He shared the glory for this with Moxie Marlinspike, who also identified the same vulnerability.  The hack was an interesting attack, not against the design of SSL, but against the coding of certain SSL implementations.

The vulnerability is demonstrated by placing “\0” into a URL used to identify a subdomain.  Since some browsers translated “\0” into a single character (ASCII zero), some browsers failed to fully qualify the domain name of the site.  While looking into the problem, I originally wondered why any system would let you insert null characters into the name.  RFC 3986 says the following:

As a result, a common security concern for server implementations that handle a URI, either as a whole or split into separate components, is proper interpretation of the octet data represented by the characters and percent-encodings within that URI.

It went on to say that the ‘\’ character should be handled with care, along with things like: ‘/’, ‘.’, ‘..’, and others. That made sense.  The fact that someone strung together the characters ‘\’ and ‘0’ should not have made any difference when the URL was processed by the browser.  Although nothing should have happened, it apparently did in certain browsers.  It could have happened when the parsing algorithm passed the byte sequence off to a routine that reprocessed the characters according to standard C/C++ tokenizing rules.  This is a classic coding error that exposes an underlying vulnerability.  Your attempt to correctly implement a standard syntax is obstructed by the tools you use.  It’s also notoriously difficult to spot in any type of code review.

Now, you may ask, did this really represent a coding error or should they have specified the syntax of URLs to exclude ambiguous interpretations.  We see many crypto standards specifying rules to prevent ambiguity, should it have happened here?  Before you answer, remember that these standards must be interpreted for both English language sites and those that use alternate character sets.  I’m interested in hearing what you think.

Jim Molini, CISSP, CSSLP

One of the projects I’ve been working on recently is to prepare a reading list for software security professionals.  Over the years it has become increasingly difficult to find the right reference papers on topics that should be of interest to all of us.  The hardest paper to find is the paper that described the original Clark – Wilson integrity model.  However, after 5 years of searching, I found it and uploaded it to the Papers directory here on the site.  You can download here from this site.

I tracked down the Clark-Wilson paper precisely because it was so difficult to find.  It was presented in 1987, the year before the IEEE began storing Security & Privacy conference proceedings online.  Therefore, it was relatively easy to find Brewer Nash (published in 1988), but almost impossible to find Clark Wilson.  Even the references to the paper are missing data that you can only find in their original text.  Other integrity models are available through other channels, but I had never seen a source on the Internet for this specific document.  So I finally found a copy at Stony Brook University in New York and uploaded it as a service to the community. 

Why?

I think that this model is important for a few reasons.  First, Clark-Wilson is one of the early models that successfully described a workable approach to data integrity.  I was not impressed with Bibabecause it appeared to merely rehash Bell-LaPadula, replacing disclosure with integrity.  I did not see in Biba the specialized attention that integrity controls required.  Brewer-Nash (aka “Chinese Wall”) was a good paper, but still relied on users to control their own actions.  Clark-Wilson, however, seems to work without special “struts.”  It is also most compatible with modern object oriented systems, IMO. 

In a well formed OO system, data transformation is bound to the entity that hosts the data.  This is compatible with the concept of the Transformation Procedure.  Moreover, the concept of a Constrained Data Item can be implemented through a variety of object interface management methods, like getters and setters.  So Clark-Wilson gets my vote for best integrity model from the early offerings.  There have been improvements.  I’ll talk about them in a future post.

Until then, look through the model.  Think about how it could improve the quality of your system.  Then post a comment to let me know if you agree or not.  I’d be interested to hear your perspectives. 

Jim Molini, CISSP, CSSLP

If you develop software under contract to another organization, you will probably find that you must create a security development lifecycle (SDL) that is different than the in-house model I discussed last week.  Security under contract includes custom software development work done by local, as well as offshore software development houses for customers.  This is how we developed software for the US Space Program and how many large organizations develop or maintain their critical applications.  Developing software for someone else means that you must meet their standards, regardless of your own expectations.  If you fail to meet their minimum standards, you may open yourself to legal liability.  If you exceed their expectations, you may find that you are underbid by another development shop for future work.  How do you reach the right balance?

First you must understand the client’s perspective on software security.  Are they risk tolerant or risk averse?  Do they know enough to be concerned about the possible vulnerabilities in the application you are developing?  Clients often tip their hands about risk tolerance in their initial request for proposal (RFP).  Read the entire RFP and look for broad statements about security.  Even if the requirements section is thin, you may find that the policy section mandates more security than the specification does.  If you see this, you know that you will have to ask additional questions.  This is also a good time to educate your client on the specifics of software development security.  Explain the risk of poor application security and the cost of building security in.

You will demonstrate the added value of your SDL in your proposal.  If you’re already under contract, talk about it anyway.  Be sure to show how you can improve the security of your work at a reasonable cost.  If you can’t be accurate in your cost estimation process, your SDL and your project will fail.  It’s that simple.  Your SDL should be efficient and based on a known standard.  Clients like it when contractors adhere to independent standards so you should be able to favorably compare your operations to those of other well-known organizations.  In that regard, your CSSLP certification should help you to establish your own credibility.

Doing security under contract means that you will spend more time tuning security requirements.  Get this right or you will pay for it later.  I still remember a government contractor who delivered an unusable application and then blamed it on the customer, saying, “You didn’t provide us with any performance requirements.”  In my opinion, this type of behavior borders on professional negligence.  If you fail to ask about security requirements and fail to provide feedback on the impacts of those requirements, you should not expect much repeat business.  If, however, you ask about security requirements, explain the risk and are told that your client cannot afford the kind of security you offer, define a set that is affordable until both sides understand both the risk and the cost.

Once you have estimated the cost of security, it’s your job to make sure that you can effectively deliver the level of control that your client has specified.  Good security design makes all the difference here.  Security under contract means that you should optimize your security mechanisms to the client’s environment.  Build to their authentication system.  Report in a way that is compatible with their auditing standard.  Work with their access control system where possible.  If you build your software for multiple clients, abstract these interfaces into an API.  Doing these things will dramatically improve the psychological acceptability of your system and is often something that they are willing to pay for.

You should build your security mechanisms with the expectation that they will be used and tested by a third party.  This is a common feature of many government software projects and you have to be ready for it.  It’s harder because a third party may not use the software as you intended it.  This will add time to the delivery phase of your application.

Finally, consider security during the system maintenance cycle.  Document your security features well and show how the security of the application can be upgraded to stay compatible with evolving technology.  If you do things right, you may find yourself under contract for 10 or 15 years.  This is not unusual for large contract jobs.  However, if you do security poorly, you may find yourself replaced because you don’t have the necessary differentiators to be considered a long-term partner.

The other major delivery model addresses security for Independent Software Vendors (ISVs).  ISVs require the most sophisticated and diverse model for an SDL.  It’s impossible to address that model in a blog, so I’ll move onto other topics unless I hear of interest from you, the readers.

Jim Molini, CISSP, CSSLP