CCSDS Threat Document Discussion CCSDS Security Working Group Spring 2005 Meeting Athens, GR

1. CCSDS Threat Document DiscussionCCSDS Security Working GroupSpring 2005 MeetingAthens, GR Howard Weiss NASA/JPL/SPARTA hsw@sparta.com +1-410-872-1515 April 2005

2. Agenda • 11 April 2005 • 1030-1200: Joint meeting with Space Link Support Area • 13 April 2005 • 0900-0915: Welcome, opening remarks, logistics, agenda bashing • 0915-0930: Review results of Fall 2004 SecWG meeting in Toulouse 0930-1000: Security Architecture Document Discussions (Kenny) • 1000-1030: coffee break • 1030-1200: Security Architecture Document Discussions, cont • 1200-1330: Lunch • 1330-1415: Anti-Jamming/Spread Spectrum (Olsen) • 1415-1500: Final review Threat Document (Weiss) • 1500-1530: coffee break • 1530-1700: Key management discussion (Kenny) • 14 April 2005 • 0900-0930: Information Security Planning Guide (all) • 0930-1000: Security Policy Framework (all) • 1000-1030: break • 1030-1200: Crypto and Authentication Standards (Weiss)

3. CCSDS Threat Document • Background • Based on threat briefing presented to CCSDS • Last reviewed at Fall 2004 SecWG meeting in Toulouse • Restructured into written document • Sent out for FINAL WG review • Status • Revised based on comments received previously: • Wolfgang Hell (ESA) • Manfred Bertelsmeier (ESA) • Ignacio Aguilar-Sanchez (ESA) • Martin Pilgram (DLR) • Paolo Chinetti (ASI) • Clayton Sigman (NASA) • Michel Miqueu (CNES) • Dave Childs (NASA) • Recent comments received from: • Stephane Pechmalbec/Olivier Belbis (CNES) • Martin Pilgram (DLR) • Mike Pajevski (JPL)

4. Latest Comments • References needed to be updated (other CCSDS docs have progressed since this work was started) • Done • Diagrams were inconsistent/incomplete • E.g., figure 3-3 • Done • CNES “though provoking comments” that need to be discussed here. CNES Comments

5. CNES Comments for Discussion • With the general increasing level of security awareness in the information technology (IT) community, civil and scientific missions should not wait to act until after a security incident occurs. The continued expansion of network interconnectivity for data dissemination and science mission scheduling creates new and additional threats against civil space missions. Both intentional and accidental[SP1] threats should be analyzed and protected against to provide protection of assets and critical services. •   comment: [SP1]Accidental threats are not developed in section 4 of the document. We must deal with that (it may be easy for ground segment but more difficult for space link and spacecraft). Can we just point on other documents or must we develop accidental threats in this document ? Maybe it is not really in the scope of this document.

6. CNES Comments for Discussion (2) • Section 3.2 THREAT ANALYSIS AND MISSION PLANNING[SP1] • [SP1]this must be the core of the information security planning guide.

7. CNES Comments for Discussion (3) • It is expected that a Common Assessment Methodology [SP1]will be agreed upon and adopted by all Space Mission Security Officers. Furthermore, a common analysis process will help agreement on common conformance testing and facilitate the agreement on interoperation procedures for multi-agency missions. • [SP1]Must we choose one as a CCSDS standard ? Or must we use Common Criteria with various methods ? We prefer the second one… All this paragraph should be part of the future Security Policy Framework.

8. CNES Comments for Discussion (4) • Section 4.1 - Active threats include[BSO1]: • [BSO1]Exploit against a vulnerability of a component (software bug for instance) should be added to the list.

9. CNES Comments for Discussion (5) • Section 4.1 - Active threats may be carried out against both spacecraft and ground systems. In the case of ground systems, it is imperative that they are operated as closed networks[BSO1]. • [BSO1] "closed network" must be defined.

10. CNES Comments for Discussion (6) • Section 4.1 - If external access is required into a closed ground system network, it should be accomplished through the use of a secure Virtual Private Network [BSO1](VPN) using technology such as Internet Protocol Security (IPSec). • [BSO1]I not sure that VPN is the only solution for that kind of problem. I think that VPN can solve confidentiality problem and can increase the use of open network. Must this technical solution appear in this threat chapter ? To be discussed.

11. CNES Comments for Discussion (8) • Section 4.2 - A passive threat may also take advantage of a software vulnerability [BSO1]such as when a worm infects a system and migrates to other systems, all the while disclosing information to whomever cares to listen. • [BSO1]It could be a passive and active threat

12. CNES Comments for Discussion (9) • Section 4.3.1 - Probability (1= Lowest, 5= Highest)[SP1] • [SP1]for all system classes, I don't think "probability" column is relevant. To be effective, consequence of threat must be also analysed. Probability and consequences of threats are specific to a space mission. Both are needed to implement efficient mechanisms to counter threats.

13. CNES Comments for Discussion (11) Section 4.3.1 [BSO1]4 ou 5 for me

14. CNES Comments for Discussion (12) • Section 4.4 - Threat summary and Security Mechanisms to Counter THREATS[BSO1] • [BSO1]we never speak about accountability. I think that we must write something about this technical solution. Also we can speak about the logs parsing.