{"id":4392,"date":"2001-12-06T10:42:06","date_gmt":"2001-12-06T16:42:06","guid":{"rendered":"https:\/\/blog.socialmediaperformancegroup.com\/?p=4392"},"modified":"2001-12-06T10:42:06","modified_gmt":"2001-12-06T16:42:06","slug":"stratvantage-news-120601","status":"publish","type":"post","link":"https:\/\/stratvantage.com\/index.php\/2001\/12\/06\/stratvantage-news-120601\/","title":{"rendered":"StratVantage – The News \u2013 12\/06\/01"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
\n

\u00a0Software Quality and Cyberterror Threats, Part 2<\/i><\/b><\/h2>\n

Last SNS, I discussed the huge task confronting Richard Clarke, the counter terrorism expert in charge of the president’s Critical Infrastructure Protection Board<\/a>. Despite the disparate issues surrounding computer security, it is at bottom a software quality issue. If software were properly written, there would be a lot less cybercrime. In this issue, I\u2019ll examine some of the challenges businesses face in responding to computer security threats.<\/p>\n

In a recent issue<\/a> of his newsletter, Cryptogram<\/i>, renowned security expert Bruce Schneier, CTO of Counterpane Internet Security, explains the lifecycle of a security bug:<\/p>\n

I coined a term called the \u201cWindow of Exposure\u201d to explain the evolution of a security vulnerability over time. A vulnerability is a bug; it’s a programming mistake made by a programmer during the product’s development and not caught during testing. It’s an opening that someone can abuse to break into the computer or do something normally prohibited.<\/p>\n

Then, someone writes an exploit: an automatic tool that exercises the vulnerability. [. . .] Once a tool is written, anyone can exploit the vulnerability, regardless of his skill or understanding.[T]his tool can be distributed widely for zero cost, thereby giving everybody who wants it the ability. This is where \u201cscript kiddies\u201d come into play: people who use automatic attack tools to break into systems. Once a tool is written, the danger increases by orders of magnitude.<\/p>\n

Then, the software developer issues a patch. The danger decreases, but not as much as we’d like to think. A great many computers on the Internet don’t have their patches up to date; there are many examples of systems being broken into using vulnerabilities that should have been patched. I don’t fault the sysadmins for this; there are just too many patches, and many of them are sloppily written and poorly tested.So while the danger decreases, it never gets back down to zero.<\/p>\n

Microsoft operating systems have been the number 1 target of software crackers and cybercriminals over the past couple of years. One reason is there\u2019s an awful lot of installations of these OSes. That alone does not account for the truly staggering number of security bugs exhibited by release after release of these systems.<\/p>\n

Part of the problem, according to Schneier is Microsoft\u2019s and other software makers\u2019 attitude towards software vulnerabilities. Schneier makes the case that full disclosure of vulnerabilities and independent code review should be the rule and not the exception. Rather than maintaining closed code and stonewalling reports of problems, software vendors should open their code for expert review and not only acknowledge problems, but actively partner with software researchers to ferret out the bugs and exterminate them.<\/p>\n

This has not been the overall practice in the industry in general, and Microsoft in specific. Until relatively recently, Microsoft utilized the deny and disparage technique for dealing with security bug reports. If a researcher or talented amateur brought a bug to the company\u2019s attention, often Microsoft\u2019s first response was to deny its existence. If pressed, the company often disparaged the bug, calling the vulnerability \u201ctheoretical\u201d or minor. To be fair, the software monopoly has drastically changed its handling of security vulnerabilities in the last couple of years. And they are by no means the only offender; plenty of software companies employ the deny and disparage defense.<\/p>\n

When there isn\u2019t full disclosure about a software vulnerability, users have no way to evaluate the threat, and the advisability of using the software. Furthermore, wrong-headed legislation like the Digital Millennium Copyright Act (DMCA) complicates the issue. The DMCA makes it a crime to unravel security measures like encryption. In fact, a Russian citizen<\/a> is being held in jail today for breaking the encryption Adobe uses for its eBooks. The act was not a crime in his homeland, where he did the work, but when he traveled to the US for a conference, he was apprehended and thrown in jail. We can only hope he\u2019s not brought up before a military tribunal.<\/p>\n

It gets worse. As I discussed in a previous<\/a> SNS, an August 2000 court decision preventing cracker site www.2600.com<\/a> from linking to the outlawed DeCSS DVD cracking code has thrown open the whole question of hyperlinking. In addition to worrying about keeping cybercriminals out, businesses now need to worry about linking to criminal sites and criminal code, assuming they can keep up with what\u2019s illegal.<\/p>\n

Determining what\u2019s illegal and abiding by the law will get harder, thanks to the international Convention on Cybercrime<\/a>, which imposes some very interesting responsibilities upon signatory nations. This treaty<\/a> enables any signatory nation to enforce their cybercrime laws against citizens of other nations, and requires the cooperation of those other nations in bringing criminals to justice. This means if it is illegal to transmit a particular document, run a particular program, or link to a particular Web site in Bulgaria, a citizen in the US could be legally and criminally liable, despite abiding by US law. The US would cooperate with any Bulgarian warrant to search and seize assets of US companies or citizens in order to investigate the case.<\/p>\n

If that\u2019s not bad enough, the treaty also specifies that companies are liable for any cybercriminal actions of their employees if those actions were due to\u201cthe lack of supervision or control\u201d by the company. Thus businesses need to be cognizant of the cybercrime laws of the 31 nations that have so far signed the convention, must educate their employees on how to comply with all those laws, and then must keep tabs on their workers\u2019 behavior in order to avoid liability.<\/p>\n

All this has cast a chill upon computer security research. Trying to figure out if closed source code is vulnerable to attack could land you in jail. Schneier notes the case security researcher Niels Ferguson who found a security flaw in Intel’s HDCP Digital Video Encryption System. Ferguson did not publish the flaw due to fear of prosecution. \u201cIntel’s reaction was reminiscent of the pre-full-disclosure days: they dismissed the break as \u201ctheoretical\u201d and maintained that the system was still secure,\u201d said Schneier. \u201cImagine you’re thinking about buying Intel’s system. What do you do? You have no real information, so you have to trust either Ferguson or Intel.\u201d Since using the software could put you afoul of the law in another country, this is an important issue.<\/p>\n

So what is the computer software industry doing about all this? Are they banding together and taking a pledge of quality, determined to release no more buggy software lest they make their customers liable? I\u2019ll take a look at the industry response in Part 3 of this article.<\/p>\n

Briefly Noted<\/i><\/b><\/p>\n