01. Principles

Security is a process, not a product

Bruce Schneier

Course

SENG406: brand-new course.

• Developing secure software
• Ensure that people using the software cannot break it (easily)

Assessment items:

Exam will cover mainly content covered in class. Additional resources covered in class are examinable.

Lecture content:

• Principles of software security
• Threat modeling, secure development lifecycle
• Attack tactics
• Common (web) vulnerabilities
• Secure design
• Security protocols, cryptography
• Logging, auditing
• Security testing
• Security evaluation
• Privacy, governance

Weeks 11, 12: time for final assignment.

Labs:

• Week 2/3: threat modeling (tutorial)
• Week 4: Web security tools (Burp, Wireshark)
• Week 5/6: secure design (inc. static analysis)
• Week 7: literature review (tutorial)
  • Can start work on assignment during the tutorial
• Week 8/9: fuzzing (inc. metasploit, sqlmap)
• Week 10: privacy and governance (tutorial)

Software security is different from software engineering in general in that new attacks, threat vectors, and actors are coming out all the time, making it critical that we stay up to date. We must be proactive and ensure we are constantly monitoring the systems.

This course is about:

• Modeling security threats (both software and organizational)
• Evaluating software systems for security issues
• Putting measure in place to:
  • Minimize the risk of security breaches
  • Restore systems after an attack (or after it just crashes)
• Understanding data privacy and governance issues

It is not about:

• Technical knowledge of secure networks
• Advanced cryptography topics
• Hardware-related security devices

Log4j:

• Gave remote access to any server which logged a user-controlled string
• Logs supported template strings
  • Supported JNDI, which downloads and executes remote code
• Root issue: user input was not being sanitized

Group discussion

Scenario:

• Security engineer for Uber Eats
• Three subsystems: end-user, restaurant driver
• All users submit personal details, inc. address, bank details
• Drivers geolocated in real time, can do multiple hops before a delivery
  • Users cannot see hops for other users’ delivery

Vulnerability discovered in GPS library (fix ready, assume similar to log4j):

1. What information do you need to evaluate the impact of the vulnerability?

• How can you get access to that information?

2. What action plan would you put in place?

• How do you communicate the issue with customers/dev team?
• How do you roll out the patch?
  • How do you force users to update (if necessary)?

3. Postmortem

• What did your learn, how will you minimize the risk of a similar incident?
• What is needed for a postmortem? Who should be involved?

Step 1, first response:

• What versions are affected?
  • Vulnerable versions of the app, the library
  • Affected subsystems
    • Trace paths lead to/from the library
• Who was possibly affected?
  • All active users during the time?
  • Some subset of users?
• Do we know if anyone’s data was actually leaked?
  • Has anyone actually exploited the vulnerability?
  • Do the logs contain any traces
• Is the vulnerability public knowledge?
  • If known, copycat attackers will likely appear quickly, including pre-made scripts that exploit the vulnerability, lowering the technical knowledge required by the attacker
• Contact GPS library developers

Step 2, communication:

• Communicate quickly and honestly
• In-app notification, email and texts to every one that may have been affected
• Plus public announcement: press release, Twitter etc.
• Additional communication for those actually impacted
  • For both drivers and users
• From class: response should depend on
  • If vulnerability is publicly known
  • If there is a fix in place

Step 3, postmortem:

• Why was the GPS library being used?
  • Does it follow secure coding practices
  • Did the team validate it before adding it into the app?
• External security audit

Security Engineering

Six goals:

• Authentication: people/data are who/what they claim they are/to be
• Authorization: access control (both physical and digital) to restricted resources (both computing and data)
• Confidentiality: non-public data is not freely accessible, including when in transit
• Integrity: software, hardware and people remain unaltered, unless authorized
• Accountability: trace of past transactions and actions, also for non-repudiation purposes
  • Legal recourse against insider threats
• Availability: resource are available for access, including resistance to attack

Terminology:

• Asset:
  • Anything that needs protection: hardware, software, information, communication
• Policy:
  • How the assets secured
  • Specifies what needs to be protected, including user permissions
• Theory v. practice
  • Exhaustive list of secure and non-secure states, versus practical guidelines
• Attack and agent
  • Deliberate sequence of steps to exploit vulnerabilities, carried by an adversary
• Threat
  • Combination of an agent and vulnerability to corrupt an asset (through an attack vector)
  • If there’s a server that no one is using that an attacker can crash, it doesn’t matter
• Controls and countermeasures
  • Technical, operational and management security mechanisms

Security violations and attacks:

• Security violations: policy-violating actions that put the asset in an insecure state
• Attacks: attack by some threat agent targeting some asset using a vulnerability

Risk assessment:

• Risk assessment is complicated
• Risks are context dependent
• $\text{risk} = \text{threat} \times \text{vulnerability} \times \text{cost}$
• Cost-benefit analysis:
  • Estimated frequencies of occurrence drive security decisions
  • $\text{AnnualLossExpectancy} = \sum_i^n{\text{frequency} * \text{cost}}$