1. Security WG: Report of the Fall 2003 Meeting October 28, 2003 Howard Weiss, NASA/JPL/SPARTA

2. Executive Summary  The Charter of the WG was reviewed in depth  The needs for each of the existing work items  Changes made to accommodate additional work items Specifications for authentication, encryption, key management/distribution Later use of Common Criteria for Information Technology Security Evaluation (ISO 15408) “Protection Profiles” to describe security requirements for use cases.  Discussed the approaches and stages for developing the threat statement.  Convert PowerPoint threat presentation into a Green Book.  Discussed approaches and first drafts of the Security Architecture  Security portions of the RASDS  Security-specific architecture based on RASDS views  Discussed comments on the revised Security Green Book  Discussed enhancements to the Green Book that can easily be incorporated into existing revision.

3. Summary of Goals and Deliverables 1. Complete update/revision of the Security Green Book. 2. Develop Security Architecture. 3. Develop Information Security Threat Statement based on PowerPoint threat presentation. 4. Develop an Information Security Guide for Mission Planners to include threat/risk analysis, security planning, and contingency and disaster recovery. 5. Formulate a security policy framework for developing trust agreements, rules for operational engagement, ensuring security compliance of legacy systems, and standard, secure interfaces between systems and across security domains. 6. Recommend a CCSDS encryption standard. 7. Recommend a CCSDS authentication standard. 8. Recommend a CCSDS key management standard. 9. Work with other WGs with respect to security.

4. Progress Achieved  Revised the WG charter based on detailed discussions on the course of the work items, what is achievable, and what is (has been) needed by CCSDS.  It was agreed that a threat statement is a high priority work item and that the mission planners guide would prove to be very useful and is needed.  It was agreed that despite the potential problems in adoption because of widely varying policies in individual countries, CCSDS recommendations are needed for encryption, authentication, and key management. These have been added to the list of work items.  It was agreed that the security architecture work, which has just begun, is progressing along the correct path.  The revisions to the Security Green Book were agreed upon based on the received comments and discussions which provided other additions to the book’s contents (e.g., enhanced threat discussion, interconnection rules between networks, trust relationships).

5. Near-Term Schedule DeliverableMilestoneDate Green Book revisions Comments received from WG Publish a revised book for CCSDS approval Complete 12/03 CCSDS Security Architecture (1 st Draft) Publish a draft document (White Book) 12/03 Security Threat Statement Update and convert PowerPoint presentation into Green Book 02/04

6. Open Issues  Do the “pure” science missions care about security? Should they be forced to care? Cost/benefit analyses need to be performed to determine whether security is necessary or not in such cases.  Can the threat statement document be meaningful without specific illustrations of the threat (which will run into classification issues)?  We think so given example use cases with open source exploits illustrated.  “Transparent Security” vs. “Simple to Use Security”  If security is transparent it will always be used because the user does not see it,  However, if it breaks, the user may not know (or care) which may make “simple to use” security better.  Architecture issues:  How specific should the architecture be – specific mechanisms, specific algorithms, etc?  How does the Security WG work with other WGs and BOFs?  Do we go to them, or do they come to us?  General feeling is that the Security WG has to go to the other WGs.

7. Action Items  Complete revision of the Security Green Book  To: Weiss  Due: November 2003  Continue development of the Security Architecture  To: Kenny  Due: Issue 1 st draft December 2003  Develop threat document.  To: Weiss  Due: February 2004.  Check on status of “security statement” required in each CCSDS document as previously recommended and draft another resolution if not already required (see later slide).  To: Shames, Weiss  Due: At the next CESG meeting

8. Resource Problems  Resources are adequate to perform the initial tasks.  It has not yet been determined if resources are adequate to accomplish all the work currently on the schedule.  There was no ESA representation at this meeting which means that a large portion of CCSDS membership was not represented. This should must be fixed.

9. Risk Management Update  It is still unclear if enough resources are available from the Agencies to perform the necessary jobs.

10. Cross Area WG / BOF Issues  Security is a cross-cutting discipline that needs to be included in many other Areas and WGs. We discussed how this would be best performed – by having other WGs come to the Security WG for help or by having the Security WG go to the other groups to provide support.  It was felt that the proactive approach would work best but resource constraints will be an issue.

11. Resolutions to be Sent to CESG and Then to CMC  The Systems Engineering Area resolves to require that all CCSDS documents produced must include a section on security detailing the security analysis performed with respect to the work area. If security mechanisms/features are included in the document, they must be described in this section. If security mechanisms/features are not included in the document, this section must provide detailed rationale as to why. A statement such as “this work item has nothing to do with security” would be inadequate.

12. New Working Items, New BOFs, etc.  Encryption recommendation.  Authentication recommendation.  Key Management recommendation.  Security policy framework document.