A primer on data security - How do we protect our satellites?

1. A primer on data security- How do we protect our satellites? Daniel Fischer OPS-GDA / Uni Lux 3 November 2006

2. Introduction

3. Weakest Link Principle The overall security of a system is only as strong as the security of its weakest link • All security aspects have to be recognised in order to realise a secure system Example: A strong access control system is useless if the passwords are written on a yellow piece of paper that sticks on the computer

4. Data Security Data Security is more than just encryption and firewalls! • Data Security is a process not an add-on • It has to be present through the whole development cycle of a system • It requires security aware thinking of system developers and users • It should increase the general responsibility awareness

5. Data Security Objectives • The goal of data security is to achieve the following fundamental objectives • Availability • Confidentiality • Integrity • Non-Repudiation • Access Control • Authentication

6. Risk Assessment

7. Risk Assessment From what do we need to protect an information system and which countermeasures are most urgent? • Risk Assessment can answer that question • In data security, risk is defined as a function of three terms: • The probability of a threat • The probability that there is a certain vulnerability • The potential cost of the impact Risk = P(Threat)*P(Vulnerability)*C(Impact)

8. Threats What kind of threats are in existence? • General • Denial of Service • Eavesdropping • Integrity violation / Corruption • Hijacking / System Takeover • Destruction of information and/or hardware • … • Further threats possible depending on the nature of the system • Threats are measured in probability of occurrence • Threats are largely dependent on the motivation, funding and qualification of the threat agent i.e. the potential attacker

9. Vulnerabilities System vulnerabilities are the entrance doors for successful attacks • Vulnerabilities are measured in probability of occurrence • Bugs in software implementations and operating systems • Missing security awareness among users • Improper configuration • Weak data protection methods

10. Impacts Successful exploitation of one or more vulnerabilities can have a more or less critical impact on a system • Examples: • Loss of a spacecraft • Data base destruction • Email espionage • Loss of customer confidence • Impacts are classified through their severity and measured in concrete values like concrete cost

11. Summary on Risk Assessment • Before applying all kinds of (good sounding) countermeasures at various points in a system, a risk assessment is a vital undertaking • Afterwards the answer to a specific threat might be clearer • The level of countermeasures is more appropriate (do not shoot flies with cannons…) • Unnecessary redundancies can be identified before • A maximum level of transparency can be guaranteed • The risk assessment might uncover new risks that were not known beforehand

12. Countermeasures

13. Countermeasures • Countermeasures can be classified • Detection • Protection • Recovery • What countermeasures exist in data security? • Cryptography • Security Policies • System Evaluation • Filtering and Monitoring • User Training • … • The key term is synergy!

14. Cryptography Params Key • Cryptography represents the classical understanding of data security • A cryptographic operation is applied to a data structure • Input: • Data Structure • Secret Information (=Key) • Other parameters • Output: • Protected Data Structure Cryptographic Function DS PDS

15. Cryptographic key principles There are two cryptographic design principles that form the basis for all crypto primitives • Symmetric Cryptography • The same key is used for a cryptographic function and its inverse function • Asymmetric Cryptography • Different keys for a crypto function and its inverse function Message = D ( E (Message, Key), Key ) Message = D ( E (Message, EncKey), DecKey ) EncKey != DecKey

16. Cryptographic Primitives Symmetric Cryptography Asymmetric Cryptography Secret Key Encryption Public Key Encryption Message Authentication Codes Digital Signatures Cryptography

17. Security Policies Security Policies are guidelines of any kind that have the goal to increase the level of security • ESA Security Policies are developed by the security office or ESACERT • They can be of any form • Technical Guidelines • Access Restriction Regulations • User Behaviour Regulations • Key Management Regulations • System Configuration Regulations • Protocol and application usage Regulations • Virus Detection and Reaction Regulations • …

18. System Evaluation System Evaluation protects against vulnerabilities resulting from a poor system design or implementation • International Standards like Common Criteria define evaluation assurance levels • E.g. CC EAL 3: Methodically tested and checked • Evaluation can be a long and expensive process • Security can already be increased by just evaluating the security critical parts of a system • Most extreme case is formal verification • Governments also have national evaluation schemes for crypto equipment protecting classified information

19. User Training User training sessions increase security sensitivity of users • Training sessions shouldbe scheduled on a regularbasis • Topics could be: • Secure usage of computer systems (e.g. protection from Trojan Horses) • Secure choice and storage of passwords • Introduction to secure software and protocols • … • This goes hand in hand with security policies

20. Filtering and Monitoring Filtering and Monitoring of network traffic can uncover or prohibit many attacks • Monitoring • Intrusion Detection Systems • Attack patterns can be recognised • Port Surveillance • Which ports are open and why? • Filtering • Packet Filter • Stateful Inspection • Content Inspection • Ingress Filtering • Both countermeasures are very punctual

21. Protocol Analysis/ Engineering • ESA and other space agencies are using of space tailored communication protocols • These protocols do not aim on providing security • Protocol analysis and security hardening is an important countermeasure • Transparency and interoperability should be kept if possible • Special purpose security protocols need to be designed • Key Exchange/ Agreement • (Mutual) Authentication • Techniques such as formal verification may become important here as well

22. Summary of Countermeasures • Each countermeasure provides only a few aspects of data security • In general, one countermeasure alone cannot counter a certain risk • There is no single “silver bullet” • Defence in depth • Countermeasures must work together to archive the protection of the system • Weakest Link Principle • Synergy!

23. Security by Obscurity • Many people think that a security system becomes more secure if its internal structure is secret • Example: A secret encryption algorithm • BUT: The exact opposite is the case • Open and standardised systems are subject to constant analysis by the international research community • Secret systems can only be analysed by internal specialists • Unless an agency or company has a huge budget, severe and constant analysis of internal security systems is not possible • The Kerckhoff principle in cryptography • The security of a crypto system shall always and only depend on the secrecy of the key • This means that everything of the algorithm except for the keys shall be open

24. Where do we stand?

25. What about ESA/ESOC? Where stands ESA/ESOC in terms of data security? • Current situation critical • Data security countermeasures are generally limited on monitoring and filtering • Security is seen as a kind of obstacle for workflows • No awareness of the work of ESACERT • Very limited security policies • Usage of insecure protocols in the networks • No cryptographic techniques e.g. for protected data transfer inside ESOC • Security unaware users • … Login: root Password: toor

26. Where do we have to improve? • A long way to go to a secure ESOC • However, already small improvements can significantly increase the security level • Implementation of ESACERT guidelines • Introduction and enforcement of a few simple policies: • Password Handling • Protocol Handling • … • On the long term • Usage of the complete set of security policies that will be developed by the ESA security office • Introduction of a public key infrastructure • Usage of evaluated software

27. Some simple examples • Standard remote console protocol in ESOC is Telnet • All user names, passwords and other information are transmitted in plaintext • Migration to the free secure shell (SSH) would solve the problem • For many user accounts, the password is very simple and easy to hack • A secure password can easily be generated by a nice little sentence • Metop is our #1polar orbiter -> Mio#1po • Many machines run old and unpatched server processes such as Apache • Regular updates close a lot of security holes

28. ESACERT • ESA Computer and CommunicationsEmergency Response Team • http://www.esacert.esa.int/ • ESACERT provides data security solutions for ESA • Intrusion Detection • Incident handling • Alerts and Announcements • Collaboration and Coordination • Vulnerability and Artefact Analysis and Response • System Scanning and Certification • Training and Awareness • Consulting and Risk Analysis • etc.

29. Incident Example • On 3/02/06 a successful attack was driven on the mcs30 machine • The attack resulted in • Complete destruction of the MySQL database that supports the ELog application • Denial of Service • Deletion of attack traces • ESACERT analysis identified the following possible break-in process: • Attack began via a very old version of Apache resulting in theft of the passwd/shadow file(s) • Because of the weak passwords the attacker succeeded in cracking them and obtaining root access very quickly • With root rights he did the rest

30. Incident Analysis Conclusion The attack on mcs30 was of extremely simple nature and would not have been possible if a few security regulations were followed • Two main factors that helped the attacker: • Old and vulnerable software installed • Weak passwords in place • Both could have been prevented easily • However, there was no reaction

31. The Data Security Support Project

32. Project Overview • Reasons for starting the project: • Currently, only very few existing and upcoming ESA missions support security features (Metop, ATV, Sentinel-1,…) • Lack of standardisation in the area of security leads to high costs for every new mission • ESAs ground segment in its current form is not able to handle space link security • In the future, many missions will have security requirements defined

33. Project Work • Work on a standardisation for space link security • On CCSDS level • On ESA/ECSS level • Perform analysis of currently existing security mechanisms and standards • Check whether they can be used in the future and where ESA needs to improve • Example: PSS TC authentication system causes a lot of trouble both on the authentication algorithm and the technical implementation in ESA systems • Buzzwords: Interoperability, Transparency, Open systems

34. Results and further objectives • Study has already produced some promising results • Analysis of PSS authentication standard has revealed several basic problems with TC authentication • A ground segment analysis has identified several weaknesses in the ground infrastructure security • A recommendation of security inclusion in the packet TM/TC standards is provided with proper justification • Further objectives • Investigate the topic of key management for ground and space link key distribution • Provide further suggestions for increasing the security situation in the ground segment • Investigate impact of security on satellite emergency situations • End-to-End security and the problems with interoperability services such as SLE

35. Summary • This presentation has given a very high level overview on security enhancing techniques • The maximum security is achieved by a synergy of all these techniques • How do we protect our satellites? • Risk Assessment on our systems • Implementation of appropriate countermeasures • Simple countermeasures can easily be implemented • A long term plan must also be developed • Development of standardised security supporting protocols for the space link

36. Tank You for Your time Any questions?