1 / 12

CCSDS Security Working Group Spring Meeting Colorado Springs Security Architecture

CCSDS Security Working Group Spring Meeting Colorado Springs Security Architecture January 19 th 2007. Agenda. Changes since Rome A recap on the use of the Views The Security Architecture CCSDS Security Core Suite Some examples Emergency Commanding Next Steps Q&A. Changes since Rome.

garrison-munoz
Download Presentation

CCSDS Security Working Group Spring Meeting Colorado Springs Security Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CCSDS Security Working Group Spring Meeting Colorado Springs Security Architecture January 19th 2007

  2. Agenda • Changes since Rome • A recap on the use of the Views • The Security Architecture • CCSDS Security Core Suite • Some examples • Emergency Commanding • Next Steps • Q&A

  3. Changes since Rome • Removal of in-depth discussions on • Authentication • Algorithm types • Key Management • These are now discussed in greater detail in other books, to which the Security Architecture refers. • Extended discussions to encompass more than scientific missions • The architecture was always designed to be flexible and extensible, this has been brought out more in the document. • Removal of File based encryption as a mandated part of the architecture, it is still available as an optional plugin for large delay and non-continuous communications. • Emergency Commanding has been updated to allow for a range of options which can be selected by mission planners, there is no mandated solution for this as there is little need to interoperability in this area. • Ground systems, from discussions in Rome it was felt that the Security Architecture should concentrate on Space Solutions, ground systems will use best-of-breed terrestrial technology and can be changed as the need arises.

  4. The Views – A Summary • Enterprise View – Tells us what inter-agency policies need to be developed • Connectivity View – Tells us to consider Threats due to HOW elements communicate • RF in Space, non-continuous, QoS • Ground systems, use of the Internet, need for VPNs • Functional View – Tells us the high level shape of the System Security Architecture • What functions does the mission need that the Security Architecture should support? • Information View – Tell us the detail of the System Security Architecture • Where is the data, how is it stored, how is it transmitted, how should it be protected.

  5. Proposed Architecture • Based on a layered and expandable model • Use of security formats, which can be used together or individually. • Transport Layer Encryption • Network Layer Encryption • The use of Link Layer or Payload specific encryption is also accommodated by the architecture

  6. CCSDS Security Core Suite • Use of a Core suite of algorithms to allow reuse where missions do not need the complexity of bespoke solutions • Mandated to ensure all CCSDS missions are interoperable • Two layers, Network and Transport, can either be used together or separately • Choice of recommended algorithms and configurations to be decided in other security books

  7. Core Suite Configurations

  8. Extending the Security Architecture • The Core suite is not intended to solve all mission problems • Missions are free to develop their own solutions as plug-ins to the architecture • Note use of Link and Payload Security • Agencies are free to develop their own security suites as plug-ins of the Security Architecture • Core Suite supplies interoperability

  9. Simple solutions

  10. Emergency Commanding • Agreement from Rome that this could not be a binary YES/NO for Security • Therefore proposed a range of solutions • In Safe Mode but CPU online - use normal authentication • In Safe Mode, CPU offline - Watchdog drops need for authentication • Not in Safe Mode, CPU offline - Watchdog drops need for authentication • Tumbling - Watchdog drops need for authentication • In the above cases the Watchdog is looking for certain events to reliably happen, if they do not it can drop the need for authentication • Main aim is to keep the Watchdog very simple and robust • Up to Missions Planners to decide which combination to choose, or whether to take the risk and not have authentication on emergency commands • Little need for interoperability so recommend it is not a mandated part of the security architecture.

  11. Next Steps • We need to develop a set of missions profiles to be used as examples for each of the 5 missions types. • Manned Space • Weather • Communications • Scientific • Navigation • It would be good to have input from the agencies with specific experiences of these mission types to ensure a good quality result. • However we need to be clear that these are examples only, the main message must be to use the different views to examine each mission on its own merits and ensure that all the correct Polices, infrastructure and architecture are in place, for that mission.

  12. AoB Questions?

More Related