Citation:
Article one: Robert Lemos(2002). "Security-flaw guidelines hit
pothole"
http://news.com.com/2100-1001-862994.html
Article two: Germanow,
A. Wysopal, C. Geer, D. Darby, C.(2002) "The Injustice of Insecure
Software". http://www.atstake.com/research/reports/atstake_injustice.pdf
Article three: James S. Rothfuss, Jeffrey W. Parrett "Go Ahead
Visit Those Websites, You Can't Get Hurt...Can You?". http://security.isu.edu/papers/Internet/Internet1.htm
Summary on Article one:
With the increasing number of vulnarablity, a draft guideline on
how security bugs in software should be responsibly disclosed to the
public was sent to the Internet Engineering Task Force (IETF). However
the draft was withdrawn because IETF, the organization that sets technical
standards on the Net, said in comments that human procedures are not
its purview.
The author further explained that the proposal outlines how and when
researchers should release information on software security holes
and the steps software makers should take to fix problems as soon
as possible. The aim of the draft is to help companies eliminate vulnerabilities,
help customers minimize the risk from security flaws, and provide
tools for identifying security holes and managing a company's response.
However, as the author mentioned, the draft doesn't hold software
makers to any set deadline to fix the problem. As long as the company
is acting in good faith, the proposal says, the researcher should
not make the information public. This can actually give major software
vendors, such as Microsoft, a breathing space.
The author also indicated that the writers of the draft will try
to find the proper forum to turn in the draft.
Summary on Article
Two:
In the article "The Injustice of Insecure Software", the
authors emphasize on the following points:
1. More and more flaws in software, together with increasing number
of security vulnerabilities demands a change in software design.
2. There are three kinds of risks that are caused by flaws in commercial
and custom software. Transferred risk means risk that a customer takes
by using a commercial product. Owned risk means risk a company takes
by building a solution in-house. Uncertainty means that company faces
risks regardless of the technology or solution deployed.
3. Software license contracts has always saved software vendors from
incurring liability from the risks they transfer to their customers,
however it is only a matter of time before a vendor is held responsible
for failing to address the security in a product.
4. Software vendors who care about risk transfer should expand traditional
quality assurance efforts with security tools and techniques that
answer the question "what can this software do that is should
not do?"
5. Security flaw persists because: increasing complexity in software
design, reduced product cycles, and there are flaws that can't be
handled by a single tool.
6. The current solution to software flaw mainly involves revealing
and patching. The researchers publish the existence of vulnerability
and force the vendors to fix the problem. However patching is only
a short-term fix, and has its problems, such as expensive, time consuming,
not on time.
7. Researches have shown that investing in security engineering can
yield attractive returns.
8. The bottom line of this change is secure software at release.
Summary of Article Three:
In the article "Go
Ahead Visit Those Websites, You Can't Get Hurt...Can You?" ,
the authors emphasize on the following points:
1. Web browsers are not
safe. Websites can exercise a lots of control over the local machine
through web browsers.
2. Common tools that can
be used by web server to gather information from or attach at users
include:
Article Analysis (Article one):
Here is the criteria used:
1. Clarity of Language
2. Bias
3. Technical Accuracy
4. Choice of Sources
Clarity of Language
The article is clearly presented, and the language is easy to understand.
However the author failed to explain exactly what "human procedure"
means in the draft, and how it will affect the feasibility of this
draft.
Bias
The article is clearly biased in the implication that the major software
vendors are the ones to benefit from this draft. That is, they are
using this draft to get some breathing space. Although this draft
is written by experts from two security companies, MITRE
and @stake, the author failed
to indicate what kind of benefits end users or security companies
can get. According to the article "The
Injustice of Insecure Software" written by @stake researchers,
they are obviously tired of having to urge or force software vendors
to fix problems. Sometimes it works well, especially with Sun in the
case of Java, who is willing to publish the source code and cooperate
actively. But most of the time, security watchers are dealing with
companies that are unwilling to release code and are unwilling to
tell end users about software flaws. It is under this situation that
security companies are calling for a standard that forces software
companies to take actions.
Technical Accuracy
Overall, this article contains very little information on flaws in
software, the causes, implications, possible solutions, and how does
this draft fit into the software flaw argument.
Choice of Sources
The article seems to be balanced by choosing speakers from security
companies and software vendors. However the quotation from the former
is centered on what to do next with the draft, while on the other
hand, the quotation from the latter is centered on what benefits they
can get from the draft.
Suggestions:
In all, this article leaves quite some questions unanswered, such
as what does "human procedure" mean in the draft, how it
will affect the feasibility of this draft, how can security companies,
users, vendors benefit from this draft, what might be the possible
destination of this draft. If the author added those information,
it will definitely be a more informative and fascinating article to
read.