TDT4237 - Software Security

Modified:
Created:

[TOC]

Intro

These are my notes for TDT4237. These are my own understandings of the subject and it may not be completely correct or accurate. It is also written in slightly below average Norwegian English.

Why do I post them here?

There is a couple of reasons. The first is for convenience. I like to write Markdown as it is very easy to structure text easily and it does not take any focus away from the text, it also has great readability both uncompiled and compiled. It is also very practical to have this available on the web as i like to read my notes on my iPad, and it is faster to access here. The last reason is that someone may find them useful.

Risk managment framework

1. Understand the business context

The software developer must understand the business goals for the application. This is to understand what kind of threats the application can be targeted for.

Some examples of business goals include:

  • Increasing revenue
  • Meeting service level agreements
  • Reducing development costs
  • Generating high return of investment

2. Identify and link business and technical risks

The key to making risk management work is to deeply understand risks. Tying risks to business context in a meaningful way.

It is important to describe technical risks, through business risks and then map them to the business goals.

Business risks

The threat against one ore more business goals. It can have direct financial loss, damage to brand/reputation, vialation of customer or regulatory constraint.

Technical risks

  • Unexpected system crashes
  • Avoidance of controls
  • Unauthorized data modification
  • Needless rework of artifacts during development

3. Synthesize and rank the risks

In any given development process and system there will be a lot of risks. Therfore it is important to give every risk a value so we can prioritize some risks over others.

It is important to answere questions like "Who cares?" and "Where do we start given the current situation?".

Typical risk metrics include:

  • Risk likelihood
  • Risk impact
  • Risk severity
  • Number of risk emerging and mitigated over time

4. Define the risk mitigation strategy

Once we have given the risks a priority we will need to make a plan on how to fix them. This plan should take financial aspects into account and the time it will take to fix an issue. Other important vectors are likelihood of success, completeness and impact over the entire corpus of risks.

The risk mitigation strategy must be constrained by the business context, what the organization can afford, integrate and understand.

It must also clearly identify validation techniques that can be used to demonstrate and verify that the risk has been neutralized.

Typical matrix:

  • Estimated cost takeout
  • Return of investment
  • Method effectiveness
  • Percentage of risk coverage

5. Carry out fixes and validate

Execute the mitigation plan. The problems should be rectified. The risk mitigation should be carried out according to the strategy defined in stage four. To measure this stage, we should use the completeness of the risk mitigation.

Good metrics:

  • Progress against risks
  • Open risks remaining
  • Any artifact quality metrics previously identified.

-> Return to step 2

Measurement and Reporting on Risk

Since the risk management framework is run continouos and in multiple iterations it is important to save data on all the previous risks that have been fixed or not fixed and the once that will be discovered.