Confecting Security And Privacy


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Confecting Security And Privacy

  1. 1. Con f ecting Security and Privacy OR How to bake a security TRA with your PIA Marcel Gingras Cinnabar Networks Inc. [email_address] 613.262.0946
  2. 2. The Cook’s Background <ul><li>A major in security with a minor in privacy </li></ul><ul><li>Manager of Risk Analysts </li></ul><ul><ul><li>TRA, PIA, BCP </li></ul></ul><ul><ul><li>Big on methodology development </li></ul></ul><ul><li>IT Security since 1995, Privacy since 2001 </li></ul><ul><li>Public service for 16 years </li></ul><ul><li>IT software developer, software and network architect and network support manager </li></ul>
  3. 3. Recipe <ul><li>Ingredients </li></ul><ul><ul><li>Risk Management and Limiting Disclosure </li></ul></ul><ul><ul><li>PIA and TRA Methodologies </li></ul></ul><ul><li>Preparation </li></ul><ul><ul><li>Sharing the Data Gathering </li></ul></ul><ul><li>Cooking </li></ul><ul><ul><li>Collaborative Analysis </li></ul></ul><ul><li>Testing for Doneness </li></ul><ul><ul><li>Tasty Privacy and Security Safeguards </li></ul></ul>
  4. 4. Conference Theme: Disclosure <ul><li>Privacy Domain </li></ul><ul><ul><li>Principle: Limiting Use, Disclosure , and Retention </li></ul></ul><ul><ul><li>Affects business process design </li></ul></ul><ul><ul><li>May need security “confidentiality” services to limit disclosure (authentication, authorization, confidentiality services_ </li></ul></ul><ul><li>Security </li></ul><ul><ul><li>Protects a business process </li></ul></ul><ul><ul><li>Provides confidentiality, integrity and availability security services </li></ul></ul>
  5. 5. Disclosure Requirements using Risk Management Processes <ul><li>Variety of Risk Management Processes </li></ul><ul><ul><li>Business Strategic Risk </li></ul></ul><ul><ul><li>Business Service Delivery Risk (Operational) </li></ul></ul><ul><ul><li>Financial Risk Management </li></ul></ul><ul><ul><li>Business Continuity Planning (BCP) </li></ul></ul><ul><ul><li>Privacy Impact Analysis (PIA) </li></ul></ul><ul><ul><li>Security Threat and Risk Analysis (TRA) </li></ul></ul><ul><li>Latter two directly analyze disclosure risks </li></ul>
  6. 6. Security Risk Management: A Long History <ul><li>Physical security </li></ul><ul><ul><li>Walls, doors, locks and safes </li></ul></ul><ul><li>Military security </li></ul><ul><ul><li>Protect the country, safeguard the troops </li></ul></ul><ul><ul><li>Codes and ciphers </li></ul></ul><ul><li>IT Security Risk Analysis </li></ul><ul><ul><li>Well developed models and methodologies </li></ul></ul>
  7. 7. IT Security Risk Analysis Process <ul><li>Conceptual analysis of system or application </li></ul><ul><li>Statement of Sensitivity </li></ul><ul><ul><li>Inventory of Assets (includes classification) </li></ul></ul><ul><ul><li>Injury tests </li></ul></ul><ul><li>Threat Assessment </li></ul><ul><li>Vulnerability Assessment </li></ul><ul><li>Examination of Existing Safeguards </li></ul><ul><li>Risk Assessment </li></ul><ul><li>Security Safeguard Recommendations </li></ul>
  8. 8. Privacy Risk Management: A Short History <ul><li>Variable expectations between social groups </li></ul><ul><ul><li>Values within a country, variations depending on context (commercial, banking, health, legal) </li></ul></ul><ul><li>Sense of privacy being under attack </li></ul><ul><ul><li>Fear of government ‘big brother’ </li></ul></ul><ul><ul><li>Fear of erosion of privacy in an IT information age </li></ul></ul><ul><li>Privacy Compliance and Risk Analysis </li></ul><ul><ul><li>New models, limited risk management and ‘young’ supporting methodologies </li></ul></ul>
  9. 9. Current Privacy Compliance and Risk Analysis <ul><li>Slanted towards compliance audit </li></ul><ul><li>Checklist based </li></ul><ul><li>No ranking of potential damages </li></ul><ul><li>No ranking of risk (too many yes/no questions) </li></ul><ul><li>No ranking of safeguard effectiveness </li></ul><ul><li>No action plan </li></ul><ul><li>Unless particular privacy safeguards are specified, it’s all ‘best guess’ </li></ul>
  10. 10. Current Privacy Compliance and Risk Analysis – The Effect <ul><li>Audit against legislation and policy sufficient in some cases, but not helpful in selecting strength of privacy safeguards needed </li></ul><ul><li>Checklist based discourages risk analysis </li></ul><ul><li>Lack of risk rankings makes it difficult to justify appropriately strong solutions </li></ul><ul><li>Lack of a prioritized action plan makes it difficult to plan next steps in the project </li></ul>
  11. 11. Other Annoying Issues <ul><li>Too many TLAs (Three letter acronyms) </li></ul><ul><li>Clutter in the project plan </li></ul><ul><li>Too many interviews asking the same questions </li></ul><ul><li>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. </li></ul><ul><li>Contradictory ‘disclosure’ and ‘confidentiality’ recommendations </li></ul><ul><li>Potential for security solutions to be privacy invasive </li></ul>
  12. 12. What Can We Improve? (1) <ul><li>We can do privacy protection requirements gathering, analysis, and audit at the right time in the project lifecycle process. </li></ul><ul><li>We can align related risk management processes (E.g. PIA and TRA) to be supportive and consistent. </li></ul>
  13. 13. What Can We Improve? (2) <ul><li>We can improve PIAs by borrowing from more mature risk analysis processes. </li></ul><ul><li>We can incorporate the risk analysis processes into the current compliance audit PIA templates, providing a tool to be used as needed. </li></ul><ul><li>Note: The current form and rigor of existing PIA methodologies do not need to be changed, just augmented. </li></ul>
  14. 14. Project Lifecycle Integration <ul><li>What information do we need when? </li></ul><ul><ul><li>Privacy requirements identification with other business requirements </li></ul></ul><ul><ul><li>Privacy protection solution identification with other business solutions </li></ul></ul><ul><ul><li>Audit/testing of privacy solutions with other business functionality audit/testing </li></ul></ul>
  15. 15. Bad Things That Can Happen… <ul><li>Unknown privacy requirement kills project </li></ul><ul><ul><li>E.g. Illegal use of SIN, Illegal disclosure of health card number </li></ul></ul><ul><li>Unknown security requirement creates ‘add-on’ expense </li></ul><ul><li>Poorly implemented safeguards leave information at risk </li></ul><ul><li>Intended safeguard implementation is deferred with unknown risk exposure </li></ul>
  16. 16. Project Lifecycle Integration
  17. 17. Things to Note <ul><li>All risk management activities should have a minimum of 3 stages: </li></ul><ul><ul><li>Requirements: Identification of risk and safeguard requirements </li></ul></ul><ul><ul><li>Solution Evaluation: Verify that the proposed solutions are effective </li></ul></ul><ul><ul><li>Implementation: Verify that the solutions are installed and operating as advertised </li></ul></ul><ul><li>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. </li></ul>
  18. 18. Risk Assessment Alignment PIAs and TRAs <ul><li>Can we integrate PIA and TRA risk analysis processes? …save time and money? </li></ul><ul><li>Can we do the two analyses in a timely fashion? </li></ul><ul><li>Can we ensure that resulting safeguard recommendations do not conflict? </li></ul>
  19. 19. Yes, But… <ul><li>Garbage in – Garbage out </li></ul><ul><ul><li>It still takes expertise in the methodology and subject area (security, privacy, …) to do good analysis </li></ul></ul><ul><ul><li>Privacy analysis requires expertise of a separate body of knowledge </li></ul></ul><ul><ul><li>Security analysts are not automatically good privacy analysts </li></ul></ul><ul><li>Team-of-2 approach works well! </li></ul>
  20. 20. At a High Level, TRAs & PIAs Have Similarities <ul><li>Both risk management processes seek to avoid adverse outcomes </li></ul><ul><li>Both are communications and decision making tools </li></ul><ul><li>Both seek to identify risks and identify safeguard requirements at the analysis phase </li></ul><ul><li>Both seek to document “due diligence” analysis and safeguards prior to deployment </li></ul><ul><li>Both stem from legislative or policy requirements </li></ul>
  21. 21. PIA/TRA Analysis Process Shared Elements <ul><li>System descriptions: detailed knowledge of the information flow </li></ul><ul><li>Knowledge of effectiveness of safeguards </li></ul><ul><li>Concept of “Damages” and “Acceptable Risk” of value to both </li></ul>
  22. 22. Not Shared: Privacy Threats (1) More Than Keeping Personal Secrets <ul><li>Lack of authority to collect </li></ul><ul><li>Inadequate consent </li></ul><ul><li>Poorly informed data subject </li></ul><ul><li>Low quality (incorrect) information </li></ul><ul><li>Too much information being held (or held too long) </li></ul>
  23. 23. Not Shared: Privacy Threats (2) <ul><li>Inappropriate use </li></ul><ul><ul><li>Data profiling </li></ul></ul><ul><ul><li>Data mapping </li></ul></ul><ul><ul><li>Transaction monitoring </li></ul></ul><ul><li>Identification of individuals </li></ul><ul><li>Lack of, or fuzzy accountability </li></ul><ul><li>Lack of openness </li></ul>
  24. 24. Not Shared: Privacy Threats (3) <ul><li>Loss of personal control over and access to data, including right to object / challenge the system </li></ul><ul><li>Physical observation of individuals </li></ul><ul><li>Publishing or re-distribution of databases containing personal information </li></ul>
  25. 25. Recap: Why do PIAs and TRAs together? <ul><li>Timeliness and cost savings </li></ul><ul><li>Minimize disruption to business and development teams </li></ul><ul><li>Assessments feed critical info to each other </li></ul><ul><li>Requirements integrated and in agreement </li></ul>
  26. 26. Solution: Risk Assessment Alignment - Detail
  27. 27. Solution: Risk Assessment Alignment - Detail
  28. 28. The Reports <ul><li>Separate PIA and TRA for different audiences </li></ul><ul><li>Similar layout for easy reading (optional) </li></ul><ul><li>Risk scenario based privacy analysis supporting PIA questionnaires (optional) </li></ul><ul><li>Note: Questionnaire formats are being revisited in some jurisdictions as they have encouraged poor analysis </li></ul>
  29. 29. Improving PIAs with Risk Scenario Analysis (1) <ul><li>Start with the privacy questionnaire… </li></ul><ul><li>Postulate system-specific attacks against particular personal information </li></ul><ul><li>Consider the initial risks, based on damages caused by disclosure, inaccuracy, etc. </li></ul><ul><li>Consider existing privacy safeguards </li></ul>
  30. 30. Risk Scenario Analysis (2) <ul><li>Rate residual risk </li></ul><ul><li>Make additional privacy safeguard recommendations (if needed) </li></ul><ul><li>Rate residual risk </li></ul><ul><li>Organize analysis and safeguards by privacy principles </li></ul>
  31. 31. Risk Scenario Analysis (3) <ul><li>Sample questionnaire question </li></ul><ul><ul><li>If personal information is to be used or disclosed for a secondary purpose not previously identified, is consent required? </li></ul></ul><ul><ul><li>Very generic, asks for a Yes/No, does not encourage analysis </li></ul></ul>
  32. 32. Risk Scenario Analysis (4) Simplified Analysis Table Item Periodic audits by ATIP office P-PSA500 Consent procedures R-PSP252 Consistent notices and forms P-PSP251 Business Liaison with ATIP R-PSP250 Business Manual R-PSP201 L XXX User Agreements R-PSGP112 M-H H M Consent is not obtained in all cases. Persons who make inquiries by telephone or by regular mail may not formally consent to having personal information stored in a repository, or may not understand that their contact information will be retained following satisfaction of their inquiry. Their consent may be viewed as implicit. PR22 R Safeguards (Existing and Recommended) Privacy SG# R L I Risk Scenario R#
  33. 33. Risk Scenario Analysis (5) Privacy Safeguard Item Recom-mended Business Liaison with ATIP : There should be a manager-level business line point of contact or points of contact with the ATIP office to ensure consistency of policy and practices, as well as integration of privacy policy and practices throughout the lifetime of the system. PSP 250
  34. 34. Recipe Recap: Get the right information at the right time <ul><li>Lifecycle Alignment and Integration: </li></ul><ul><ul><li>Set up your project to get privacy requirements and solutions at the right time </li></ul></ul><ul><li>Risk Analysis Process Integration: </li></ul><ul><ul><li>Align your privacy and security risk management processes </li></ul></ul><ul><li>PIA Analysis Improvement </li></ul><ul><ul><li>Formalize and harmonize privacy risk analysis with other risk analysis processes </li></ul></ul>
  35. 35. Questions? Thank you for your time.