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

1

CCSDS Threat Document DiscussionCCSDS Threat Document Discussion

CCSDS Security Working GroupCCSDS Security Working GroupSpring 2005 MeetingSpring 2005 Meeting

Athens, GRAthens, GR

Howard WeissNASA/JPL/[email protected]+1-410-872-1515

April 2005

2

AgendaAgenda• 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 DocumentCCSDS 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 CommentsLatest 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 DiscussionCNES 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)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


• 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


• 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


• 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


• 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


• 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


• 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


Software threats Undesirable eventsSystem damageEnable other threats

2[BSO1] Acceptance testing Independent verification and validation (IVV) Code walkthroughsAutomated code analysis

[BSO1]4 ou 5 for me

Section 4.3.1

14


– 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.

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

Documents

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