4

What the real difference between IT Security Assessment based on ISO 27001 (or in general other international standard) and qualitative risk analysis?

In some way the approach is much similar - environment, question towards process owner, gap analysis and final result (where you are and where you should be)

Polynomial
  • 132,208
  • 43
  • 298
  • 379
emc2
  • 43
  • 1
  • 3
  • Yes I agree, my feeling is very close your. Say that, just to go in depth and given that for me Business Impact Analysis (BIA) is a fundamental task to perform risk assessment process what your opinion about same task in Security Assessment process? In other words do you think BIA must be performed during Security Assessment process or not? – emc2 Oct 06 '12 at 17:43

3 Answers3

5

An IT security assessment is a type of risk assessment. Here's the usual process:

  1. Identify the scope of the assessment, and the information assets that are important to the target.
  2. Perform an analysis of the technical security of the target, e.g. via network attacks, physical penetration, etc.
  3. If in scope, perform an analysis of the security policies that the target currently has.
  4. If in scope, perform an analysis of the human security of the target, e.g. via social engineering.
  5. Compile the results of these analyses into a report, using an appropriate risk categorisation framework.

This is by no means exhaustive, and the order of the inner three tasks is arbitrary.

The difference between a generic risk assessment and an IT risk assessment is that the latter isn't something that can really be qualified - it's like asking about the difference between fruit and an apple.

If you're looking at ISO27000 standards specifically, these are just a way to enforce and standardise a particular code of practice and set of analysis tasks, in order to prove that an organisation has performed a security risk assessment to a particular level. They don't change the basic framework of a risk assessment, they just give you a set of minimums that you must perform.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 1
    The last paragraph above concerning ISO27000 is very well said. There are certificates that a firm could obtain, testifying that it passes e.g. ISO27001. But that says 'nothing' about the eventual security risks stemming e.g. from the firm's employing certain proprietary (non-open-source) software of certain producers which are inherently not verifiable by outsiders concerning whether these are free from unintended errors (programmers' faults) or intended malicious manipulations (by capable outsiders and maybe also by disloyal inside workers). In short, IT security risks are omnipresent. – Mok-Kong Shen Oct 06 '12 at 17:24
  • Certs != security. You can attain certification by being secure, but attaining a certification doesn't mean you're secure. For example, there are a few certs out there that require that you check for all patches, do risk assessments on them, identify the security issues related to them, but it doesn't actually require that you patch the damn system. – Polynomial Oct 07 '12 at 00:05
  • 1
    Your formula has IMHO the same significance for IT security as the one short formula well-known in modern physics. On the other hand, I am afraid that most "common" people (who of course never even glance at the ISO documents) are likely to be misled by the said certificates into the wrong belief that any firm possessing them are processing the informations in their possession securely (anyway up to the current standard!). – Mok-Kong Shen Oct 07 '12 at 08:35
3

First, you should know that the ISO27000 family of standards isn't specific about IT. Depending on the scope you define in the beginning, your risk analysis could also cover various activities of your company. Of course, as the focus is on managing the security of your information, there are a lot of recommended controls that are indeed about IT.

That said, the standard says you have to conduct a risk analysis on your assets, but says very little about how you should do it. The methodology is something you're free to define yourself. Most of the time, you won't want to reinvent the wheel and use some known methodology, but the choice is yours. Usually, it's a matter of identifying your assets and their worth to you, then the various threats to these assets and the vulnerabilities that these threats might exploit.

So you can't really compare the risk analysis done in the process of establishing your ISMS (as per ISO27001) with a particular type of risk analysis. If you want, it's a bit like if you ask what's the difference between building a wall and brick masonry.

On thing the standard does say however is that your risk analysis should be reproducible, so that it should give the same results if conducted, for example, by two different persons. In that sense, the more precise your methodology is, the better.

Joubarc
  • 141
  • 4
2

In the scope of IT security, quantitative risk analysis is done by developing a rigorous mathematical model to represent the desired definition of the risk or some aspect of the risk. The security (of a network, for example) is assessed using the developed model.

An example of this approach is risk analysis of enterprise networks using quantitative analysis of attack graphs.

hsnm
  • 1,281
  • 1
  • 10
  • 11