Ever tried to build something without having a plan at all? In the most, you fail while struggling with simple decisions and thinking about consequences in the future steps. If you work on a small private project by your own or with your kids, improvise can be fun and wrong decisions will typically not cost you your job or bring you to the jail. The other way around, working chaotically without a focus and structure in your daily job make a bad impression on your person. Even worse in specific roles and positions losing the focus and take a wrong decision can lead to severe sanctions.

Such a role is the one of a security manager. Especially during the process of risk analysis and of a security concept important product assets and mechanisms can be missed which may lead to severe data loss and claims for payment from you customers.

Curiously a structured analysis is exactly the step I've already seen many of my colleagues struggling with. My personal assumption for the reason is mix-up security risk analysis and normal risk analysis. The main and first part of a typical risk analysis in a project context is something like “chaotic thinking”, or brainstorming. This method is very usable to resolve mental bindings to specific topics and think in all directions. Such kind of “open thinking” is also welcome in a security analysis process. The drawback is, in a typical risk assessment workshop the team consist of experts in software, hardware, mechanics, RF, project management, etc. where a filtering is done implicitly during the process, still if it is not desired. In a security risk analysis workshop, the team consists of the same experts but they are typically not experts in security topics, therefore an implicit filtering is not done and the team produces tons of threat scenarios. The problem is, as long as no assumptions, system boundaries, are specified no one knows how far do he needs to think.

The other sort of typical issues are discussion secession about questions like “do we really need to protect this data?”. Typically, no one can really answer because no one in the team knows what kind of important artifacts, called assets, the system is containing.

If the assets are known another problem appears, they must be classified. Typically, the classification is done using a CIA (confidentiality, integrity, availability) scheme, the most common problem here is granularity. In every workshop, I've participated or moderated till now there is at least one guy who tries to create 10 steps (or more) rating system to classify those assets.

Next classification trap, you collected a bunch of threat scenarios, at the end, you have to run a classification round again to figure out which one are the most critical one. To do so there are many techniques known, unfortunately, the general one can not consider real values which your company business case. This leads to the questions like “To rate the following scenario as very likely, an attacker must be able to attack the product using only standard equipment, in our domain a 20k€ oscilloscope is a standard equipment, does it count?”

In the following sections, I will try to untangle the chaos and give some tips how to run more smoothly through the analysis steps, having fun thinking as an attacker and get more out of the process.

Identify your assets first

If you ever been participating a security risk analysis workshop where at the end of the day you was not really satisfied with the result or had the feeling that everyone is discussing again and again about the same topics. The reason was most probably the missing focus.

The main goal of a security analysis is, to find ways how an attacker can manipulate, steal or damage important aspects of the system. If you don't know the important aspects of the system, so-called assets, you just try to answer the following question “how can an attacker manipulate, steal or damage ...” for that there are infinite answers available. The step between these two worlds is very small and easy but is dropped unintentionally because inexperienced but highly motivated teams want to concentrate on problems to solve them as fast as possible.

So how to proceed? If you feel the workshop is drifting in the described direction, make a proposal to summarize the assets together with the other participants, by the way, it is not important whether you are the workshop moderator or a participant do it.

Create a list on a whiteboard, flip chart or use any other documenting tool. Do not filter the proposals by the state, whether they are already secured or not, but you can prefilter by the type of assets, standard assets like MAC address are not really useful in most discussions. Depends on your solution you will end with ~ 5 - 15 assets you want to protect somehow, typically not more. Here is an example.

If your professional domain is software development you can see the step as the generalization. Instead of implementing the same routine in every single class you just create some super classes to inherit from, surely with the option to overload the super class implementation if required.

Raw classification for assets, fine for threats

You have a list of assets, great! The important first step was done, now let's have some general discussions in the team which will show you the direction your workshop will take in the next hours. The assets need a proper security class classification to be able to find the best fit. Why? If you do not have a classification you run into danger to handle all assets the same way and over- or/and under- your final solutions. A well known and used classification scheme is CIA, interesting coincidence by the way, where "C" stands for confidentiality, "I" for integrity and "A" for availability.

In the NIST.SP 800-160 the classes are described as following

• Confidentiality: Rules that govern access to, operations on, and disclosure of system elements (including, but not limited to, data and information). While confidentiality policy typically is considered in terms of information and data, it also applies to restrictions on the knowledge of and the use of system functions and processes;
• Integrity: Rules that govern the modification and destruction system elements (including, but not limited to, data and information) and that govern the manner in which system elements can be manipulated; and
• Availability: Rules that govern the presence, accessibility, readiness, and continuity of service of system elements (to include, but not limited to, data and information).

Thereby confidentiality is full in the scope of security policies, the other both topics have, in the best case, only an overlap. That means integrity and availability of an asset can not always be protected or guaranteed applying security measures.

To classify your data, many authorities and experts (e.g. Carnegie Mellon University, Department of Information Technologie) recommend to use a 3 stages approach with the classes public, private/internal and restricted or use a mapping to the impacts in case of a disclosure like low, moderate, high.

My personal experience shows me that a 2 stage or binary approach is sufficient for many projects. Especially if we talk about small IoT projects where only the device data is in the scope of the analysis. Ok how will the previous list look like if we add a binary classification scheme

Creating such a table is a task of approx. 1h in a workshop together with all involved members. It looks quite common and not really useful but gives the whole team the power for quick go/no-go decision regarding change requests, arguments for specific implementations, the direction to go but also a quick validation of rush job decisions and possible negative effects on the security.

Focus on real threats, define assumptions

Having a list of goals or targets is a great start for an analysis, really, but it should have also an end. Many analysis workshops feel like they will never end because the participants digress more and more deepened in discussion and concepts. A great technique to prevent it is to define assumptions. Assumptions can be seen as security concept boundaries comparable to system boundaries in common product and solution concepts. Below are some common assumptions I've already used in projects:

• Developer team is seen as trustworthy
• Environmental conditions are out of scope for availability considerations
• Vandalism is out of scope for availability considerations
• Power an internet infrastructure is considered as available

Bind real values to your classification scheme

Find a proper classification for the assets is one issue, the other one is to define a classification scheme for the threat scenarios you and your analysis team have found. While for the assets you have to classify very roughly, means just to decide what you want to secure, for the threats a fine-grained approach is needed to be able to estimate likelihood and severity more accurate. Maybe your organization already has a dedicated classification matrix, if not you can take a look on the following two.

• You can derive from the medical domain using their classification (Likelihood and Severity - Medical )
• Use the, very detailed, classification matrix from university of Adelaide (Risk Management Handbook)

Irrelevant where the matrix is coming from, important is how your team can use it efficiently! The best approach I've found until now is to bind real, known values to the classification. The most classification schemes are talking about very generic topics, here are some examples

• Moderate Consequence - One of the consequence: Significant but short term damage to reputation
• Likelihood: High risk = risk to be given appropriate attention & demonstrably managed; reported to Vice-Chancellor or other senior Executives / Management Committees as necessary

What does "Significant but short term damage to reputation" mean? And do your company define exactly for every possible incident when and when not to inform your senior executives? I'm working for a very conservative and highly regulated company and still, there you can not give a definitive answer. Binding well-known values and assets to the classification, in contrast, helps the team to handle them properly. Here are some examples:

• Moderate Consequence - Loss of revenue > 150.000 $
• High Consequence - Loss of one or more customers with a turnover of 1 Mio $
• Extreme Consequence - Loss of human life
• High Likelihood - Attacker needs only standard inexpensive tools (e.g. mobile phone, logic analyzer, screwdriver) to execute an attack a successfully
• Unlikely - Attacker needs access to two unique ID cards which are in ownership of two different users from the senior management team

Use proper templates

Was your team not really touched by the previous issues? You are a lucky guy. The workshop, or a set of, was very productive and the outcome needs to be documented in a proper way. In the most cases, no specific template exists for security analysis documentation or everyone is familiar with the standard template for risk analysis and decide to use it. Unfortunately a bad decision in the most cases, due to the fact that available standard templates for risk analysis don't contain all required elements.

A good template shall contain, at least, the following sections to document your work

• Assets
• Attackers
• Threat Scenarios
• Identified or known Vulnerabilities
• Assumption
• Security Requirements (input to the analysis and output from it)
• Measures
• Proper classification schema for Assets (e.g. CIA)
• Proper classification schema for Threat Scenarios (e.g. Likelihood, Severity) If you are looking for a starting point or a framework, ISO/IEC 27000 gives you an impression which topics shall your analysis and security concept cover.