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

The Chinese are at it again.  Canadian Business Online reports that the Chinese government has now required Chinese banks to stop using foreign information security technology.  You’ll find another good review of the regulation here at SiliconValley.com. The program is called Multi-Level Protection System (MLPS).  From these early reports, it’s hard to tell whether the Chinese government is genuinely concerned with foreign government spying or if this is just another effort to protect their own technology sector.  The articles did mention Cisco a lot, but I assumed that it’s because Huawei (a Chinese competitor) is getting deeply into the firewall business.  I expect that we will know more as the full story is reported in the media.

Before anyone gets too worked up about this, let’s remember that this type of thing happens all the time and in every major nation on the planet.  I personally remember conversations with several security pros in the U.S. government who described a quiet effort by a U.S. Security agency in the 1990s to curtail government use of a firewall technology built overseas.  We all know that the French required that encryption technology sold in France include keys so that government agencies could decrypt all traffic.  For a long time it was against the law to sell encryption technology in South Korea.  It is also very similar to the dispute between RIM and the governments of Saudi Arabia, Dubai, and India, don’t you think?

In this country, we often require that companies providing technology to the government make that technology inside the USA.  Our government also requires that U.S. banks use approved U.S. algorithms for encryption and data protection.  Finally, we have the International Trafficking in Arms Regulation (ITAR), which restricts technology that can be exported to other nations.  That’s been in place since 1976 and China was embargoed for a long time under ITAR.

And if we go back even earlier in the history of information security we could talk about the debate that raged around the crypto key length of the original Data Encryption Standard.  At the time it was rumored that the key link had been shortened from 64 bits to 56 bits, simply because the NSA did not have the computing power to effectively decrypt messages with a 64 bit key.  This is purely rumor, but I’m sure someone inside the People’s Republic is well acquainted with these restrictions on the use of security technology.

  As they say: “What goes around, comes around.”   So it’s reasonable to expect that the Chinese would also try some form of prohibition on the importation of security technology.  I only hope that their leaders will look back on all of these prior efforts and realize that these kinds of trade barriers hurt competitiveness and technology adoption.  I hope they will realize that general prohibitions are generally unproductive.  Otherwise they may spend several years and several billion dollars, while their own suppliers make the mistakes and learn the lessons of this industry.

Jim Molini, CISSP, CSSLP

I’m doing part 2 of my review of the CSIS paper on the human capital crisis in IT security.  I think anyone who’s ever participated in development of a certification program has dreamed of the kind of certification they describe in this report.  Wouldn’t it be great if we could build it and develop a group of world class security gurus?  This is the kind of “build it and they will come” scenario that makes me think of cornfields and Kevin Costner. 

However, I was surprised that the authors of this report could look at all of the certification work done over the past 20 years in the security profession and declare it “dangerous.”  In response, the commission would create a brand new organization that could start from scratch and come up with a technical certification program that would meet the needs of a diverse federal workforce.  As someone who was deeply involved in the design of the CSSLP certification, I can assure them that the devil is in the details.  Any one of the listed organizations could have built a certification program like the one described, but they didn’t.  There’s a reason for that.

Having worked on both the CISSP and the CSSLP I have also yearned for a more technical exam, possibly with code analysis.   I didn’t get what I wanted when we developed the CSSLP, but I’m now willing to admit that I could have been wrong in my initial assessment.  Although most technical security people will tell you that they’re happy to test their skills against a standard, it’s extraordinarily difficult to put a standard test onto paper (or into bits).  Then, how do you build equivalent tests using both Windows and Linux, or C++ and Java?  When you pair the subject matter experts up with the psychometricians, the discussions get messy.

IMO, the closest anyone has ever come in the federal government to this kind of program is the ISSEP concentration, started in 2004.  The ISSEP is a coordinated security concentration between the (ISC)² and the US National Security Agency.  It is a very tough concentration that tests candidates across a range of security engineering functions.  Incidentally, it also requires the CISSP as a base certification before a candidate can request the concentration.  It’s a very difficult technical program to complete and I wish the authors of this report had spent some time studying the lessons from the ISSEP.

So, in order to get this out onto the blog, I’m going to stop by asking 3 questions:

1. Did the committee perform an evaluation of the legal ramifications of this type of certification in the federal workforce?  If so, we should hear more about this in the report.
2. Did the committee look at lessons from the existing ISSEP program?  There was no mention of this program in the document, so it would help to hear about direct experience with a program that most closely matches the one they describe.
3. At least 10,000 highly skilled intrusion analysts have passed through the SOCs of the federal government in the past 15 years.  If we have fewer than 1000 today, why did so many of them fall behind the technology curve?  If there is a half-life on deep security expertise, we should consider addressing that issue before training another 10,000, shouldn’t we?

That’s my take on the issue – in two installments.  I hope that the authors will take some time to take a closer look at the problem.  If you think I’ve missed something, please add a comment and we can talk.

Best,

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

In a 9 – 0 ruling, the U.S. Supreme Court decided that employees do not have a right to privacy when using company phones to text each other.  The court’s ruling sent a clear message to privacy advocates worldwide, by saying that a supervisor’s search through employee text messages was in fact a search, but was not an “unreasonable” search, in their opinion last Friday.  I read about it in the Los Angeles Times here. 

A couple of things are interesting in this case.  First, the court apparently considered text messaging to be similar to any other public paging system.  So, in effect, it looks like sending a text message could be legally as open as calling someone through the Airport public address system.  I’m sure we will hear more about this in the future.

Second, the court rejected a broad interpretation of in individual’s right to privacy by the US 9th Circuit Court.  Normally, I wouldn’t be surprised if the 9^th  Circuit Court supported and privacy rights for pigeons on the San Francisco Bay Bridge.  However, many people, including me, wondered if the Supreme Court would broaden privacy protection, somehow.  In this ruling, it didn’t happen.

Under this ruling, it looks like your employer can have a closer look at text messages.  It might also extend to email messages in some future decision.  Certainly, a broader interpretation of privacy would have opened up the possibility of lawsuits for those of us who monitoring corporate networks.  The threat of lawsuits would have prevented many legal searches, simply because it would be too much trouble to defend.

Some people will say that the US is losing a right to individual privacy.  I’d have to disagree.  This ruling is putting privacy into perspective.  It’s also going to help protect information security professionals from baseless lawsuits as they perform legitimate monitoring for employers. 

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

Let me start by saying that I was wrong.  Yep.  That’s the best way to begin this post.  This morning I read on Wired.com that Google had officially stopped censoring search results inside the People’s Republic of China.  They ignored the naysayers and have stopped doing searches inside mainland China, instead asking users to go to their Hong Kong site for searches.  Of course, it’s not likely that people inside mainland China will be able to get unfiltered search results from Hong Kong, but that’s beside the issue. 

Most importantly, Google is risking their China business to meet their stated goal of unfiltered search.  The g-men stood on principle and took action in favor of Internet freedom.  Bravo.

Just as the issue itself had strong cultural overtones, (see my earlier post) anyone reading the post from outside the USA may wonder about the title. We have a euphemism inside the US for anyone who has to retract a statement or admit that they were wrong.  It is called “having to eat crow.”  A crow is a particularly obnoxious bird that tastes like a rat.  It’s hard to catch and very hard to stomach.  So it’s an appropriate comparison for having to admit that you’re wrong.  In this case, I’m contrite and happy to see that my original skepticism has been upended.

Right or wrong, the leadership team at Google made a particularly tough decision.  It’s nice to see that they stood on principle in the face of opposition.  And to CEO Eric Schmidt and everyone in the company, please accept my heartfelt apology for doubting your ability to execute on the plan.

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

Two days ago, President Obama announced that Howard Schmidt would be the new Whitehouse Cybersecurity Coordinator.  Howard deserves our thanks for taking the job.  It’s arguably the biggest information security job in the world, although it’s neither the most lucrative, nor the most rewarding job in our business.  His responsibility will far outweigh his authority, so it will be a miracle if he’s thanked for the job he’s done in 3 years, after the next presidential election.  He’s not a cabinet member or a secretary or even a director – he’s a coordinator.  He will be tasked with developing a national security plan that also respects individual privacy; something akin to building a perpetual motion machine.  Personally, I wondered if I should send him congratulations or condolences for this move.

So why would he do it?  Why would anyone do it?  

Personally, I would guess that he wanted to serve his country again.  Imagine that.  After a prestigious 40 year career, spanning government and industry, when he should be settling down, this guy volunteers to go into the political viper’s den (the beltway, not the Whitehouse) and do an impossible job that has no promotion potential.  He knows how bad it can be, because he’s been there before, but he signs up anyway.  As they say in Philadelphia – go figure.

In these difficult times, there is no shortage of heroes.  The spectacular feats of heroism by people fighting against the narco-trafficers in Mexico or those bringing peace and security to other parts of the world might make it hard for people in the technical community to feel like they’re making a difference.  In fact, I don’t know of anyone who would compare themselves to these protectors of the free world.  But we should also talk about the other people who have shown courage, dedication, and a sense of duty that would bring tears to your eyes. 

The next time I think of courage, dedication, and service, I’ll be looking in the direction of Washington, D.C. and remembering a guy named Schmidt, who took on a massive national security problem just because the President called. 

Thanks, Howard.

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

I noticed a recent article talking about additional fines for ChoicePoint.  They were fined for a second breach of security that occurred 4 years after the original intrusion.  This may be an extreme case, but it’s a tragic reminder of the importance of proactive security.

As you may recall, ChoicePoint became a poster child for data loss when a 2004 breach was discovered. They struggled for years as the fines piled up and subsequently sold themselves off piecemeal, with Reed Elsevier retaining the ChoicePoint name.  However, the story is not as important to me as the company they keep.

Nowadays, whenever someone writes about data breaches, they inevitably mention three names: ChoicePoint, TJX, and Heartland Systems.  This continual rehashing of past mistakes is doing massive harm to the brands that the companies have developed.  And in that, there are lessons here for every company that must make a claim about security.

If you are talking to your leadership team about spending for security, be sure to let them know that the cost of a positive brand image is many times the amount you will spend on computer security this year.  If your organization makes a spectacular blunder in the security space, you could be one of those names that gets bandied about any time someone needs a cheap joke about cyber crime.  No matter how much work you do after the breach, it probably won’t matter. 

Your job as a security professional is to translate these problems into business terms.  Start by estimating the annual value of your corporate brand. Then model a catastrophic security scenario and cost out the 10 year effort it could take to rebuild the brand, after the incident occurred.  Once you’ve done all that, the real value of good security might be more interesting to Management.

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