16
1 Security Policy Framework & Security Policy Framework & CCSDS Common Criteria Use CCSDS Common Criteria Use CCSDS Security WG Fall 2005 CCSDS Security WG Fall 2005 Atlanta, GA USA Atlanta, GA USA Howard Weiss NASA/JPL/SPARTA [email protected] +1-410-872-1515 September 2005

1 Security Policy Framework & CCSDS Common Criteria Use CCSDS Security WG Fall 2005 Atlanta, GA USA Howard Weiss NASA/JPL/SPARTA [email protected] +1-410-872-1515

Embed Size (px)

Citation preview

1

Security Policy Framework &Security Policy Framework &CCSDS Common Criteria UseCCSDS Common Criteria Use

CCSDS Security WG Fall 2005 CCSDS Security WG Fall 2005 Atlanta, GA USAAtlanta, GA USA

Howard WeissNASA/JPL/SPARTA

[email protected]+1-410-872-1515

September 2005

2

AGENDAAGENDA• 14 September 2005

– 0900-0915: Welcome, opening remarks, logistics, agenda bashing, 0915-0930: Review results of Spring 2005 SecWG meeting in Athens Mtg Notes

– 0930-1000: RASDS Review wrt Security Architecture (Kenny)– 1000-1030: coffee break– 1030-1200: Security Architecture Document Discussions (Kenny)– 1200-1330: Lunch– 1330-1400:Review CNES Mission Security Req Development using

EDIOS (Pechmalbec/Belbus)– 1400-1500: Encryption Algorithm Trade Study (Weiss)– 1500-1530: coffee break– 1530-1700: Authentication/Integrity Algorithm Trade Study (Weiss)

• 15 September 2005– 0900-1000: Key management discussion (Kenny)– 1000-1030: Coffee break– 1030-1100: Identity Management, Spacecraft IDs (Weiss)– 1100-1130: CNES Interconnection Rules (Pechmalbec/Belbus)– 1130-1300: Lunch– 1300-1400: CNES Security Development Process

(Pechmalbec/Belbus)– 1400-1500: Security Policy Document/Common Criteria (Weiss)

3

Security Policy Framework – Security Policy Framework – What is This?What is This?

• Connection agreements between space agencies have to be developed – often from scratch – to govern the security policies and enforcement between the connected networks.

• We agreed that it would make sense to develop a standard CCSDS policy framework for – developing trust agreements, – rules for operational engagement, – ensuring security compliance between legacy systems,

and – standard, secure interfaces between systems and

across security domains.

4

What Might It Contain?What Might It Contain?

• Sections might include:– System description– Interconnection partners reason for connecting– Description of networks to be connected

» Security policies» Security administration

– Interconnection demarcation rules– Mutual agreements and understanding– Etc.

5

6

7

Existing DocumentExisting Document

• US National Institute of Standards and Technology (NIST) Special Publication 800-47– NIST 800-47– This would appear to need to be re-written for CCSDS

rather than adopting» Lots of US-centric references to documents,

regulations, departments, etc.» But it contains a lot of the baseline information

including a template for an agreement between parties.

8

Discussion ResultsDiscussion Results

• Athens meeting: seemed to be in agreement that this is a good thing to do– Create a Green Book based on NIST 800-47?– Action item assigned (Weiss) to investigate

» Not completed – question is should we still contemplate doing this?

» ……..

9

CCSDS Use of Common CriteriaCCSDS Use of Common Criteria

• Background– In the past we’ve discussed the creation of an

information security guide for the mission planner– We have discussed re-examining this in favor of using

the Common Criteria to instead write a Space Mission Protection Profile

10

What Might It Contain?What Might It Contain?

• Sections might include:– Project mission roles and responsibilities– Security overview (a la Green Book)– Threat/risk analysis– Risk mitigation– Security planning (a la Security Architecture document)– Security mechanisms (a la Green Book)– Contingency and disaster mitigation– Etc.

11

Alternative: Common CriteriaAlternative: Common Criteria

• ISO 15408: Common Criteria for Information Technology Security Evaluation – Protection Profiles (PP) are produced as security

“acquisition” documents» Collection of system security requirements that the

system “user” wants to purchase– Security Targets (ST) are produced by vendors to

describe the security characteristics of their system.• Use the CC as the basis for describing the mission

security requirements?– Use the existing CCToolbox?– Extend/modify the CCToolbox for space environments?– Write a (several) Protection Profiles to describe the

security requirements for space missions?» E.g., Use illustrative mission categories from the

Threat Green Book?

12

CC Protection ProfilesCC Protection Profiles

• Means by which security requirements for missions can be described in a way that is internationally understood.

• Threat Document mission types:– Manned– Meteorological (LEO, GEO)– Communications (LEO constellations, GEO)– Science missions: Near-earth, Lunar,

Interplanetary/Deep-space– Navigation

• Develop a PP for each mission type?

13

Use CCToolbox?Use CCToolbox?

• SPARTA-developed for US National Information Assurance Partnership (NIAP)

• Freely available (although no longer supported)– Written in Java– ftp://ftp.sparta.com/pub/columbia/cctb.zip

• “Interviews” PP or ST developer to walk through the developer though the myriad mess of the CC.– Akin to TurboTax that walks folks in the US through

their income tax preparation

14

15

16

Discussion ResultsDiscussion Results