1. Security Vulnerability Detection and reduction Linda Cornwall MWSG, CERN 24 Feb 2005 L.A.Cornwall@rl.ac.uk

2. 24-Feb-05Security Vulnerability - Linda Cornwall2 Introduction Where are we? Why do we need to act? What are we protecting and preventing happening by addressing vulnerabilities? How to approach it Discussion

3. 24-Feb-05Security Vulnerability - Linda Cornwall3 Where are we? In DataGrid and EGEE a lot has been done on Security Functionality –Requirements –Design –Implementation –Deployment Is the grid secure? –We know some vulnerabilities are there, some are being fixed by developers, some are waiting to be exploited by hackers

4. 24-Feb-05Security Vulnerability - Linda Cornwall4 Why do we need to act? We could be considered highly negligent if we continue to role out Grid deployment without dealing with vulnerabilities It will be really embarrassing if when LHC comes on line we get a serious attack on the grid system which prevents data being stored or processed Hackers Conference HOPE mentioned Grids –unfriendly people without credentials are becoming aware of us 1000s of users in 10’s CAs –we cannot guarantee that every person with a correctly issued certificate is trustworthy

5. 24-Feb-05Security Vulnerability - Linda Cornwall5 What are we protecting? Firstly, we need to protect the system Ensure the system is available and working Cannot be disrupted by an authorized user –On purpose –By mistake Cannot be disrupted by a hacker

6. 24-Feb-05Security Vulnerability - Linda Cornwall6 Protect others from our system Prevent our system being used to crack a certificate by brute force Prevent denial of service attacks from our system Ensure it’s not used to store and distribute illegal material If we don’t take care to address these issues we could find ourselves in serious trouble, it would be more than embarrassing, we may be considered criminally negligent for setting up these systems without sufficient protection

7. 24-Feb-05Security Vulnerability - Linda Cornwall7 Protect Data We need to ensure that data is stored in a reliable manner We need to ensure that data cannot get accessed by those who should not access it –Especially confidential data

8. 24-Feb-05Security Vulnerability - Linda Cornwall8 Protect the user We need to protect the user from being accused of doing something they did not do We need to protect the user from doing something they did not intend to do –Large bills –Possibly more in the future

9. 24-Feb-05Security Vulnerability - Linda Cornwall9 3 way approach Checklists –One for Middleware –One for Deployment Vulnerability logging –Logging knowledge of specific vulnerabilities Anti use cases –Use cases that should be prevented

10. 24-Feb-05Security Vulnerability - Linda Cornwall10 Checklists My document contains checklists for Middleware and Deployment The middleware list is more developed Some may seem obvious – I don’t apologise for this, if they are so simple and taken care of a tick is all that is needed I don’t claim they complete – anyone is free to suggested additions or changes They are intended to indicate what to check –not formal –not much detail – not re-writing secure programming text books!

11. 24-Feb-05Security Vulnerability - Linda Cornwall11 Checklists – (cont) Middleware developers check against the middleware list to help reduce vulnerability Note that these checklists are not a substitute for requirements

12. 24-Feb-05Security Vulnerability - Linda Cornwall12 Middleware Checklist For middleware so far I have around 116 checks in 22 categories including –Design –Input checking –Middleware Access to the system –File Handling –Logging –Testing Tried to class them –SV – Specific vulnerability –VIR – Vulnerability Impact Reduction –VRR – Vulnerability Risk Reduction –ADL - Activity Detection and Logging

13. 24-Feb-05Security Vulnerability - Linda Cornwall13 Middleware Design DES-02 Design for robustness –Design such that if one part of the system is mis- configured or fails the whole system doesn’t fail –Means 1 hacked site does not cause the whole to fail –VIR – Vulnerability Impact Reduction DES-03 Principle of least privilege –Consider what privileges the executing software should have – try and minimize –Impact of a vulnerability is less –VIR

14. 24-Feb-05Security Vulnerability - Linda Cornwall14 Communications COM-01 Use Established protocols –Less likely to have a vulnerability if you do not invent your own! –VRR – Vulnerability Risk Reduction COM-05 Encrypt sensitive information –Obvious! –SV – Specific Vulnerability

15. 24-Feb-05Security Vulnerability - Linda Cornwall15 Input Checking INP-01 Validate all input INP-02 Validate at each connection –You cannot assume your own client is used, even if your client validates the input! INP-07 Check for input that links to input from elsewhere –Don’t allow this to be a way of bypassing the checking

16. 24-Feb-05Security Vulnerability - Linda Cornwall16 Logging Logging is important to ensure that any abnormal activity is detected. LOG-02 Log access to resources LOG-03 Log usage of resources LOG-05 Traceable logging –Ensure users credentials are logged All ADL – activity detection and logging

17. 24-Feb-05Security Vulnerability - Linda Cornwall17 Deployment and Configuration So far about 35 checks, e.g. VER-02 Apply all critical patches CRD-01 Password protect all private keys CRD-02 Private keys must not be shared Will add more, open to suggestions, some will come as a result of the specific vulnerability logging

18. 24-Feb-05Security Vulnerability - Linda Cornwall18 Tables Each development team is encouraged to use the list –After a bit of improvement For each item on the checklist to check, –Rel – tick if relevant, if not do nothing –Checked, tick if carried out –Result – if O.K. nothing more. –Otherwise Refer to a description of the problem, whether or not it’s been tackled. –Comment – if only 3-4 words are enough.

19. 24-Feb-05Security Vulnerability - Linda Cornwall19 Known Vulnerabilities We should produce a ‘known vulnerability’ log Collect information from people like sysadmins and loose cannons, as well as developers We must keep such a list away from public consumption –At least until we have a fix We must encourage people to address the known vulnerabilities

20. 24-Feb-05Security Vulnerability - Linda Cornwall20 Vulnerability logging Location – where the problem is Vulnerability – brief description of the problem Exploitation – whether it has been exploited and who could exploit it –No credentials, authenticated only, authorized user, or a sysadmin Analysis –Configuration problem? Middleware problem? Risk –What might happen if it isn’t fixed

21. 24-Feb-05Security Vulnerability - Linda Cornwall21 Vulnerability logging (cont) Proposed solution Bugs submitted Checklist reference –If a check in one of the lists would pick it up Checklist proposal –Something to add to the list to improve detection of potential vulnerabilities in the future (if appropriate) Severity? –Possibly a scale of 1 to 10? –E.g. far worse if an un-authenticated user can delete the whole database, than if in rare circumstances an authorized user can see data belonging to a different group.

22. 24-Feb-05Security Vulnerability - Linda Cornwall22 (Anti) Use Cases Suggest we have Anti Use cases, I.e. things that should not be allowed e.g. –Certificate cracking –Launch of a denial of service attack on the grid Describe what mechanisms prevent these Try and achieve them! Fix if we do achieve them!

23. 24-Feb-05Security Vulnerability - Linda Cornwall23 Summary Produce a checklist of things we should take care of to remove or reduce the risk of there being a vulnerability –One for middleware –One for deployment Check against this list to find specific vulnerability or reduce risk of vulnerability –Developers check their middleware Produce a list of known vulnerabilities Consider (anti) use cases Fix vulnerabilities –Use knowledge of specific vulnerabilities to improve the checklists I suspect it’s not possible to fix all vulnerabilities quickly Keep information on specific vulnerability away from public consumption until they are fixed Hopefully the software and deployment will get better with time

24. 24-Feb-05Security Vulnerability - Linda Cornwall24 Relation to Risk Analysis This is not a risk analysis, but a way getting rid of some of the vulnerabilities to get rid of risk When analysing specific vulnerabilities should consider the risk –Could also mention e.g. specific LCG risk no. Could refer checks on checklists to relevant risk Most of the risks in the risk analysis may be reduced by using the checklist

25. 24-Feb-05Security Vulnerability - Linda Cornwall25 Checklist Discussion (1) Is the Concept of a checklist useful? Is it along the right lines? –Do you think it should be more formal? –Categories? Classification? E-mail anything you think I should add –Not just my list – more I’m starting it and driving it and encouraging people to contribute to and use it

26. 24-Feb-05Security Vulnerability - Linda Cornwall26 Checklist Discussion (2) Should we have separate per language checklist documents? –There is some XML stuff in the Grid Incident Description and Exchange document written by Yuri Is it useful to have a detailed social engineering chapter ?

27. 24-Feb-05Security Vulnerability - Linda Cornwall27 Vulnerability Logging discussion Is what I suggest logging sensible? How should we manage this? Important to keep the information outside the public domain until it is fixed Database, with limited access? E-mail list – with moderated membership?