A Blueprint for Handling Sensitive Data: Security, Privacy, and Other Considerations

1. A Blueprint for Handling Sensitive Data: Security, Privacy, and Other Considerations David Escalante Director, Computer Policy & Security Boston College Monday, July 30, 2007, 8:30am-12:00pm Campus Technology 2007 Washington, DC

2. Seminar Goals At the end of this session: • You should feel comfortable discussing common cybersecurity risks plaguing higher education and computer users in general. • You will have a list of key strategies to pursue for stopping the leakage of confidential/sensitive data. • You will be introduced to several security resources and best practices to help you apply the key strategies.

3. Agenda (1) • Overview and Introductions • Creating a Security Risk-Aware Culture • Defining Institutional Data Types • Clarifying Responsibility and Accountability • Reducing Access to Data Not Absolutely Essential

4. Agenda (2) • Establishing & Implementing Stricter Controls • Providing Awareness and Training • Managing Sensitive Data Outreach Programs • Verifying Compliance • Putting It All Together • Evaluation and Wrap-Up

5. Icebreaker • Human Scavenger Hunt • Instructions: • Take a moment to read entire list (front and back) • Obtain as many signatures as possible in the time allotted • An individual may sign your sheet only once • Fill in the blanks when space is provided

6. The Blueprint ConfidentialData Handling Blueprint Purpose • To provide a list of key strategies to follow for stopping the leakage of confidential/sensitive data. • To provide a toolkit that constructs resources pertaining to confidential/sensitive data handling.  https://wiki.internet2.edu/confluence/display/secguide/Confidential+Data+Handling+Blueprint

7. The Blueprint ConfidentialData Handling Blueprint Introduction • Steps and ensuing sub-items are intended to provide a general roadmap • Institutions will be at varying stages of progress • Organized in a sequence that allows you to logically follow through each step • Each item is recommended as an effective practice; state/local legal requirements, institutional policy, or campus culture might leave each institution approaching this differently

8. Ingredients for Success Systems must be built and technologies deployed to adhere to policies Policies must be developed, communicated, maintained, and enforced Process Technology People Processes must be developed that show how policies will be implemented People must understand their roles and responsibilities according to policies

9. Step 1 • Create a security risk-aware culture that includes an information security risk management program • Sub-steps 1.1 Institution-wide security risk management program 1.2 Roles and responsibilities defined for overall information security at the central and distributed level 1.3 Executive leadership support in the form of policies and governance actions

10. Step 1 • Create a security risk-aware culture that includes an information security risk management program • Sub-steps 1.1 Institution-wide security risk management program 1.2Roles and responsibilities defined for overall information security at the central and distributed level 1.3 Executive leadership support in the form of policies and governance actions

11. Risk Management Framework

12. Risk Assessment Framework • Phase 0: Establish Risk Assessment Criteria for the Identification and Prioritization of Critical Assets • Phase 1: Develop Initial Security Strategies • Phase 2: Technological View – Identify Infrastructure Vulnerabilities • Phase 3: Develop Security Strategy and Plans

13. Risks Incurred ECAR IT Security Study, 2006

14. Risk Assessments • 55 percent do some type of risk assessment • But less than 9 percent cover all institutional systems and data. ECAR IT Security Study, 2006

15. Step 1 • Create a security risk-aware culture that includes an information security risk management program • Sub-steps 1.1 Institution-wide security risk management program 1.2 Roles and responsibilities defined for overall information security at the central and distributed level 1.3 Executive leadership support in the form of policies and governance actions

16. Best Practices & Metrics Information Security Program Elements: • Governance • Boards/Senior Executives/Shared Governance • Management • Directors and Managers • Technical • Central and Distributed IT Support Staff CISWG Final Report on Best Practices & Metrics

17. Governance • Oversee Risk Management and Compliance Programs Pertaining to Information Security (e.g., Sarbanes-Oxley, HIPAA, Gramm-Leach-Bliley) • Approve and Adopt Broad Information Security Program Principles and Approve Assignment of Key Managers Responsible for Information Security • Strive to Protect the Interests of all Stakeholders Dependent on Information Security • Review Information Security Policies Regarding Strategic Partners and Other Third-parties • Strive to Ensure Business Continuity • Review Provisions for Internal and External Audits of the Information Security Program • Collaborate with Management to Specify the Information Security Metrics to be Reported to the Board CISWG Final Report on Best Practices & Metrics

18. Management • Establish Information Security Management Policies and Controls and Monitor Compliance • Assign Information Security Roles, Responsibilities, Required Skills, and Enforce Role-based Information Access Privileges • Assess Information Risks, Establish Risk Thresholds and Actively Manage Risk Mitigation • Ensure Implementation of Information Security Requirements for Strategic Partners and Other Third-parties • Identify and Classify Information Assets • Implement and Test Business Continuity Plans • Approve Information Systems Architecture during Acquisition, Development, Operations, and Maintenance • Protect the Physical Environment • Ensure Internal and External Audits of the Information Security Program with Timely Follow-up • Collaborate with Security Staff to Specify the Information Security Metrics to be Reported to Management CISWG Final Report on Best Practices & Metrics

19. Technical • User Identification and Authentication • User Account Management • User Privileges • Configuration Management • Event and Activity Logging and Monitoring • Communications, Email, and Remote Access Security • Malicious Code Protection, Including Viruses, Worms, and Trojans • Software Change Management, including Patching • Firewalls • Data Encryption • Backup and Recovery • Incident and Vulnerability Detection and Response • Collaborate with Management to Specify the Technical Metrics to be Reported to Management CISWG Final Report on Best Practices & Metrics

20. Responsibility for IT Security • IT Security Officer (up to 35% from 22%) • CIO (up to 14% from 8%) • Other IT Directors (down to 50% from 67%)

21. IT Security Plan • 11.2 percent - a comprehensive IT security plan is in place • 66.6 percent - a partial plan is in place • 20.4 percent - no IT security plan is in place ECAR IT Security Study, 2006

22. Characteristics of Successful IT Security Programs • Institutions with IT security plans in place characterize their IT security programs as more successful and feel more secure today. • The respondents who believe their institution provides necessary resources give higher ratings for IT security program success and their current sense of IT security. • The biggest barrier to IT security is lack of resources (64.4 percent) and especially at smaller institutions, followed by an academic culture of openness and autonomy (49.6 percent), and lack of awareness (36.4 percent). ECAR IT Security Study, 2006

23. Step 1 • Create a security risk-aware culture that includes an information security risk management program • Sub-steps 1.1 Institution-wide security risk management program 1.2 Roles and responsibilities defined for overall information security at the central and distributed level 1.3 Executive leadership support in the form of policies and governance actions

24. Information Security Governance If businesses, educational institutions, and non-profit organizations are to make significant progress securing their information assets, executives must make information security an integral part of core business operations. There is no better way to accomplish this goal than to highlight it as part of the existing internal controls and policies that constitute corporate governance. Information Security Governance Report: Executive Summary

25. InfoSec Governance Self Assessment • Organizational Reliance on IT • E.g., What is the impact of major system downtime on operations? • Risk Management • E.g., Has your organization conducted a risk assessment and identified critical assets? • People • E.g., Is there a person or organization that has information security as their primary duty? • Processes • E.g., Do you have official written information security policies and procedures? • Technology • E.g., Is sensitive data encrypted? Information Security Governance Assessment Tool for Higher Education

26. Policies in Place • Individual employee responsibilities for information security practices (73%) • Protection of organizational assets (73%) • Managing privacy issues, including breaches of personal information (72%) • Incident reporting and response (69%) • Disaster recovery contingency planning (68%)

27. Policies in Place • Investigation and correction of the causes of security failures (68%) • Notification of security events to: individuals, the law, etc. (67%) • Sharing, storing, and transmitting data (51%) • Data classification, retention, and destruction (51%) • Identity Management (50%)

28. Step 2 • Define institutional data types • Sub-steps 2.1 Compliance with applicable federal and state laws and regulations - as well as contractual obligations - related to privacy and security of data held by the institution (also consider applicable international laws) 2.2 Data classification schema developed with input from legal counsel and data stewards 2.3 Data classification schema assigned to institutional data to the extent possible or necessary

29. Step 2 • Define institutional data types • Sub-steps 2.1 Compliance with applicable federal and state laws and regulations - as well as contractual obligations - related to privacy and security of data held by the institution (also consider applicable international laws) 2.2Data classification schema developed with input from legal counsel and data stewards 2.3 Data classification schema assigned to institutional data to the extent possible or necessary

30. All-In-One Compliance

31. Step 2 • Define institutional data types • Sub-steps 2.1 Compliance with applicable federal and state laws and regulations - as well as contractual obligations - related to privacy and security of data held by the institution (also consider applicable international laws) 2.2 Data classification schema developed with input from legal counsel and data stewards 2.3 Data classification schema assigned to institutional data to the extent possible or necessary

32. Data Classification Policy Provides the framework necessary to: • Identify and classify data in order to assess risk and implement an appropriate level of security protection based on categorization. • Comply with legislation, regulations, and internal policies that govern the protection of data. • Facilitate and make the Incident Response process more efficient. The level in which the data is classified determines the level of response.

33. SP 800-60 NIST Security Categorization Example: An Enterprise Information System Mapping Information Types to FIPS 199 Security Categories

34. Data Classification at GW Privacy Levels Operations Levels Public Official Confidential Highest Security Highest Operations Enterprise System 2 2 1 1 Department Server 3 2 Lowest Security Lowest Operations 2 Desktop/ Laptop 3 4 Note, numbers in boxes suggest the priority levels for mitigating risks.

35. Stanford Data Classification

36. U of Texas-Austin Data Categories

37. Qualitative Risk Assessment Exercise

38. BREAK

39. Step 3 • Clarify responsibilities and accountability for safeguarding confidential/sensitive data • Sub-steps 3.1Data stewardship roles and responsibilities 3.2Legally binding third party agreements that assign responsibility for secure data handling

40. Step 3 • Clarify responsibilities and accountability for safeguarding confidential/sensitive data • Sub-steps 3.1Data stewardship roles and responsibilities 3.2Legally binding third party agreements that assign responsibility for secure data handling

41. Example – University of North Carolina • Data Trustee: Data trustees are senior University officials (or their designees) who have planning and policy-level responsibility for data within their functional areas and management responsibilities for defined segments of institutional data. Responsibilities include assigning data stewards, participating in establishing policies, and promoting data resource management for the good of the entire University. • Data Steward: Data stewards are University officials having direct operational-level responsibility for information management – usually department directors. Data stewards are responsible for data access and policy implementation issues. • Data Custodian: Information Technology Services is the data custodian. The custodian is responsible for providing a secure infrastructure in support of the data, including, but not limited to, providing physical security, backup and recovery processes, granting access privileges to system users as authorized by data trustees or their designees (usually the data stewards), and implementing and administering controls over the information. • Data User: Data users are individuals who need and use University data as part of their assigned duties or in fulfillment of assigned roles or functions within the University community. Individuals who are given access to sensitive data have a position of special trust and as such are responsible for protecting the security and integrity of those data. http://its.uncg.edu/Policy_Manual/Data/

42. Step 3 • Clarify responsibilities and accountability for safeguarding confidential/sensitive data • Sub-steps 3.1Data stewardship roles and responsibilities 3.2Legally binding third party agreements that assign responsibility for secure data handling

43. Outsourced Data Handling • Some Drivers • Security of Commercial Software – addressed elsewhere (Step 7.4) • Incidents: Mishandling by 3rd Parties • GLB Act: Oversight of Service Providers • PCI requirement • Federal Contracts and Grant • Sample Contract Language • E-mail instructor for a copy

44. Step 4 • Reduce access to confidential/sensitive data not absolutely essential to institutional processes • Sub-steps 4.1 Data collection processes (including forms) should request only the minimum necessary confidential/sensitive information 4.2 Application outputs (e.g., queries, hard copy reports, etc.) should provide only the minimum necessary confidential/sensitive information 4.3 Inventory and review access to existing confidential/sensitive data on servers, desktops, and mobile devices

45. Step 4 continued… • Reduce access to confidential/sensitive data not absolutely essential to institutional processes • Sub-steps continued 4.4 Eliminate unnecessary confidential/sensitive data on servers, desktops, and mobile devices 4.5 Eliminate dependence on SSNs as primary identifiers and as a form of authentication* *Note: SSNs may need to be used for certain things (e.g., student employees, student financial aid, etc.) and we recommend that schools limit the use of SSNs to necessary processes only.

46. Step 4 • Reduce access to confidential/sensitive data not absolutely essential to institutional processes • Sub-steps 4.1 Data collection processes (including forms) should request only the minimum necessary confidential/sensitive information 4.2 Application outputs (e.g., queries, hard copy reports, etc.) should provide only the minimum necessary confidential/sensitive information 4.3 Inventory and review access to existing confidential/sensitive data on servers, desktops, and mobile devices

47. Fair Information Practices and Privacy • General Principles of Fair Information Practice: • Openness • Individual Participation • Collection Limitation • Data Quality • Finality • Security • Accountability • Privacy Statements • Privacy Policies

48. Step 4 • Reduce access to confidential/sensitive data not absolutely essential to institutional processes • Sub-steps 4.1 Data collection processes (including forms) should request only the minimum necessary confidential/sensitive information 4.2 Application outputs (e.g., queries, hard copy reports, etc.) should provide only the minimum necessary confidential/sensitive information 4.3 Inventory and review access to existing confidential/sensitive data on servers, desktops, and mobile devices

49. Step 4 • Reduce access to confidential/sensitive data not absolutely essential to institutional processes • Sub-steps 4.1 Data collection processes (including forms) should request only the minimum necessary confidential/sensitive information 4.2 Application outputs (e.g., queries, hard copy reports, etc.) should provide only the minimum necessary confidential/sensitive information 4.3 Inventory and review access to existing confidential/sensitive data on servers, desktops, and mobile devices

50. Step 4 continued… • Reduce access to confidential/sensitive data not absolutely essential to institutional processes • Sub-steps continued 4.4 Eliminate unnecessary confidential/sensitive data on servers, desktops, and mobile devices 4.5 Eliminate dependence on SSNs as primary identifiers and as a form of authentication* *Note: SSNs may need to be used for certain things (e.g., student employees, student financial aid, etc.) and we recommend that schools limit the use of SSNs to necessary processes only.