Difference between revisions of "Team 7 Main"

Revision as of 07:53, 24 October 2005

The assignment mentions four bullets:

• "A plain English, no jargon description of attack techniques attempted..." etc.
• "Estimated dollar value of the damage..."
• "Estimated feasibility and strategic value of the attack technique to a terrorist organization."
• "Feasibility and cost of defending against such attacks."

These map onto the sections below as follows:

• The "executive summary" is just a summary of the report; we should leave until the rest is written.
• The "Attack Methodology" is the first bullet.
• The first subsection of the "Vulnerability Assessment" is the second bullet.
• The second subsection of the "Vulnerability Assessment" is the third bullet.
• The "Details: Defenses" is the fourth bullet.

Executive Summary

Attack Analysis

Methodology

Results

Summary of Defenses

Details: Vulnerability Assessment

Estimated Potential Damage

Estimated Attack Value for Terrorist Aims

Details: Defenses

[this is a first pass to help other people work off of and also comment. I'm going to bed, I'll do another pass tomorrow] [See some of my comments under discussion... Keunwoo Lee 00:53, 24 October 2005 (PDT)]

Software is very easy to distribute once it’s created. Also, software engineers and computer scientists are passionate about improving the state of the art, and the market of rapidly improving hardware and voracious consumer appetite has supported this rapid advancement. These very things have contributed to the large-scale insecurity present in our software infrastructure, but are also the primary reasons why it is cost effective to make software secure.
It’s true that the best protection against attacks is simply good administration and policy in the companies that distribute and use software. Having quality control and not allowing people to get hold of things like passwords is important, quite aside from technical issues. I argue that these costs will be largely incurred above and beyond simply avoiding software vulnerabilities, so here, we focus on technical costs.
Creation of software has a “pay once, benefit many people” or “pay once, benefit for a long time” dynamic. Software that’s created today can be pushed over the internet to millions of computers. In addition, software that’s created today provides a basis for future, more complex software, and its design aspects inform future designs, and thus the state of the art improves. The market is thus willing to invest in enhanced security, because there is feeling that we can drastically improve our security, that it’s not just an arms race.
There are three ways to avoid being damaged by exploits such as buffer overrun attacks. One is to lower the attack surface: don’t expose your program to input from the user in unnecessary ways; for example, don’t install potentially risky programs on a server by default. The second is to separate the attack points from critical systems; for example, our target executable for this exercise should have not run under administrative privileges. Or an internet browser could operate within a shell and not be able to affect the larger computer system. The third is to make the software itself free of vulnerabilities, and can be done by hiring talented developers, having an excellent process of quality control, and using good meta-software tools which make your software inherently resistant to exploits recover if a vulnerability is indeed exploited. It can also be achieved by having an efficient way to provide fixes for broken software.
Successfully pursuing all three of these items involves hiring talented and experienced developers and managers, which incurs perhaps a 10-20% overhead over hiring their less talented peers. Such developers can create good robust designs, and the creation of the better software is not more expensive beyond the initial cost of the people, who can do more with less time. Also, good design becomes cheaper over time, as the state of the art improves, and as people learn from the mistakes of the past.
The third item is particularly interesting, because its effectiveness doesn’t presuppose that people are flawless. So I will focus on some items here as fundamental and cost effective ways to achieve security.
In the short term, many companies, most notably Microsoft and Apple, have developed ways to push patches for broken software out to customers. Millions of customers regularly (perhaps monthly) receive updates that fix vulnerabilities. For some fixes, it is possible to “hotfix” the client software so that its host need not even reboot when it gets the patch. The technology behind hotfixing is improving. The cost of protecting customers from discovered vulnerabilities post-shipment has thus gone from prohibitive to relatively cheap in just a few years. The fixed cost to develop these mechanisms was large, but the recurring cost is small. A server can avoid being reliant on hotfixes by having multiple servers redundantly provide the same service. This is often necessary due to transaction volume anyway, and need not always be considered an additional cost.
The runtime environment software uses, or the construction of the software itself, can be inherently more secure. For example, Microsoft’s latest compilers provide buffer-overrun checking which cause the program to crash rather than execute nefarious code when a vulnerability is found. Even cooler, when such a thing happens, an error report can be sent to Microsoft, and Microsoft can then find and fix the issue. Recent versions of Linux provide Address Space Layout Randomization, which makes it difficult for hackers to use hardcoded values when making their attacks, and much more difficult to make viruses and worms. These mechanisms make newer software more secure almost for free, and either would have protected against our attack for this project.
Also, software can be made type-safe using languages like Java, C++/CLI, Ada, and C#. This prevents users from writing input to segments of the executing program which aren’t designated as accepting user input. Rewriting old software in type safe languages is quite expensive, but this cost can often be amortized by the fact that the software often needs to be rewritten for other reasons. Writing type-safe code has many other merits; it can actually improve developer productivity, as software bugs tend to be discovered at compile-time rather than run-time. However, not all software can be written in a type-safe language, either because it is impossible (some system code), or because the runtime performance impact of type-safety is often significant for time-critical applications.
All of the things listed here are cost-effective because (a) it is easy to distribute software, (b) it is easy to use protection mechanisms which can benefit all or most software, or (c) because costs of increasing software security are often the same as the costs of increasing software quality.