G
G
Gudsaf2018-05-01 14:16:11
Information Security
Gudsaf, 2018-05-01 14:16:11

How to properly identify and assess architectural risks?

There is one simple task: to exchange data.
You can solve this problem in three ways:

  1. through a website where this data can be posted;
  2. through a site where you can place these markers and subscribe to these data that they are mine;
  3. through the blockchain, where we automatically sign that this data is mine.

Each of these solutions, without choosing means of protection, without understanding what application software is used, has risks that do not depend at all on what OS you have on the user's computer or on the server, what DBMS is installed - that is, those risks that are not tied to the method of implementing this architecture, and those risks that are dictated by the architecture of the solution itself.
Let's call these risks architectural for simplicity . So, for each method, for each architecture of the solution, these risks can be assessed and, subsequently, the total risk of using a generally similar solution as a whole: its architecture.
Here is an example of a similar problem , but more simply: I want to compare the risks of using two types of bicycles, a tricycle and a two-wheeler. Bicycle architectures are different, but they solve one problem - to transport me from point A to point B. Accordingly, there are also risks that do not depend at all on what kind of rubber I have on my bike, but depend, for example, on the fact that in the first architecture you have three wheels, and in the second two.
Then we can immediately identify the risk common to these two decisions: the risk of falling off the bike.
In the case of the first architecture, where there are 3 wheels, the risk will be less, for example 0.1.
In the case of the second architecture, where there are 2 wheels, the risk will be greater, for example 0.9.

Accordingly, it is possible to somehow highlight the general architectural risks for these solutions and compare them within these risks. If we return from bicycles to data exchange systems, then I do not want to consider the details of the system:
  1. then what kind of subd I have on the server, what vulnerabilities it has;
  2. what OS the user has, what vulnerabilities it has;
  3. the fact that the BIOS firmware can be faked by the Chinese and then the data in the database is a disaster;
  4. and other little things.

And consider the risks of architecture:
  • architecturally, the first solution has the risk that we will not prove that the data belongs to you, and in the second and third solutions this risk is small - it is solved by architecture thanks to the blockchain or the involvement of the digital signature;
  • the first and second solutions have the risk that the data will be spoofed by an attacker, their architecture allows this, but the blockchain does not;
  • etc.

How to correctly identify and evaluate such architectural risks ? Is there any method, examples ?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
A
Alex, 2018-09-30
@asilonos

There is a common technique in information security, it is called Risk Management. What you want to do can also be calculated using the techniques of this technique. Let's say it will be Risk management at the stage of designing TK to some inf. systemme.
Have a look at:
Risk Management Framework NIST SP800-37
Quantitative vs Qualitative Risk Assessments
Development of Threat Analysis i.e. based on known threats, for example, if it is data transmission over an open channel, then the maximum threat is the interception and analysis of traffic for XX time.
Asset Classification - The architect, of course, is not entirely aware of the significance / cost of the data with which his IS will operate. but he is aware, for example, if this is the Encryption Key (this is an asset), then this is resource No. 1 that needs to be protected. it means you need to spend more time on the development of technical specifications for its protection in memory, storage and transfer.
For example, the MTD metric can be taken as - how long is your IP capable of functioning in case of loss of the communication channel \ with the server \ database failure? When an Encryption Key is compromised, how much time do you have before it can be used?
ARO - these can be average values ​​for the latest Hacks / Penetrations, which show the frequency of exploitation of certain types of vulnerabilities. Let's say if you are going to use the OpenSSL library, then in its entire history many different types of severity of vulnerabilities have been found in it -
https://www.openssl.org/news/vulnerabilities.html
is about 2 per year (severe on average). You can safely put this parameter in your formula in the TOR :)
ALE = SLE X ARO
This is the damage that the natural appearance of vulnerabilities in OpenSSL = SLE * 0.5 will cause to your IP
Next SLE - what should be done to close the gap? (one-time cost to get out of a specific vulnerable IS situation when your IS is in operation) - Update OpenSSL . Is the installed copy of your IP ready to survive the major OpenSSL update?? As an architect, rate this willingness from 0 to 10 on potential issues/costs/dependencies in your encryption protocols.
Accordingly, if your "architectural" SLE is closer to 10, then ALE will be large and you can already at the Design stage predict the costs of operating your system in conditions when OpenSSL needs to be updated twice a year.
And so on..
And yes, you think correctly that the Risk should somehow be calculated in the form of numbers.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question