SecurityRiskAnalysis

Home
who: JohanPeeters

Security is a blind spot in application development. It is typically retrofitted by security professionals tweaking the infrastructure. However, as the network continues to penetrate deeper into homes and professional systems alike, and the voracious appetite for application integration punches more and more holes through traditional, network-based defenses, this approach is faltering. Today's applications must be developed with security in mind.

In so far as agile teams succeed in writing fewer bugs, their software scores better w.r.t. security as there are fewer incidences of unexpected behavior for attackers to exploit. On the other hand, agile processes by themselves will not guarantee security requirements. This session is one of 3 that explores the principles and techniques developed in the security community and investigates whether and how they can be integrated into an agile process. This session focuses on security risk analysis.

Security requirements, architecture and design (15min)

The security requirements, architecture and design from the Security Requirements Engineering and Secure Design and Archticture sessions serve as input for a security risk analysis. They are presented briefly. The organise provides fallback sets of requirements and an architecture in case the former sessions do not take place.

Risk analysis (1h15min)

In a secure development process, risk analysis must be performed continuously. However, risk analysis as presented at this workshop is solely on requirements analysis and design. Code reviews are not addressed. The workshop focuses on the following questions:

  • how will the abuser stories identified during requirements engineering be tested?
  • what are the threats to the technical architecture?
  • how are risks prioritized?
  • how will threats be mitigated?
Threat modeling is based on STRIDE:
  • Spoofing of identity,
  • Tampering with data,
  • Repudiation,
  • Information disclosure,
  • Denial of service,
  • Elevation of privilege.
In developing the mitigation strategy, the architecture needs to be revisited and possibly reviewed.

Evaluation (30min)

In the final part of the workshop, risk analysis practices are reviewed and evaluated.