|
ACM SIGSAC Review,
Vol. 6, No. 2, Summer 1988
A CASE STUDY IN CERTIFICATION AND ACCREDITATION
Bill Neugent
Heidelberg , West Germany
In the Department of Defense (DoD) , it takes longer to
read the rules about how to do a job than it takes to do the job. Because
of this, we have in the DoD two kinds of people: those who spend so much
time with the rules that they never get to the job, and those who do the
job without bothering about the rules.
|
For me, this dichotomy has given rise to personal dilemmas. Take the topic
of certification and accreditation. Having written the rules on
certification and accreditation, I come to this topic heavily encumbered.
I say encumbered, because only someone who has studied a topic and
written the rules can appreciate the topic’s fascinating complexity.
People interested only in doing a job have no appreciation for the
potential satisfaction available from such complexity.
Recently I was helping to manage the procurement of a network.
I pointed out to the program manager that, since the network would
process sensitive information, certification and accreditation were
needed for each system in the network. And I blissfully took it
upon myself to pursue the matter. |
John, the developer
Some people just dig in
and do the job |
Now the first step in certification and accreditation is
to find out who’s the boss, with respect to security. Obviously
one can assume this to be a straightforward step in the DoD, where there
is a rigid and well-defined chain of command. At least, that is what most
people would assume, who have never worked in the DoD. The reality is
that this first step can be one of the most entertaining parts of certification
and accreditation. Being no stranger to the DoD, I was hoping for fun
and found it. Most of the systems in my network seemed to fall into one
of five categories (Table 1).
Table 1 Categories Of Accreditation Responsibility
Category |
Description |
“Hello! Anybody home?” |
No one is responsible. Maybe a reorganization is in
progress. Maybe the boss has left and not yet been replaced. |
“We’ll get back to you on this.” |
Different people are responsible at different times,
or for different parts, or for different aspects of the same part. |
“It’s mine! No, it’s mine!” |
Two or more people assert it as their responsibility.
You cannot proceed without choosing sides, and subjecting yourself
to retribution from the other side(s). |
“Wait. Let’s think about this.” |
One person is clearly responsible, but no good will
come from getting him involved. |
“Why do you ask?” |
The organization operates many systems that process
sensitive data, and none of the systems have been certified or accredited.
The people don’t take kindly to outsiders coming in and asking
questions. |
To a conscientious neophyte, this game of "find the
boss" can be especially frustrating. That’s why it’s
important to remember that, in most cases, it doesn’t matter. I
learned
this many years ago, under the tutelage of a wise old bureaucrat. I had
written a technical report that needed to go out under the “old
man’s” signature. This was a big event for me, because it
was my opportunity to impress the boss with the quality of my work. The
wise old bureaucrat knew better. He took the report, saying, “Let
me show you how this is done.” He waited until just before the morning
staff meeting, and then rushed up to the boss. “Sir, I need your
signature on this right away,” he said. “Don’t worry:
it’s okay.”
Naturally, the benefits of this approach were not clear to me at the
time. Subsequently, after some experimentation on my own, I came to understand
its attraction.
Returning to the more recent past, I enjoyed the opportunity to track
down accreditors within my network. But what I really was looking forward
to was the technical analysis involved in certification. I had experience
doing this in Washington, but never “in the field.” To do
this, I first located the Theater coordinator. I asked him what forms
he used and whether he had his own local requirements for certification
and accreditation. Well, talk about service, he not only had the forms
for doing the security analysis, he had already filled
in the findings. All I had to do was fill in the blank spaces that
called for the name of the system and, of course, its location and list
of hardware.
The fellow explained that he had experienced problems in getting people
to do the necessary paperwork. As a result, many systems under his jurisdiction
were not accredited. This didn’t look good for him. With this new
approach, however, he’s been much more successful at getting the
right paperwork. Also, he said, some of the sites might even read the
package before they sign it, and thereby learn something about security.
Finally, since the paperwork is certain to be acceptable, neither the
field users nor the security managers have to worry about tricky judgments
or about the paperwork being rejected.
What was doubly dismaying to me about this process was not only that it
failed to satisfy my needs, but that it so well satisfied theirs. My needs
appeared to have been failed utterly. I was looking for analysis--something
to give me new insight into security “in the field.” Sometimes
such insights are even of sufficient merit to warrant publication. It
was clear to me, though, that nothing publishable could ever come from
this.
From this article, you can see that again I was wrong, and that field
certification and accreditation suited my needs as well. Clearly there
is much that I have yet to learn about this profession.
ACM COPYRIGHT NOTICE. Copyright © 1988 by the Association for Computing
Machinery, Inc. Permission to make digital or hard copies of part or all
of this work for personal or classroom use is granted without fee provided
that copies are not made or distributed for profit or commercial advantage
and that copies bear this notice and the full citation on the first page.
Copyrights for components of this work owned by others than ACM must be
honored. Abstracting with credit is permitted. To copy otherwise, to republish,
to post on servers, or to redistribute to lists, requires prior specific
permission and/or a fee. Request permissions from Publications Dept, ACM
Inc., fax +1 (212) 869-0481, or permissions@acm.org.
This copy is posted by permission of ACM
and may not be redistributed.
|
