BKRDDBSC.RVW 931014 Springer-Verlag 175 Fifth Ave. New York, NY 10010 212-460-1500 800-777-4643 or 8 Alexandra Road London SW19 7JZ UK 44-81-947 5885 "Research Directions in Database Security", Lunt (ed.), 1992, U$39.50 Generally, we speak of security in binary terms. You either allow access to the system or you don't. You allow a file to be modified, or you don't. There are, of course, some very complex issues to be faced, and access situations can certainly become complicated. But by and large, access security can be resolved to a series of yes/no questions. Not so with database security. The situation is almost the reverse of access security: there is no black or white, only shades of grey. In database security you have to assume that everyone needs and has access to the database, but that certain answers are not to be given to certain people. That's a fairly simple problem to deal with. What about the situation where many people can update but you don't want two people simultaneously updating the same record, and thus corrupting the data. Again, some reasonably simple solutions; although, when we add together many "simple" solutions, we start to build a fairly "complex" system. Let's return to the question of access to information, using the example of the census data. There is no problem with anyone and everyone knowing how many people are unemployed in Canada. An aggregate number for British Columbia, or even for North Vancouver, should still present no problems of confidentiality. However, no one should know that Robert M. Slade is unemployed unless Robert M. Slade chooses to divulge that datum. Even then, Robert M. Slade should have control over who should know that fact. Therefore, we have a situation where the individual records should not be divulged, but queries reported over a range can be. (Just to ensure that the issue doesn't get any easier, we have to build in safeguards that would prevent the indirect revelation of information such as generating queries of intersecting sets and watching the changes.) Such are the questions addressed in this book. The contents are basically the results of a three-day symposium held in 1988. Sponsored by the military, many of the papers specifically address "classified" data, but a number of the concepts have practical business applications as well. (The military involvement may also explain the four-year lead time until the book was published.) The book covers questions at all levels of the computing enterprise, from computer architecture through operating systems to data base architecture to conceptual approaches. Not all possible topics are covered, but there is a good range. This is, quite definitely, for the database professional, and prior database security background would be helpful. The "alphabet soup," as Dorothy Denning notes, flies thick and fast. Most of the papers discuss TCB: the book is about finished before a paper tells you what it is (trusted computer base). The acronyms multiply, even using other acronyms: halfway through one paper on "A1 Secure DBMS (database management system) Architecture" the authors start talking about "ASD". As with all such omnibus volumes, the interest will vary with the topic, and the quality varies with the author. One essay examines the "man in the loop" question in regard to the feasibility of automatic classification of data. After spending seven pages clarifying the question, the answer is basically, "No, computers can't understand text yet." Generally, however, the title is accurate. These are the "cutting edge" (or perhaps *slightly* behind) issues in data security, and an interesting discussion piece for those issues. copyright Robert M. Slade, 1993 BKRDDBSC.RVW 931014 Permission granted to distribute with unedited copies of the Digest ====================== DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 DECUS Symposium '94, Vancouver, BC, Mar 1-3, 1994, contact: rulag@decus.ca