Con f ecting Security and Privacy

1. Confecting Security and Privacy OR How to bake a security TRA with your PIA Marcel Gingras Cinnabar Networks Inc. mgingras@cinnabar.ca 613.262.0946

2. The Cook’s Background • A major in security with a minor in privacy • Manager of Risk Analysts • TRA, PIA, BCP • Big on methodology development • IT Security since 1995, Privacy since 2001 • Public service for 16 years • IT software developer, software and network architect and network support manager

3. Recipe • Ingredients • Risk Management and Limiting Disclosure • PIA and TRA Methodologies • Preparation • Sharing the Data Gathering • Cooking • Collaborative Analysis • Testing for Doneness • Tasty Privacy and Security Safeguards

4. Conference Theme: Disclosure • Privacy Domain • Principle: Limiting Use, Disclosure, and Retention • Affects business process design • May need security “confidentiality” services to limit disclosure (authentication, authorization, confidentiality services_ • Security • Protects a business process • Provides confidentiality, integrity and availability security services

5. Disclosure Requirements using Risk Management Processes • Variety of Risk Management Processes • Business Strategic Risk • Business Service Delivery Risk (Operational) • Financial Risk Management • Business Continuity Planning (BCP) • Privacy Impact Analysis (PIA) • Security Threat and Risk Analysis (TRA) • Latter two directly analyze disclosure risks

6. Security Risk Management:A Long History • Physical security • Walls, doors, locks and safes • Military security • Protect the country, safeguard the troops • Codes and ciphers • IT Security Risk Analysis • Well developed models and methodologies

7. IT Security Risk Analysis Process • Conceptual analysis of system or application • Statement of Sensitivity • Inventory of Assets (includes classification) • Injury tests • Threat Assessment • Vulnerability Assessment • Examination of Existing Safeguards • Risk Assessment • Security Safeguard Recommendations

8. Privacy Risk Management:A Short History • Variable expectations between social groups • Values within a country, variations depending on context (commercial, banking, health, legal) • Sense of privacy being under attack • Fear of government ‘big brother’ • Fear of erosion of privacy in an IT information age • Privacy Compliance and Risk Analysis • New models, limited risk management and ‘young’ supporting methodologies

9. Current Privacy Compliance and Risk Analysis • Slanted towards compliance audit • Checklist based • No ranking of potential damages • No ranking of risk (too many yes/no questions) • No ranking of safeguard effectiveness • No action plan Unless particular privacy safeguards are specified, it’s all ‘best guess’

10. Current Privacy Compliance and Risk Analysis – The Effect • Audit against legislation and policy sufficient in some cases, but not helpful in selecting strength of privacy safeguards needed • Checklist based discourages risk analysis • Lack of risk rankings makes it difficult to justify appropriately strong solutions • Lack of a prioritized action plan makes it difficult to plan next steps in the project

11. Other Annoying Issues • Too many TLAs (Three letter acronyms) • Clutter in the project plan • Too many interviews asking the same questions • Timing issues: When to do these things to get actual value… Requirements when you need them and a reality check on the solution when you need it. • Contradictory ‘disclosure’ and ‘confidentiality’ recommendations • Potential for security solutions to be privacy invasive

12. What Can We Improve? (1) • We can do privacy protection requirements gathering, analysis, and audit at the right time in the project lifecycle process. • We can align related risk management processes (E.g. PIA and TRA) to be supportive and consistent.

13. What Can We Improve? (2) • We can improve PIAs by borrowing from more mature risk analysis processes. • We can incorporate the risk analysis processes into the current compliance audit PIA templates, providing a tool to be used as needed. Note: The current form and rigor of existing PIA methodologies do not need to be changed, just augmented.

14. Project Lifecycle Integration • What information do we need when? • Privacy requirements identification with other business requirements • Privacy protection solution identification with other business solutions • Audit/testing of privacy solutions with other business functionality audit/testing

15. Bad Things That Can Happen… • Unknown privacy requirement kills project • E.g. Illegal use of SIN, Illegal disclosure of health card number • Unknown security requirement creates ‘add-on’ expense • Poorly implemented safeguards leave information at risk • Intended safeguard implementation is deferred with unknown risk exposure

16. Project Lifecycle Integration

17. Things to Note • All risk management activities should have a minimum of 3 stages: • Requirements: Identification of risk and safeguard requirements • Solution Evaluation: Verify that the proposed solutions are effective • Implementation: Verify that the solutions are installed and operating as advertised Cost note: Typically, the cost of the first two exercises does not exceed 1.5 times the cost of doing a single large exercise (TRA or PIA). It’s an incremental update.

18. Risk Assessment AlignmentPIAs and TRAs • Can we integrate PIA and TRA risk analysis processes? …save time and money? • Can we do the two analyses in a timely fashion? • Can we ensure that resulting safeguard recommendations do not conflict?

19. Yes, But… • Garbage in – Garbage out • It still takes expertise in the methodology and subject area (security, privacy, …) to do good analysis • Privacy analysis requires expertise of a separate body of knowledge • Security analysts are not automatically good privacy analysts • Team-of-2 approach works well!

20. At a High Level, TRAs & PIAs Have Similarities • Both risk management processes seek to avoid adverse outcomes • Both are communications and decision making tools • Both seek to identify risks and identify safeguard requirements at the analysis phase • Both seek to document “due diligence” analysis and safeguards prior to deployment • Both stem from legislative or policy requirements

21. PIA/TRA Analysis ProcessShared Elements • System descriptions: detailed knowledge of the information flow • Knowledge of effectiveness of safeguards • Concept of “Damages” and “Acceptable Risk” of value to both

22. Not Shared: Privacy Threats (1)More Than Keeping Personal Secrets • Lack of authority to collect • Inadequate consent • Poorly informed data subject • Low quality (incorrect) information • Too much information being held (or held too long)

23. Not Shared: Privacy Threats (2) • Inappropriate use • Data profiling • Data mapping • Transaction monitoring • Identification of individuals • Lack of, or fuzzy accountability • Lack of openness

24. Not Shared: Privacy Threats (3) • Loss of personal control over and access to data, including right to object / challenge the system • Physical observation of individuals • Publishing or re-distribution of databases containing personal information

25. Recap: Why do PIAs and TRAs together? • Timeliness and cost savings • Minimize disruption to business and development teams • Assessments feed critical info to each other • Requirements integrated and in agreement

26. Solution: Risk Assessment Alignment - Detail

27. Solution: Risk Assessment Alignment - Detail

28. The Reports • Separate PIA and TRA for different audiences • Similar layout for easy reading (optional) • Risk scenario based privacy analysis supporting PIA questionnaires (optional) Note: Questionnaire formats are being revisited in some jurisdictions as they have encouraged poor analysis

29. Improving PIAs with Risk Scenario Analysis (1) • Start with the privacy questionnaire… • Postulate system-specific attacks against particular personal information • Consider the initial risks, based on damages caused by disclosure, inaccuracy, etc. • Consider existing privacy safeguards

30. Risk Scenario Analysis (2) • Rate residual risk • Make additional privacy safeguard recommendations (if needed) • Rate residual risk • Organize analysis and safeguards by privacy principles

31. Risk Scenario Analysis (3) • Sample questionnaire question If personal information is to be used or disclosed for a secondary purpose not previously identified, is consent required? Very generic, asks for a Yes/No, does not encourage analysis

32. Risk Scenario Analysis (4)Simplified Analysis Table Item

33. Risk Scenario Analysis (5)Privacy Safeguard Item

34. Recipe Recap: Get the right information at the right time • Lifecycle Alignment and Integration: • Set up your project to get privacy requirements and solutions at the right time • Risk Analysis Process Integration: • Align your privacy and security risk management processes • PIA Analysis Improvement • Formalize and harmonize privacy risk analysis with other risk analysis processes

35. Questions? Thank you for your time.