What these organizations have in common?

1. What these organizations have in common? • American Education Services, PA • United States Marine Corps / Penn State University • St. Vincent Hospital • Fox News • SAIC, (San Diego, CA) • Western Union • Fidelity National Information Services Computer Science and Engineering

2. What these organizations have in common? • American Education Services, PA • United States Marine Corps / Penn State University • St. Vincent Hospital • Fox News • SAIC, (San Diego, CA) • Western Union • Fidelity National Information Services Security Breaches July 2007 http://www.privacyrights.org/ar/ChronDataBreaches.htm#2007 Computer Science and Engineering

3. Computer Science and Engineering

4. Computer Science and Engineering

5. Csilla Farkas Associate Professor Dept. of Computer Science and Engineering University of South Carolina farkas@cse.sc.edu http://www.cse.sc.edu/~farkas Computer Science and Engineering

6. Prevent/detect/deter improper Disclosure of information Secrecy Prevent/detect/deter Improper modification of information Integrity Availability Prevent/detect/deter improper Denial of access to services Security Objectives Computer Science and Engineering

7. Security Tradeoffs Security Functionality COST Ease of Use Computer Science and Engineering

8. Achieving Security • Policy • What to protect? • Mechanism • How to protect? • Assurance • How good is the protection? Computer Science and Engineering

9. Policy Organizational policy Information systems policy Computer Science and Engineering

10. Security by Obscurity • Hide inner working of the system • Bad idea! • Vendor independent open standard • Widespread computer knowledge Computer Science and Engineering

11. Security by Legislation • Instruct users how to behave • Not good enough! • Important • Only enhance security • Targets only some of the security problems Computer Science and Engineering

12. Security Mechanism • Prevention • Detection • Tolerance and Recovery Computer Science and Engineering

13. Prevention: Access Control • Ensures that all direct accesses are authorized • Protects against accidental and malicious threats Computer Science and Engineering

14. Access Control • Subject: active entity that requests access to an object - e.g., user or program • Object: passive entity accessed by a subject - e.g., record, relation, file • Access right (privileges): how a subject is allowed to access an object - e.g., subject s can read object o Computer Science and Engineering

15. Access Control Models • Discretionary Access Control (DAC) • Mandatory Access Control (MAC) • Role-Based Access Control (RBAC) Computer Science and Engineering

16. Discretionary Access Control (DAC) • For each subject access right to the objects are defined. • User based • Grant and Revoke • Problems: - Propagation of access rights - Revocation of propagated access rights Computer Science and Engineering

17. GRANT SELECT ON Employee TO Red GRANT SELECT ON Employee TO Black WITH GRANT OPTION ? Brown revokes grant given to Black ? • Brown does not want • Red to access the • Employee relation GRANT UPDATE(Salary) ON Employee TO White DAC by Grant and Revoke Black Red Brown (owner) White Computer Science and Engineering

18. Mandatory Access Control (MAC) • Security label • Dominance (), e.g.,Top-Secret  Secret  Public • Objects: security classification - File 1 is Secret, File 2 is Public • Subjects: security clearances - Brown is cleared to Secret, Black is cleared to Public • Access rights: defined by comparing the security classification of the requested objects with the security clearance of the subject Computer Science and Engineering

19. MAC – Bell-LaPadula (BLP) Model • Single security property: a subject S is allowed a read access to an object O only if label(S) dominates label(O) • Star-property: a subject S is allowed a write access to an object O only if label(O) dominates label(S) No direct flow of information from high security objects to low security objects! Computer Science and Engineering

20. Role-Based Access Control (RBAC) • Express organizational policies - Separation of duties - Delegation of authority • Flexible: easy to modify to meet new security requirements • Supports - Least-privilege - Separation of duties - Data abstraction Computer Science and Engineering

21. RBAC0 U Users User assignment Permission assignment R Roles P Permissions . . . S Sessions Computer Science and Engineering

22. ResearchSecure Semantic Web Computer Science and Engineering

23. Web Evolution • Past: Human usage • HTTP • Static Web pages (HTML) • Current: Human and some automated usage • Interactive Web pages • Web Services (WSDL, SOAP, SAML) • Semantic Web (RDF, OWL, RuleML, Web databases) • XML technology (data exchange, data representation) • Future: Semantic Web Services Computer Science and Engineering

24. Research Areas • Access Control for • Data • Metadata • Application Computer Science and Engineering

25. Secure XML Views medicalFiles <medicalFiles> UC <countyRec> S <patient> S <name>John Smith </name> UC <phone>111-2222</phone> S </patient> <physician>Jim Dale </physician> UC </countyRec> <milBaseRec> TS <patient> S <name>Harry Green</name> UC <phone>333-4444</phone> S </patient> <physician>Joe White </physician> UC <milTag>MT78</milTag> TS </milBaseRec> </medicalFiles> countyRec milBaseRec physician Jim Dale physician Joe White milTag MT78 patient patient name John Smith phone 111-2222 name Harry Green phone 333-4444 View over UC data Computer Science and Engineering

26. Secure XML Views (cont.) medicalFiles <medicalFiles> <countyRec> <patient> <name>John Smith</name> </patient> <physician>Jim Dale</physician> </countyRec> <milBaseRec> <patient> <name>Harry Green</name> </patient> <physician>Joe White</physician> </milBaseRec> </medicalFiles> countyRec milBaseRec physician Jim Dale physician Joe White patient patient name John Smith name Harry Green View over UC data Computer Science and Engineering

27. Secure XML Views (cont.) medicalFiles <medicalFiles> <tag01> <tag02> <name>John Smith</name> </tag02> <physician>Jim Dale</physician> </tag01> <tag03> <tag02> <name>Harry Green</name> </tag02> <physician>Joe White</physician> </tag03> </medicalFiles> countyRec milBaseRec physician Jim Dale physician Joe White patient patient name John Smith name Harry Green View over UC data Computer Science and Engineering

28. Secure XML Views (cont.) medicalFiles <medicalFiles> UC <countyRec> S <patient> S <name>John Smith</name> UC </patient> <physician>Jim Dale</physician> UC </countyRec> <milBaseRec> TS <patient> S <name>Harry Green</name> UC </patient> <physician>Joe White</physician> UC </milBaseRec> </medicalFiles> countyRec milBaseRec physician Jim Dale physician Joe White patient patient name John Smith name Harry Green View over UC data Computer Science and Engineering

29. Secure XML Views (cont.) medicalFiles <medicalFiles> <name>John Smith</name> <physician>Jim Dale</physician> <name>Harry Green</name> <physician>Joe White</physician> </medicalFiles> physician Jim Dale name John Smith physician Joe White name Harry Green View over UC data Computer Science and Engineering

30. Multi-Plane DTD Graph <milBaseRec> D,medicalFiles UC <milTag> TopSecret S TS D, countyRec D, milBaseRec <countyRec> UC S TS D, physician <patient> D, patient D, milTag Secret <phone> UC S D, name D, phone <physician> <name> <medicalFiles> Unclassified MPG = DTD graph over multiple security planes Computer Science and Engineering

31. Transformation <milBaseRec> MPG <milTag> TS MSCG <countyRec> <patient> name phone S <phone> physician <medicalFiles> Security Space Secret UC <physician> <name> Computer Science and Engineering

32. Transformation <milBaseRec> <milTag> TS <countyRec> <patient> name S <phone> physician <emrgRec> <medicalFiles> MSCG UC <physician> <name> SP MPG Computer Science and Engineering

33. Transformation <milBaseRec> <milTag> TS <countyRec> <patient> S <phone>  <emrgRec> <medicalFiles> MSCG UC <physician> <name> SP MPG Computer Science and Engineering

34. Transformation <milBaseRec> <milTag> TS medicalFiles <countyRec> <patient> emergencyRec S <phone> physician <emrgRec> name <medicalFiles> UC <physician> <name> SP Data Structure MPG Computer Science and Engineering

35. Metadata Security • No security model exists for metadata • Can we use existing security models to protect metadata? • RDF/S is the Basic Framework for SW • RDF/S supports simple inferences • This is not true of XML: XML Access control cannot be used to protect RDF /S data Computer Science and Engineering

36. Example Graph Format • RDF Triples: • (Student, rdfs:subClassOf, Person) • (University, rdfs:subClassOf, GovAgency) • (studiesAt, rdfs:domain, Student) • (studiesAt, rdfs:range,University) • (studiesAt, rdfs:subPropertyOf, memberAt) • (John, studiesAt, USC) Computer Science and Engineering

37. Example Graph Format Computer Science and Engineering

38. Example Graph Format Computer Science and Engineering

39. Example Graph Format Computer Science and Engineering

40. Secure RDF Entailed Data in RDF can cause illegal inferences: • (John, studiesAt, USC) [S] + (studiesAt, rdfs:domain, University) [S]  (USC, rdf:type, University) [S] • (USC, rdf:type, University) [S]+ (University, rdf:subclassOf, GovAgency) [S]  (USC, rdf:type, GovAgency) [TS] Secret User can infer TS information Computer Science and Engineering

41. RDF Access Control • Security Policy • Subject • Object – Object pattern • Access Mode • Default policy • Conflict Resolution • Classification of entailed data • Flexible granularity Computer Science and Engineering

42. Application Security Security Policy: • Application semantics (from syntax to semantics) • External requirements • Privacy • Trust management • Compliance checking Computer Science and Engineering

43. How to become information security professional? Computer Science and Engineering

44. EDUCATION: Graduate Certificate Program in Information Assurance and Security (IA&S) Computer Science and Engineering

45. CNSS Certifications • National Training Standard for Information Systems Security Professionals, CNSSI No. 4011 • National Training Standard for System Administrators in Information Systems Security, CNSSI No. 4013 • National Training Standard for Information Systems Security Officers, CNSSI No. 4014 Computer Science and Engineering

46. Core Courses • CSCE 522 – Information Systems Security Principles • offered every Fall semester • CSCE 715– Network Security • offered every Fall semester • CSCE 727 – Information Warfare • offered every 3rd semester Computer Science and Engineering

47. Elective Courses • CSCE 517 – Computer Crime and Forensics • CSCE 557 – Introduction to Cryptography • CSCE 548 – Secure Software Construction • CSCE 716 – Design for Reliability • CSCE 717 – Comp. Systems Performance • CSCE 813 – Internet Security • CSCE 814 – Distributed Systems Security • CSCE 824 – Secure Databases • CSCE 853 – Formal Models of Information Security Computer Science and Engineering

48. Undergraduate Education • New undergraduate courses: • CSCE 201: Introduction to Information Security Computer Science and Engineering

49. Questions? Computer Science and Engineering