SD Secure Start
In this Issue:
>>SECURITY TIMEWARP: 7 Years, 5 Years, Today
The more things change, the more they stay the same. Securing our systems has been a hot topic since enterprise-wide network computing was in its infancy. Unfortunately, it's still a growing concern.
* * *
TODAY: SECURITY SOFTWARE IS NO SECURITY BLANKET
Don't worry about defending your operating system—first, check your security software! Formerly, OSes were the victim of choice for cracker attacks. But on Monday, June 20, 2005, the Boston-based analyst firm Yankee Group released a study of industry vulnerability data that reveals an ironic new target—the very software used to shore up system security. The group's 15-month analysis of ICAT, the computer vulnerability database from the Computer Security Division at the National Institute of Standards and Technology, reveals 77 vulnerabilities affecting a range of security products, with the rate of increased attacks matching that of the growth of the industry itself.
Unfortunately, the nature of security software—its elevated user privilege and wide reach throughout the operating system—makes it an inherently enticing target. But common sense can go a long way in the search for security.
The answer lies in personal responsibility, according to Yankee Group Senior Analyst Andrew Jaquith. "Vendors have to engineer security into the development application lifecycle, get developers to have core responsibility and give them the tools to do it."
He advises security software developers to conduct early and frequent design review, run nightly regression tests and frequent code base reviews, keep privilege levels and authorization management in the forefront, analyze component authentication, ferret out buffer overflows, and perform checkpoint reviews with security-knowledgeable people. "Basically, you can barrage the software at every major release with a penetration test."
—Laurie O'Connell, "False Protection," Sept. 2005
http://www.sdmagazine.com/documents/sdm0509a/
* * *
5 YEARS AGO: BUILDING BETTER CODE
"Vulnerabilities have been around since the first software," says Matt Bishop, associate professor at the University of California, Davis department of computer science. "There were two seminal studies in the 1970s about this. One was done by Bob Abbott and a group of people at Livermore Laboratories. They surveyed about 10 systems and built a classification scheme for the vulnerabilities they found. The Information Sciences Institute project, under Richard Busbee, published a similar study two years later. Their goal was to automate the detection of vulnerabilities. They didn't succeed, but they developed a very interesting classification of security flaws."
But that work lay dormant in the 1980s, according to Bishop—abandoned in favor of the belief that the technology at the time allowed the construction of secure systems without any vulnerabilities. It soon became evident that this was not true.
"You can't build systems without vulnerabilities," says Bishop, "and even if you could, you'd have problems with the operators and misconfigurations and such. In 1991, the folks at Purdue came out with a taxonomy of security flaws. I wrote one at the same time. Carl Landware, in the late 80s, had come out with one as well. They all boil down to this: Essentially, nothing's changed. The flaws described in the taxonomies were quite different, but you could basically map them on to one another. I'm coming up with a new one now, and again, I'm not seeing any development in the field. Techniques for writing good code and testing for vulnerabilities are not being used. Intrusion detection will help us spot things, but it's too late."
Many security professionals, though, are tired of hearing the same harangue about quality code. Bishop does acknowledge that "we're beginning to get a handle on how to scan programs for potential race conditions; once we've got a list of potential ones, we can go in and eliminate them." But, he notes, a classic attack from the late 1970s—buffer overflow—is still successfully penetrating systems today.
—Alexandra Weber Morales, "Intrusion Detection," Apr. 2000
http://www.sdmagazine.com/documents/sdm0004d/
* * *
7 YEARS BACK: LACK OF SECURITY AWARENESS
It may seem obvious by now that programmer awareness of security flaws leads to improved security in programs. But the extent to which programmers are unaware of security issues is sometimes mystifying to those of us who study information protection. While I have spent almost 20 years studying protection issues, most programmers spend less than a few weeks during their entire career.
One of my many responsibilities is managing a team of programmers who are not particularly aware of security issues. I try to alert them to issues, but it's sometimes hard to believe that they don't know about things that I find obvious. One such example is information assurance.
When you mention security, most people think about secrecy, but secrecy is really the least important aspect. Usually, integrity and availability of data and functions far outstrip secrecy in terms of programming requirements. Many of today's attackers spend their time and effort trying to prevent systems from working correctly rather than trying to steal some deep dark secret. Some of the most famous attacks of recent years include the SYN flood that denies services by sending SYN packets to a server on the Internet; and the huge PING packets that crash Internet servers when you send them a single packet.
A classic example was demonstrated on the World Wide Web when an attacker figured out that by sending a browser hundreds of recursively embedded tables to format, the browser would crash. It's an easy matter to limit recursion depth, but unless you think about the possibility of resource exhaustion, you're unlikely to protect your program from it.
The most pleasant side effect of pursuing information assurance is that everything you do to make programs resistant to malicious attempts to deny services and corrupt information also works to prevent accidental disruption. Anyone who uses computers extensively knows that system and program crashes are very frustrating, and people who study ergonomics know that user frustration links directly to product acceptance or rejection. By improving information assurance, product acceptance and reputation are enhanced.
—Fred Cohen, "Eliminating Common Security Faults," May 1998
http://www.sdmagazine.com/documents/sdm9805d/
>>NOMINATE NOW! DEADLINE EXTENDED
The 16th Annual Software Development Jolt Awards
Due to a flurry of requests, Software Development has extended the nomination deadline for the 16th Annual Software Development Jolt Product Excellence Awards to December 15, 2005. We're looking for the products and books that have made a difference to developers in 2005—products that have "jolted" the industry. The nomination fee is $200 per product. Nominations close December 15, 2005. Finalists will be announced in January 2006, and the winners will be honored at a gala ceremony on March 15, 2006, at SD West in Santa Clara, Calif., and in the June 2006 issue of Software Development.
To nominate your product, go to
https://www.sdmediagroup.com/view/jolt/jolt01.jsp
