1. Security Administration II Trusted Systems Social Context

2. CSCE 522 - Farkas2 When Can a System be Trusted? Identify objectives Identify risks and vulnerabilities Identify security requirements Identify systems with appropriate levels of trust

3. CSCE 522 - Farkas3 Vulnerabilities Security objectives: Prevent attacks Detect attacks Recover from attacks Attacks: against weaknesses in the information systems Need: find weaknesses

4. CSCE 522 - Farkas4 Avoiding Weaknesses  Vulnerability monitoring  Secure system development  User training and awareness  Avoiding single point of failure

5. CSCE 522 - Farkas5 Vulnerability Monitoring Identify potential weaknesses in existing information systems Reveal wide-range of vulnerabilities

6. CSCE 522 - Farkas6 Secure Software Installation Correct installation of software Change default settings Validate upgrades/changes Patch new security flaws

7. CSCE 522 - Farkas7 Vulnerability Detection Tools COPS SATAN SARA SAINT MBSA SAFEsuite Many others

8. CSCE 522 - Farkas8 COPS Computer Oracle and Password System FREE Checks vulnerabilities of UNIX systems

9. CSCE 522 - Farkas9 SARA Security Auditor’s Research Assistant Descendent of SATAN

10. CSCE 522 - Farkas10 SAINT Security Administrator’s Integrated Network Tool Commercial product

11. CSCE 522 - Farkas11 MBSA Microsoft Baseline Security Analyzer Checks Microsoft systems

12. CSCE 522 - Farkas12 SAFEsuite Internet Security Systems, Inc. Family of network security assessment tools Web security scanner Firewall scanner Intranet scanner System security scanner) Keyed to the IP address of the customer

13. CSCE 522 - Farkas13 Security Publications Legal publications: how to remove vulnerabilities CERT advisories SANS Security Digest Hacker publications: “how to” exploit known vulnerabilities Security mailing lists

14. CSCE 522 - Farkas14 Early Security Criteria 1960s: US Department of Defense (DoD) risk of unsecured information systems 1981: National Computer Security Center (NCSC) at the NSA DoD Trusted Computer System Evaluation Criteria (TCSEC) == Orange Book

15. CSCE 522 - Farkas15 Orange Book Orange Book objectives Guidance of what security features to build into new products Provide measurement to evaluate security of systems Basis for specifying security requirements Security features and Assurances Trusted Computing Base (TCB) security components of the system

16. CSCE 522 - Farkas16 Orange Book Levels Highest Security  A1 Verified protection  B3 Security Domains  B2 Structured Protection  B1 labeled Security Protections  C2 Controlled Access Protection  C1 Discretionary Security Protection  D Minimal Protection No Security

17. CSCE 522 - Farkas17 Security Policy C1C2B1B2B3A1 DAC++nc + Object Reuse0+nc Labels00++nc Label integrity00+nc Exploration of labeled info00+nc Labeling human-readable output00+nc MAC00++nc Subject sensitive labels000+nc Device Labels000+nc 0no requirements + added requirement ncno change MAC (from lecture notes of Jajodia http:www.ise.gmu.edu)

18. CSCE 522 - Farkas18 Accountability C1C2B1B2B3A1 Identification and Authentication+++nc Audit0++++nc Trusted Path000++nc 0no requirements + added requirement ncno change Assurance changes (from lecture notes of Jajodia http:www.ise.gmu.edu)

19. CSCE 522 - Farkas19 Assurance C1C2B1B2B3A1 System Architecture+++++nc System Integrity+nc Security Testing++++++ Design Specification and Verification00++++ Covert Channel Analysis000+++ Trusted Facility Management000++nc Configuration Management000+nc+ Trusted Recovery0000+nc Trusted Distribution00000+ 0no requirements + added requirement ncno change No covert channel (from lecture notes of Jajodia http:www.ise.gmu.edu)

20. CSCE 522 - Farkas20 Documentation C1C2B1B2B3A1 Security Features User’s Guide+nc Trusted Facility Manual+++++nc Test Documentation+nc + + Design Documentation+nc++++ 0no requirements + added requirement ncno change (from lecture notes of Jajodia http:www.ise.gmu.edu)

21. CSCE 522 - Farkas21 Covert Channel Analysis B1: no requirements B2: covert storage channels B3: covert channels (timing and storage channels) A1: formal methods (proof of covert channel analysis) (from lecture notes of Jajodia http:www.ise.gmu.edu)

22. CSCE 522 - Farkas22 Design Specifications DTLS Descriptive top-level specification FTLS Formal top-level specification Specifications for TCB (trusted computing base) (from lecture notes of Jajodia http:www.ise.gmu.edu)

23. CSCE 522 - Farkas23 C and B Requirements C2: no requirement B1: informal or formal model of the security policy B2: formal model of the security policy that is proven consistent with its axioms, B3: convincing argument shall be given that the DTLS is consistent with the model (from lecture notes of Jajodia http:www.ise.gmu.edu)

24. CSCE 522 - Farkas24 A Requirements A1: FTLS (formal top-level specification) of the TCB Formal and informal techniques to show that FTLS is consistent with the model Convincing argument the DTLS is consistent with the model (from lecture notes of Jajodia http:www.ise.gmu.edu)

25. CSCE 522 - Farkas25 Orange Book Classes C1, C2: simple enhancement of existing systems. Does not break applications. B1: relatively simple enhancement of existing system. May break some of the applications. B2: major enhancement of existing systems. Will break many applications. B3: failed A1 A1: top-down design and implementation of a new system from scratch. (from lecture notes of Jajodia http:www.ise.gmu.edu)

26. CSCE 522 - Farkas26 Orange Book Criticisms Mixes various levels of abstraction in a single document Does not address integrity of data Combines functionality and assurance in a single linear rating scale (from lecture notes of Jajodia http:www.ise.gmu.edu)

27. CSCE 522 - Farkas27 Functionality vs. Assurance functionality assurance C1 C2 B1 B2 B3 A1 functionality is multidimensional assurance has a linear progression (from lecture notes of Jajodia http:www.ise.gmu.edu)

28. CSCE 522 - Farkas28 NCSC Rainbow Series Orange: Trusted Computer System Evaluation Criteria Yellow: Guidance for applying the Orange Book Red: Trusted Network Interpretation Lavender: Trusted Database Interpretation (from lecture notes of Jajodia http:www.ise.gmu.edu)

29. CSCE 522 - Farkas29 Assurance Methods Testing Penetration testing Formal verification Validation Open source

30. CSCE 522 - Farkas30 Testing Developer testing User testing Penetration testing (aka tiger team analysis, ethical hacking Can show existence of problems Can not show that problems don’t exist

31. CSCE 522 - Farkas31 Other Approaches Formal verification Based upon assertions and proofs Validation Show that all required functionality is present (not just that what is there works) Open source A form of peer review A lot of debate on this

32. CSCE 522 - Farkas32 European Criteria German Information Security Agency: German Green Book (1988) British Department of Trade and Industry and Ministry of Defense: several volumes of criteria Canada, Australia, France: works on evaluation criteria 1991: Information Technology Security Evaluation Criteria (ITSEC) For European community Decoupled features from assurance Introduced new functionality requirement classes Accommodated commercial security requirements

33. CSCE 522 - Farkas33 United States January 1996: Common Criteria (CC) Joint work with Canada and Europe Separates functionality from assurance

34. CSCE 522 - Farkas34 CC Functionality Audit Communications User data protection Identification and authentication Privacy Protections of trusted functions Resource utilization Establishing user sessions Trusted path

35. CSCE 522 - Farkas35 CC Assurance Configuration management Delivery and operation Development Guidance documents Life cycle support Tests Vulnerability assessment

36. CSCE 522 - Farkas36 Common Criteria Evaluation Assurance Levels (EAL) EAL1: functionally tested EAL2: structurally tested EAL3: methodologically tested and checked EAL4: methodologically designed, tested and reviewed EAL5: semi-formally designed and tested EAL6: semi-formally verified and tested EAL7: formally verified design and tested

37. CSCE 522 - Farkas37 National Information Assurance Partnership (NIAP) 1997: National Institute of Standards and Technology (NIST), National Security Agency (NSA), and Industry Aims to improve the efficiency of evaluation Transfer methodologies and techniques to private sector laboratories

38. CSCE 522 - Farkas38 NIAP Functions Develop tests Test methods and tools for evaluating and improving security products Develop protections profiles and associated tests Establish formal and international schema for CC

39. CSCE 522 - Farkas39 Security Awareness and Training Major weakness: user unawareness Organizational effort Educational effort Customer training Federal Trade Commission: program to educate customers about web scams

40. CSCE 522 - Farkas40 Avoid Single Point of Failure Critical information resources Identification Backup Hiding Separation of duties Multi-person requirements Limit temptations

41. CSCE 522 - Farkas41 A Legal Perspective Protecting Programs and Data Information and the Law Rights of Employees and Employers Software Failures Computer Crime Privacy Ethical Issues in Computer Security

42. CSCE 522 - Farkas42 Relationship to Security Relationship of topics discussed to computer security is not always clear Legal and ethical issues involving computers are often, not always, security issues Example: Ownership of program code

43. CSCE 522 - Farkas43 Legal Issues Laws provide a framework in which security issues can/must be addressed Constraints Things you can’t do Requirements Things you must do

44. CSCE 522 - Farkas44 Privacy Issues Combine legal requirements and social expectations Privacy refers to protection/release of personal information Confidentiality refers to protection/release of information in general

45. CSCE 522 - Farkas45 Ethical Issues Ethics involves generally accepted standards of proper behavior Ethical principle – “an objectively defined standard of right and wrong” Ethical system – “a set of ethical principles” The United States is an ethically pluralistic society

46. CSCE 522 - Farkas46 Law and Ethics It is possible for an action to be legal but not ethical It is possible for an action to be ethical but not legal What these actions are depends upon the ethical system used

47. CSCE 522 - Farkas47 Some Privacy Issues Identity theft Data mining Carnivore Passport Anonymity Computer voting E.U. Data Protection Act (personal data) Gramm-Leach-Bliley (financial information) HIPAA (health information)

48. CSCE 522 - Farkas48 Additional Privacy Issues US Privacy Act US Electronic Communications Privacy Act US Patriot Act

49. CSCE 522 - Farkas49 Software Ownership Protecting information about software Possible protection mechanisms:  Trade secret  Copyright (DMCA)  Patent

50. CSCE 522 - Farkas50 Who/What is Protected? Code and data  Personal data Rights of employees/employers Program users System users

51. CSCE 522 - Farkas51 Criminal vs. Civil Law Criminal law – actions against the state Statutes Civil law – actions against individuals/other private entities Precedents Contract law – actions in violation of a contract

52. CSCE 522 - Farkas52 How are Computer Crimes Different from Other Crimes? Unfamiliarity of criminal justice system with computers and computer terminology Need to deal with intangible and easily copied property

53. CSCE 522 - Farkas53 International Issues Laws are different in different countries. Computer networks are international. Who has “jurisdiction” over a computer crime? Can software/data be effectively excluded? Privacy concerns Cryptography

54. CSCE 522 - Farkas54 Ethical Principles Consequence-based: teleology Egoism Utilitarianism Rule-based: deontology Rule-deontology Personal Professional codes of ethics