Home link Books link Press link Security link Briefings link

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

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.

www.TaleCatcher.com

Updated: 20-Oct-2005