MULTICS ADMINISTRATIVE BULLETIN MAB-071 To: MAB Distribution From: J. M. Stansbury Date: August 14, 1985 Subject: Multics Security Coordinator: Duties and Responsibilities ABSTRACT This bulletin describes the position responsibilities and duties of the Multics Security Coordinator. Briefly, the Security Coordinator has the assigned responsibility to look closely at the security implications of every system change. Changes to the Multics Trusted Computing Base (TCB) are particularly important to the Security Coordinator. The Security Coordinator is also required to be cognizant of the policies spelled out for data security Critical Fixes in MAB-063. - i - MAB-071 Security Coordinator CONTENTS Page 1: References . . . . . . . . . . . . . . . . . . 1 2: Introduction . . . . . . . . . . . . . . . . . 2 2.1: Scope . . . . . . . . . . . . . . . . . . . . 2 3: Technical Background of Security Coordinator . 2 4: Duties and Responsibilities for Planned Software Changes . . . . . . . . . . . . . . . . . 3 4.1: Design Reviews of Software Proposals . . . . 3 4.2: MCR Board . . . . . . . . . . . . . . . . . . 3 4.3: Code Audit . . . . . . . . . . . . . . . . . 4 4.4: Security Hierarchy . . . . . . . . . . . . . 4 4.4.1: Management of the Security Hierarchy . . . 4 4.4.2: Running of Functional Tests . . . . . . . . 4 4.4.3: Maintenance of Multics Design Documentation 5 5: Duties and Responsibilities for Emergency Software Changes . . . . . . . . . . . . . . . . . 5 5.1: Design Reviews of Software Proposals . . . . 5 5.2: MCR Board . . . . . . . . . . . . . . . . . . 5 5.3: Code Audit . . . . . . . . . . . . . . . . . 6 5.4: Security Hierarchy . . . . . . . . . . . . . 6 5.4.1: Management of the Security Hierarchy . . . 6 5.4.2: Running of Functional Tests . . . . . . . . 6 5.4.3: Maintenance of Multics Design Documentation 6 _________________________________________________________________ Multics Project internal working documentation. Not to be reproduced or distributed outside the Multics Project. - ii - Security Coordinator MAB-071 1: REFERENCES The Security Coordinator must be well versed with the policies and procedures spelled out in the following documents. 1. MAB-066, August 8, 1985, Multics Configuration Management: Software Development Procedures, by B. I. Margulies and R. Barstad 2. MAB-048, August 12, 1985, Rules for the Multics Change Review Board, by R. Barstad 3. MAB-069, August 13, 1985, Multics Configuration Management: Guidelines for Auditing Software, by G. C. Dixon 4. MAB-056, August 7, 1985, Multics Configuration Management: Installing Planned Changes in System Libraries, by F. W. Martinson and G. E. Johnson 5. MAB-057, August 7, 1985, Multics Configuration Management: Installing Emergency Changes in System Libraries, by G. E. Johnson 6. MAB-063, August 13, 1985, Multics Configuration Management: Critical Fixes for Released Software, by G. C. Dixon 7. MAB-067, August 5, 1985, Procedures for Software Installation and Integration, by W. Olin Sibert 8. MAB-068, August 13, 1985, Multics Programming Standards, by B. Margulies and R. Barstad 9. MDD-004, July 10, 1985, The Multics Security Functional Test Suite: Goals, Standards and Policies, by E. A. Ranzenbach 10. MAB-064, August 27, 1984, Third Party Software Submission Procedures, by F. W. Martinson 11. Department of Defense Trusted Computer System Evaluation Criteria, CSC-STD-001-83, 15 August 1983, also known as "The Orange Book" - 1 - MAB-071 Security Coordinator 2: INTRODUCTION This document describes the responsibilities of the Security Coordinator in the Multics Software Development process, and in the Configuration Management procedures in place to ensure high quality software and proper operation of Multics security mechanisms. Any person appointed to the position of Security Coordinator must follow the guidelines of this document. That person may also suggest amendments or enhancements to this document, through normal channels. 2.1: Scope The guidelines in this document are definitive with regard to the duties and responsibilites of the Security Coordinator. Other documents should refer to this MAB when discussing any duty of the Security Coordinator. The software referred to in this document is Released Product Software destined for installation in the System Libraries, or distributed as critical fixes for such software. Other software, such as private tools, is not covered by these policies and procedures. 3: TECHNICAL BACKGROUND OF SECURITY COORDINATOR The Security Coordinator must be an individual with substantial Multics experience, particularly in the various subsystems of Multics hardcore. Specifically, experience in the following areas is highly desirable: o System Initialization o Storage System & Directory Control o Answering Service o Hardcore Supervisor Programming o Interprocess Communication o Resource Control o Message Segment Software The Security Coordinator must be familiar with any reports or data generated by formal Multics security evaluations. For example, the MR11.0 B2 security evaluation team performed a penetration analysis and wrote a report describing their findings. The Security Coordinator must be familiar with this report in order to evaluate new software changes for potential - 2 - Security Coordinator MAB-071 penetration flaws. Reports of such a sensitive nature must also be carefully safeguarded. In addition to software expertise, the Security Coordinator must be knowledgeable with the central system hardware, especially those hardware features which Multics depends upon to exercise data security. Specifically, knowledge of hardware features in the following components is highly desirable: o Central Processor (L68 or DPS8M) Unit o IO Multiplexor o System Control Unit 4: DUTIES AND RESPONSIBILITIES FOR PLANNED SOFTWARE CHANGES This section describes, in detail, the duties and responsibilities of the Security Coordinator for software which is destined for installation in Multics System Libraries as part of planned system software changes (Ref. 1, 4, and 7). 4.1: Design Reviews of Software Proposals The Security Coordinator will participate in all design reviews for changes to the TCB. Particular attention is required in areas where modifications or enhancements to the TCB are proposed. If it is apparent at this stage of the design that such modifications or enhancements imply undue risk to Multics security mechanisms, the Security Coordinator may veto the design proposal. The Security Coordinator should, in such a case, be prepared to suggest methods which may allow implementation of the proposal without hazard to the TCB. 4.2: MCR Board The Security Coordinator is an active member of the GMCRB, and is eligible for appointment to the EMCRB as well. As a member of either body, this person has primary responsibility for reviewing the correctness of the security aspects of all proposed designs. Again, if it is apparent at this stage of the design that such modifications or enhancements imply undue risk to Multics security mechanisms, the Security Coordinator may veto the design proposal. The Security Coordinator should, in such a case, be prepared to suggest methods which may allow implementation of the proposal without hazard to the TCB. - 3 - MAB-071 Security Coordinator 4.3: Code Audit Each developer of code intended for inclusion in the Multics System Libraries is responsible for finding an auditor for his code. This auditor may be the only auditor of record if the module or subsystem is small and not part of the TCB. If the subsystem is large, there may be several auditors of record. If the module or subsystem is part of the TCB, the Security Coordinator plays a vital role in the audit process. Once the primary audit, as performed by the auditor selected by the developer, is complete, the MSCR package is turned over to the Security Coordinator to perform (or appoint someone to perform) a secondary audit. This audit will focus primarily upon the security aspects of changes to the module(s) involved. 4.4: Security Hierarchy Multics security, as enforced by the TCB, is tested and maintained by a large number of tests known as the Functional Test Suite. This series of tests, along with supporting software, documentation, and Multics Design Documents (MDDs), is kept within the >security hierarchy on System-M in Phoenix. The Functional Test Suite is described in MDD-004 (Ref. 9). Changes to the >security hierarchy are requested through normal channels by developers using MSCR forms. The Security Coordinator must approve such changes by signing the MSCR. Changes to this hierarchy are installed by personnel of the System Integration Project. 4.4.1: MANAGEMENT OF THE SECURITY HIERARCHY Multics software development is governed by guidelines which, as a whole, are known as Multics Configuration Management. The majority of the references included with this bulletin act as definition of that policy. One of the Security Coordinator's highest responsibilities is knowing and exercising that policy. The Configuration Management procedures must be observed for all Multics system software, TCB and non-TCB. In addition, the Functional Test Suite also must conform to Configuration Management. 4.4.2: RUNNING OF FUNCTIONAL TESTS Whenever part of the TCB is modified, the associated Functional Test(s) must be verified to run without errors. If the change is substantial enough, the test(s) must also be modified to account for the extended functionality. The Security Coordinator may not necessarily make changes to the Functional Tests, but is - 4 - Security Coordinator MAB-071 responsible for ensuring their continued correct validation of the TCB. The entire Functional Test Suite is run at least once per release cycle to ensure that no security holes have been introduced. The suite of tests will normally be run by the System Integration Project. Results of such runs will be made available to the Security Coordinator on a routine basis. A primary goal of the Test Suite is to ensure that Multics retains a B2, or better, security rating as defined by the Department of Defense Computer Security Center (DoDCSC) Criteria (Ref. 11). 4.4.3: MAINTENANCE OF MULTICS DESIGN DOCUMENTATION The >security hierarchy also contains a set of documents, known as Multics Design Documents (MDDs), which definitively describe the Multics TCB and trusted applications. The Security Coordinator is responsible for ensuring that these documents reflect the current running TCB. As part of the duties with the GMCRB and design reviews, the Security Coordinator must make clear when updates to these documents are required. The Security Coordinator will not approve an MSCR until such updates to MDD(s) have been written and approved. 5: DUTIES AND RESPONSIBILITIES FOR EMERGENCY SOFTWARE CHANGES In cases where normal procedures for installation in the Multics System Libraries will not suffice, the Security Coordinator has the following duties and responsibilities. These procedures imply usage of Emergency MSCRs and PBFs. (See References 5 & 6). 5.1: Design Reviews of Software Proposals The normal design review process applies. In cases of this nature, the software fix(es) which must be applied are unforeseen, and must be applied as expeditiously as possible. There is a potential requirement for update to MTB(s). 5.2: MCR Board For more detail on the procedure outlined below, refer to MAB-063 (Ref. 6). If a data security problem exists in the Multics release being developed, then its fix must be submitted for installation on System M as an Emergency MSCR. The developer will write an MCR describing the nature of the problem and the impact of the - 5 - MAB-071 Security Coordinator problem on data security. The developer will submit the MCR to the Multics Security Coordinator. The Multics Security Coordinator will submit an Emergency MSCR to install the fix in the Multics release being developed, following the procedures for Installing Emergency Fixes described in MAB-057 (Ref. 5). The Multics Security Coordinator is also responsible for submitting the MCR to the MCR Board for review and approval. MCR submission must be delayed until at least two (2) months after formal announcement of the data security fix in order to protect information about the problem. Once the MCR is approved, the Multics Security Coordinator also has responsibility to coordinate permanent installation of the fix into the Multics release being developed, according to the procedures for Normal Installations in MAB-056 (Ref. 4). 5.3: Code Audit Code audit requirements are the same as for planned installations. 5.4: Security Hierarchy The Security Coordinator must remain cognizant of any software changes which will affect the content of this hierarchy, and must be instrumental in causing any necessary modifications. 5.4.1: MANAGEMENT OF THE SECURITY HIERARCHY Same as for planned installations. 5.4.2: RUNNING OF FUNCTIONAL TESTS If a software modification creates the need for modification of an existing functional test, or creation of a new one, the Security Coordinator must cause the change to happen. The Security Coordinator will also affirm that the test(s) run accurately. 5.4.3: MAINTENANCE OF MULTICS DESIGN DOCUMENTATION If a software modification creates the need for modification of existing design documentation, or creation of new documentation, the Security Coordinator must cause the change to happen. - 6 -