From epperson@vak12ed.edu Wed Jul 24 01:02:49 1996 Received: from hp01.vak12ed.edu (hp01.vak12ed.edu [141.104.150.251]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id BAA10545 for ; Wed, 24 Jul 1996 01:02:23 +1000 Message-Id: <199607231502.BAA10545@suburbia.net> Received: by hp01.vak12ed.edu (1.37.109.18/16.2) id AA121694034; Tue, 23 Jul 1996 11:00:34 -0400 From: "W.C. Epperson" Subject: Re: Authentication necessary when encryption ? To: vin@shore.net (Vin McLellan) Date: Tue, 23 Jul 1996 11:00:34 EDT Cc: best-of-security@suburbia.net In-Reply-To: ; from "Vin McLellan" at Jul 22, 96 5:03 pm X-Mailer: Elm [revision: 109.18] Having spent significant chunks of my career on the data side of the house, I'd like to toss a couple of turnips in to stew with Vin's excellent discussion. > > Christian Alt petitioned the Brethern here assembled > for discussion of a serious question -- one too often ignored; yet likely > to be heard more often in the future. Said Mr. Alt: > > >With encryption between a remote user's laptop and the central site, do > >you think that authentication is still necessary. This is the point on > >which i would like to exchange some thoughts. > > > >I admit that the encryption keys are unique to any user. > > > >Authentication is still necessary to access the ressources on the central > >site. But no more to access the site itself. > > Mr. Alt raises the issue in a particularly subtle way. He asks on > one hand whether encryption, per se, could serve as an authentication > process -- and then, on the other hand, he suggests that any such an > authentication (implemented solely on the basis of possession of a unique > encryption key) could be used with some limitations, in a process where it > would be honored only to the extent of providing a remote user "access" to > a host network or remote system. > [snip] > II. Within virtually all organizations, access controls and > secrecy/confidentiality are different functions -- politically, as well as > technically. They serve, quite literally, different masters. It would seem that, WRT data, access control is one facet of implementing secrecy/confidentiality. > > * Access control privileges are generally assigned by a local > manager, a manager of people. On the other hand, the designation of data > as secret or confidential (or requiring ongoing integrity checks) is > generally done by the manager or developer of an application -- in most > organizations, a different fellow than the aforementioned local manager. > > The local manager probably doesn't know the heritage of the data or > fully understand the relevant issues of confidentiality. The applications > manager probably doesn't understand what specific access privileges a given > employee requires to do his job; certainly not enough to appropriately > minimize that employee's access. In organizations with effective data administration programs, classification of data as to confidentiality and business criticality is done by data administration professionals in concert with the data owners or stewards. Access authorization is then requested by local managers for their people, accompanied by business justification, and approved by the data owners/stewards. As a business decision regarding disposition of resources, such authorization is subject to similar ramifications of carelessness or inattention to business requirements as other business decisions. Implementation of the access authorizations by security staff, then, is just another instance of staff implementation of organizational decisions, and should be compartmentalized from the ability to make the decision, as with any other process involving disposition of valuable resources. E.G. the compartmentalization of the abilities to commit budgets/approve payments/write checks. Vin's model is, however, more common than the strong DA one. > > * These are divergent chains of responsibility and authority, and > the import of this distinction is compounded by the reality that, > typically, the life span of the application is much longer than the tenure > of any one employee. (People can be managed by transient managers, in part > because a person can explain himself and his role. A long-lived > application may, on the other hand, require someone with a deep > understanding of the heritage of the data and its legal, moral, and > political associations, to specify -- or adjust -- its info-security > classification.) More factors in the importance of data classification and administration. If you have people using data (never mind administering access control) without adequate understanding of the legal, moral, political implications, there's much more wrong in the organization than a technical information security function can fix. > > * The implications of combining control of encryption > (secrecy/confidentiality) and access control in one function or a single > individual can be dangerous. Often, this would create an administrative > task in a vacuum -- a place where the organization doesn't have a > designated or appropriate area of responsibility, or a role sufficiently > informed to carry it off. As above, more dangerous IMO is combining authorization and implementation. My views expressed here are somewhat data-centric, but I don't seek to start any process/data/network religious wars: I've worked as systems analyst, DBA, DA, network designer, security manager, etc., and strive to keep a balance in my approach to the disciplines involved. The major point is the need for appropriate checks and balances in any system of organizational processes. Thanks to Vin for his other excellent remarks regarding encryption and authorization (omitted here). regards, -- W.C. Epperson "I have great faith in fools. Senior SE Self-confidence, my friends call it." Information Security Officer --Edgar Allan Poe-- DBA Emeritus Curmudgeon-for-Life Virginia Dept. of Education epperson@pen.k12.va.us