• Home   
• Blog   
• About   

A System Security Assessment

Bjørn-Ivar Bekkevold - January 2023 (533 Words, 3 Minutes)

Brief

How to approach evaluating systems, identifying threats, security risks, and ways to mitigate or remediate them. The process I lay out is my opinion where I try to compile the different steps in a way that I like to think about it, and reflects how I have experienced it in a professional setting so far.

Problem

A system or product, continously in development will most likely at certain points in time have weaknesses or vulnerabilities residing in them. These or some of these may be identified internally or externally by someone, to later be notified and addressed in some way.

When the question of treatment, mitigation, or whatever we should do arrives at the table of decision makers, architects or designers, they might say “Should we fix this?”, “How bad is it?”, “How much time should we spend on investigating this?”, “What other weaknesses do we have, that we currently are not aware of?”, “Are they more or less critical than this one?”.

And the answer is, we dont know, and most likely we will not find out. Because the architects on this matter lack the necessary data to make good informed decisions regarding the system or product, put in a security context. And this may be a symptom of lacking security focus in the development process, missing stakeholders or dedicated roles within a project to address and manage security incident matters.

Introduction

Given a system, either in-development or deployed in the field, an approach to securing it is by performing a System Security Assessment (SSA). This often goes by different names such as Security Risk Analysis, Threat Assessment, Risk Management or Threat Modeling.

The purpose of performing an SSA, is to provide initial coverage for the scope that you set; we identify threats against the system and its assets, with the consequences they may lead to. We then search for vulnerabilities or system weaknesses that may aid such threats in potential attacks.

Such an assessment is a top down approach to securing systems, and what this provides us with is concrete actionables, serving as a decision basis for technical teams, projects or organizations in where to best allocate resources in mitigating unwanted or unacceptable risks to a system or product.

In short: The objective is to set a scope, identify threat to the system and weaknesseses that may enable them within said scope. Taking this as input, the output from an SSA produces risks that you may act upon to further mitigate. What can happen? How can it happen? Where do I put my effort?

Process

The process is meant to be and should be iterative. The quality of the output mirrors the quality of the input, and whatever data that is fed in the assessment will always be a snapshot of the situation at exactly that current point in time. Meaning it is better to reduce the granularity and level of detail of an assessment to ensure that the assessment will be perfomed again. Multiple shallow assessments is preferred over one large painful iteration, especially at the beginning.

The assessor is not meant to have the full knowledge of the system being evaluated. The assessor must facilitate and ensure that subject matter experts are included in most if not all phases of the process. The assessor should interview the relevant technical teams, architects and developers and encourage discussion and brainstorming. Ideally the technical teams and SMB’s should know enough of the process to intuitively think through the steps themselves, where the asessor should simply collect and compile the information. Such an activity should produce risks that technical teams may work with, but allowing the teams to take part of the process allows them to better internalize the mindset, which may uncover further findings not identified in the assessment initially. The following are 5 phases of the process:

1. Scope - Set the scope of the assessment.
2. Valuation- Identify the assets of the system.
3. Threats - Identify relevant threats to the system.
4. Attacks - Identify possible attacks to the system.
5. Risk Management - Produce risks for each scenario. Address the identified risks and implement mitigations if needed. Assess the risk-profile again after treatment, do we accept and take ownership of the residual risk for the system?