Title: Confecting Security and Privacy
1Confecting 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
2The 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
3Recipe
- 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
4Conference 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
6Security 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
7IT 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
8Privacy 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
9Current 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
10Current 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
11Other 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
12What 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.
13What 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.
14Project 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
15Bad 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
16Project Lifecycle Integration
17Things 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.
18Risk 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?
19Yes, 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!
20At 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
21PIA/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
22Not 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)
23Not Shared Privacy Threats (2)
- Inappropriate use
- Data profiling
- Data mapping
- Transaction monitoring
- Identification of individuals
- Lack of, or fuzzy accountability
- Lack of openness
24Not 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
25Recap 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
26Solution Risk Assessment Alignment - Detail
27Solution Risk Assessment Alignment - Detail
28The 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
29Improving 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
30Risk Scenario Analysis (2)
- Rate residual risk
- Make additional privacy safeguard recommendations
(if needed) - Rate residual risk
- Organize analysis and safeguards by privacy
principles
31Risk 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
32Risk 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
33Risk 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
34Recipe 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
35Questions?