|
|
|
 |
|
Show printable version |
Send this article to a friend |
|
|
| Posted by: phiber on March 21, 2001 |
Documenting what we know remains a challenge in the computer security profession. Various
resources exist: the Internet, web pages on intranets, articles, email, and technical
white papers. White papers are probably the most formal method, and they have the
advantage of wide dissemination. These documents usually speak to a specific issue in
depth. The range varies though with respect to the quality of coverage. |
|
|
Here's a sampling of titles from the Mind Share Systems, Inc. website:
"Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery" by Russell L. Brand
"An Architectural Overview of Unix Network Security" by Robert B. Reinhardt
"Unix Password Security" by Walter Belgers
The practical questions to ask about security white papers revolve around their effectiveness. When should I use them? What benefits do they provide? How can I judge their validity and reliability?
<b>Using White Papers</b>
When facing a new challenge — perhaps you are new to Unix and Unix security issues — reading "Unix Password Security" saves a great deal of time. Cutting straight to the main issues eliminates much tedious introductory material found in textbooks. Or, if you are installing say a bastion host for the first time, a paper may provide step-by-step instructions.
Or you may simply desire a broad overview or perspective on a topic. For example, attending a technical seminar or business meeting on a new topic may prompt doing some homework in advance.
Then the white paper's two main functions are to save time in absorbing new information, and to act as a checklist in undertaking new procedures. So close reading of the paper takes place at two levels. First, you read for knowledge or understanding. And second, you judge the reliability and validity of the paper's information. If the work being done is mission- or safety-critical, then evaluating the reliability and validity of the material becomes vital.
<b>Reading for Knowledge</b>
We live under a torrent of data. But, data is not knowledge. Only when data is placed in a proper context does it become more than a curiosity. The writer creates context through aids to the reader. These aids include good organization of the material, internal hyperlinking, and external ties or pointing to other resources.
Good organization could be an outline at the beginning of the white paper. Then, each major division in the outline equates to a section in the paper. Ideally, the document will be web pages so that each item in the outline hyperlinks to its section in the paper's main body. With information changing at a ferocious pace, web pages, easily updated, modular in organization, and internally referenced, provide flexible, current communication.
While the specific topics will vary according to the subject, an ideal sequence in a paper would be:
Statement of the Problem
Alternative Solutions
The Preferred Method
Troubleshooting or Implementation Steps
Other Sources for Information
Pointing to other materials not only gives the reader additional resources but also helps the reader update the material. External hyperlinks afford different, and hopefully, timely perspectives on the paper. If the author cannot update the paper directly, an external link to his or her website (or email address) gives the reader opportunities to obtain current information.
<b>Establishing Reliability and Validity</b>
Perhaps the most important hallmark for reliability is the white paper's date. Papers should supply an initial creation date and the date of the last revision. Ideally, the information should be posted right at the top of the article. And, preferably alongside the date, the author's name and brief biographical data should appear. "John Jones, Ass't Professor, Computer Science, Caltech"; or "Bob Peters, Network Engineer, Cisco Systems," for example, at least give us some idea of the white paper's author's qualifications. We need to ask, "Is the paper from a reliable, knowledgeable source?"
Of course, references in the paper's body and bibliography to recognized sources establish reliability further. (How dependable is the information? What is the track record of the source?) Look for recognized citations like "CERT Advisory CA-2001.03, VBS/OnTheFly (Anna Kournikova) Malicious Code" or "Guide to Handling a Worm Virus Attack on Microsoft Exchange Server 5.5." Always consider the background and reputation of the source. What makes them knowledgeable and authoritative about the issues involved?
Validity, how well the information corresponds to reality, rests upon the author's ability to recognize real-world problems. Does the paper's author understand only academic perspectives? Are only best-case scenarios considered?
Or, does the author admit where he or she could be uncertain? Does the author recognize logical flaws or questionable assumptions? Are caveats supplied to warn you about pitfalls? And, does the author discuss both the advantages and disadvantages of a particular course of action or procedure? Most important, does the author avoid questionable claims or outlandish statements? Terms like "absolute security," "impregnable," "foolproof," and "total protection" should raise a skeptical eye. Real security exists at differing degrees of insecurity, not at absolute levels.
This balanced approach can be very important, especially when doing mission-critical work. If you want recent examples, read the technical papers of Bruce Schneier or his latest book, Secrets and Lies. He rarely loses sight of real-world concerns when discussing computer security.
Finally, don't be afraid to check the validity of links and works cited in the paper. Don't forget Professor Kingsfield's warning to his students in the television show The Paper Chase, "Not all answers are found in books!" Call knowledgeable people and associates for their opinions and perspectives on the paper. They can be a real safety net when you are doing vital, critical work.
By Ronald Mendell (ronmen93@hotmail.com) for <a href="http://www.securityportal.com/articles/whitepapers20010320.html">SecurityPortal</a> |
 |
|
|
|
|
Show printable version |
Send this article to a friend
|
|
|
|
|
| |
