Confecting Security and Privacy

1
Confecting Security and Privacy

• OR
• How to bake a security TRA with your PIA

Marcel Gingras Cinnabar Networks
Inc. mgingras_at_cinnabar.ca 613.262.0946
2
The Cooks 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 ManagementA 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 ManagementA 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, its 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). Its
  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
R Risk Scenario I L R Privacy SG Safeguards (Existing and Recommended) R
PR22 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. M H M-H R-PSGP112 XXX User Agreements L
PR22 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. M H M-H R-PSP201 Business Manual L
PR22 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. M H M-H R-PSP250 Business Liaison with ATIP L
PR22 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. M H M-H P-PSP251 Consistent notices and forms L
PR22 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. M H M-H R-PSP252 Consent procedures L
PR22 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. M H M-H P-PSA500 Periodic audits by ATIP office L
33
Risk Scenario Analysis (5)Privacy Safeguard Item
PSP 250 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. Recom-mended
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.