09. Data Privacy and Sovereignty

Current Events: GitLab RCE

Any user with a login could remotely execute code through the GitHub import feature.

Patched in 15.3.1/15.2.3/15.1.5

Communication:

None until patch was released
Workarounds released in case organizations do not/cannot upgrade
No individual communication with organizations
UC did not know about the issue

Current Events: Optus Hack

2nd largest telecommunications company in Australia. 5 million drivers’ license/passports stolen.

Broken access control: faulty API which allowed the attacker to dump a large amount of data.

Initially released 10K entries as proof and requested million dollar ransom; apparently changed their mind and deleted the data.

Data Privacy

NZ Data Privacy Act 2020:

Defines 13 principles - guidelines, not rules
Principles 1, 2, 4: collection of data
Principle 3: privacy statements
Principles 5, 9: data storage security and duration
Principles 6, 7, 8: how data can be verified/amended
Principles 10, 11, 12: usage of data in/outside NZ
Principle 13: ID numbers and how and how to not use them

NZ Google Street View Wi-Fi collection (2010):

Network information (SSID, name, signal strength)
Payload information from unsecured networks
- No reason for collecting the data and was never used for anything

EU GDPR:

General Data Protection Regulation
Applies to organizations offering goods/services to the EU
99 articles in 11 chapters
Processors must give full information
Right to erasure (to be forgotten)
Right to object to processing of data
More explicit rights to lodge complaints
Transfer of data outside territory is institutional
Strong data sovereignty - requires mutual agreement
Explicit articles on liability and penalties

digital.govt.nz on GDPR:

While the GDPR imposes additional obligations on agencies, and provides additional privacy rights to EU residents, an agency is likely to comply with most of its obligations under the GDPR if it complies with the Privacy Act.

No…

Web Usability Standard 1.3

Web usability and privacy standard for NZ public service websites
Must be accessible: readable by a screen reader and be printable
Must identify as being affiliated to a government organization
Link to the main govt.nz website
Include contact information
Have a copyright and privacy statement
- Cookie usage
- Collation/usage of personal data
- Rights to access/amend/delete information

ISO 27000:

Closed standards - costs money to read them
27002 information security:
- Human resource and asset management
- Access control, inc. devices and procedures
27004 monitoring:
- What to monitor end measure
- Define, maintain, evaluate monitoring process
Domain-specific series:
- 27033 (7 parts) network security
- 27034 (7 parts) application security
- 27035 (4 parts) incident management

NZ Information Security Manual:

Mostly focused on government-led services/agencies
Practitioner’s manual covering:
- Governance: management, roles
- Security of personnel and facilities
- Monitoring and incident response
- Logging/forensics
- Cryptography requirements
Uses multi-level security (top-secret -> unclassified)

OWASP Secure Code Review Guide V2:

Vulnerability areas:
- Data Validation
- Authentication
- Session Management
- Authorization
- Cryptography
- Error Handling
- Logging
- Security Configuration
- Network Architecture
Source code scanners:
- Useful for identifying particular flaws, but cannot deal with flaws related to business logic
- Has a high false positive error and hence requires manual review
STRIDE:
- Spoofing another user’s identity or permissions
- Tampering: with HTTP requests made by clients
- Repudiation: matching activity to a user
- Information disclosure: private information breached
- Denial of service
- Elevation of privilege
DREAD:
- Damage: consequences of success
- Reproducibility: ease of attack; automation
- Exploitability: resources (and initial access required) for the attack
- Affected users: number of affected users, permission levels
- Discoverability: ease of attackers in finding the vulnerability
Mitigation:
- Not mitigated
- Partially mitigated: DREAD reduced
- Fully mitigated
Cyclomatic complexity: fixing high CC code has a greater chance of introducing new errors
Top 10 (2017):
1. Injection
- Bind SQL: boolean (valid/invalid query) or timing
1. Broken auth/session management
- Limit brute force
- Protect forgot password
- Require HTTPS
- Out of band comms (e.g. 2FA)
- Session hijacking:
  - Use HTTP-only cookies; no JS access
  - Don’t send IDs in URLs
  - Change session ID on elevation (e.g. log in)
  - As well as periodically (or enforce periodic logouts)
1. XSS
- Escape user input when rendering a page
1. Insecure direct object reference
- Verifying that user has access to view/edit some object (e.g. ID for a different account)
- Data binding: attacker passes in additional parameters that the endpoint is not expecting but is automatically bound
1. Security misconfiguration:
- URL rewriting: double URI encode; bypass initial security control layer, but next layer also runs decoding without security checks
1. Sensitive data exposure
- Proper encryption at rest and in transit
- Use of standardized/validated implementations
- Avoid wildcard certificates
- Reusing salts, IV, insecure entropy source
- Secure key storage
1. Missing function-level access control
- Response checks auth, but request already executed
1. CSRF
- User on malicious site executes request to target site
1. Components with known vulnerabilities
2. Unvalidated redirects/forwards

OWASP Secure Coding Practices Quick Reference Guide V2:

Potential targets:
- Software/associated information
- OSes of the servers
- Backend DB
- Other applications (if running in a shared environment)
- User systems
- Other software the user interacts with
Checklist:
- Input validation:
  - Backend validation (trusted system)
  - Partition data as trusted/untrusted
  - Have a centralized input validation routine
  - Specify character set, canonicalize strings
  - Reject on validation failure
  - Validate all data: URL parameters, HTTP headers, cookies etc.
    - Ensure only ASCII
  - Validate redirects (attacker sends request to redirect target)
  - Validate data range, length, type
  - Use allowlists of characters where possible
- Output:
  - Encode on trusted system
  - Use standard, validated routine for encoding
  - Sanitize untrusted data
- Authentication:
  - Specifically mark publicly accessible pages rather than the other way round
  - Use well-tested authentication services/libraries
  - Centralize authentication code/services
  - Separate authentication logic from business logic
  - Authentication controls should fail securely
  - Validate authentication data only when all inputs received
  - Return minimal information about authentication failures
  - Store secrets securely (not in source code)
- Error handling
  - Do not log session identifiers, account information etc.
  - The application, not the server, should handle application errors
  - Log both successes and failures
  - Log4j
  - Use a unified logging system
  - Log all:
    - Input validation failures
    - Authentication attempts
    - Access control failures
    - Tampering attempts
    - Requests using invalid/expired session tokens
    - System exceptions
    - All admin functions
    - TLS failures
    - Crypto failures
    - Use a HMAC to validate log integrity
  - Data protection
    - Least privilege
    - Purge sensitive data from caches after they are no longer required
    - Remove unnecessary information about system details from documentation and comments in user-accessible code
    - Do not include sensitive information in GET requests
    - Disable client-side caching when required
    - Implement access control for data stored on servers (e.g. cache directory only accessible by specific users)
  - Misc
    - Disable unnecessary library/framework/system functionality
    - File uploads: check headers/magic bytes, not just the extension
    - Never send absolute paths to clients
    - Make application files read-only where possible
    - Raise/drop privileges as late/soon as possible

Secure Code Review Best Practices:

Understand the developer’s approaches to security
Use multiple automated tools
Do not access level of risk: let the development team do this
Focus on the big picture, not individual lines of code
Pick a small subset of weaknesses to manually investigate
Follow up with development team
Secure code review != pen testing

Penetration testing on live systems:

May cause crashes or heavy load, impacting legitimate users
Bug bounties: running on sandboxed systems and has a legal framework
Disclosure: what happens if the company does not fix it?

Māori Data Sovereignty:

Te Mana Raraunga network:
- Founded in 2016
- Individuality vs collective ownership
- All data collected from Māori should belong to Māori
- Data should be analyzed in context with help from Māori
- Six principles:
  - Rangatiratanga: authority and self-determination
  - Whakapapa: data in their relationships
  - Whanaungatanga: obligations and accountability
  - Kotahitanga: collective benefit and capacity
    - Not just for a private benefit
  - Manaakitanga: reciprocity, respect and consent
    - Ask for consent
  - Kaitiakitanga: guardianship and ownership
    - Build knowledge within the Māori community

Patriot Act (9/11), CLOUD Act (2018):

Government can request access to any and all data held in US servers or US-led companies
Lots of companies based in Ireland (for tax purposes): government wanted access and was not allowed by the courts
- The fix? Write a new law to allow it

China National Intelligence Law:

Applies to all Chinese-led companies or those registered in China
Allows all means necessary to carry out intelligence work

Local legal agreements can prevent data transfer:

Auditing of data sometimes requires formal approval (e.g. unions in France)
GDPR picky on data storage location (mutual exchange agreement)
GDPR and CLOUD can conflict
- US requests must comply with GDPR

VPNs vs Tor:

Tor:
- Access to Tor via rendezvous points
- Data goes through intermediaries: proxies
- Data encrypted multiple times (3 should be enough)
- Only the entry node knows your IP address
- Tor exit nodes may be known
- Tor provides anonymity
VPNs:
- VPNs provide privacy
- Data sent to server to mask your IP
- Server must be trusted: it knows your identity and the sites being visited
- VPN servers may be known