Network Security: Accountability Issues for Networks
Articles and Tips: tip
01 Oct 1996
There is an accountability issue with computers and people that it different than just identification and authentication (I&A). This accountability is especially critical for electronic commerce. In a transaction environment, you need to know not only which computer ran the transaction, but also which person handled the transaction. Auditors understand this accountability issue; business managers, executives, and directors also want this accountability.
However, getting user-access accountability across computer networks is a technical issue unlike those previously addressed by I&A. It is important to differentiate absolute-nature accountability from I&A issues for the following reasons:
I&A is a gradable mechanism with regard to trust.
I&A, though it is the essence of accountability, is affected by temporal events.
I&A is not usually cognizant of application-driven events that occur after a user has been identified and authenticated.
A Matter of Trust
I&A is gradable in nature. It looks only at the workstation and does not take into account the specifics of the server operating systems NetWare, Windows NT, or OS/2. Therefore, there must be some concern that identification "secrets" (such as passwords) are going to be passed from the end-user to the keyboard, relayed from the keyboard to the processor, and even perhaps stored in memory after the identification process has occurred.
Identification secrets that the end-user memorizes are definitely more secure than secrets that the end-user writes down. However, there is no basis for trusting the workstation operating system to maintain secrecy. Instances of secrets being duplicated, even for only a short period of time, are commonplace. Windows 95, for example, stores identification secrets at the workstation. UNIX, in many instances, passes passwords unencrypted across the wire. These are good examples of diminishing trust in an identification secret.
While some degree of accountability is established in most systems through I&A, it is affected by events which can and do occur prior to the I&A process. If you have no idea what is going on before I&A takes place, you really cannot assert with any level of confidence that I&A mechanisms are occurring in proper order or that secrets are being handled correctly. For example, password-scavenging software has been available on the Internet for some time that will effectively make a copy of the identification secrets and store them. This will allow someone else to forge an end-user's identification by password.
On the other hand, if you know (from evaluation) that the Power On Self Test and BIOS load are the only two events that can occur before I&A, then you are relatively assured (by evaluation) that the I&A mechanism will load and perform as tested. This is why providing NetWare secrets on a Class C2 trusted workstation is considered a reliable mechanism.
So our second point is that I&A is effective only up to the point where it occurs, and then only if you know how the identification secrets are really handled, and if you ascribe to those methods some level of trust. If some unevaluated or unknown process is allowed to operate where identification secrets are present, you have considerably diminished the value and reliability of those secrets.
Secure to the End
Identification is good, but only if we know what has gone on before. This means that after running I&A, we expect to know who is at the other end. If any unknown process occurs after I&A, you cannot be certain of the identity of the end-user. This is the third point: Accountability is based on knowing who the user is throughout the session, from the beginning right up through to the end. The threat of malicious software and maliciously inclined users intervening in an established session might give you cause for a decreased level of trust in accountability even after a positive ID by I&A.
While microcomputer networks allow a broad range of activities, network managers and corporate administrators should give consideration to developing levels of accountability commensurate with the company's need for controlled or regulated access. Only by providing networks with the ability to prove or disapprove accountability will companies be able to successfully use them for electronic commerce.
* Originally published in Novell AppNotes
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.