Motto: "Technology follows the same rule of evolution
as any other live form" Freeman Dyson
I was asked many times - and I have
debated it with my colleagues since I’d started my career in (IT Security
Audit) domain! - what is the best tactical approach on IT security audits.
When you are arriving to a client…
(1) you have a checklist in your
pocket – basically, every security standards or guidelines come with set of items
(that has to be checked) in a form of a non-structured list -,
(2) you encounter on the field some
people with some level of IT experience (and some level of communication
skills) and
(3) you are facing an IT
infrastructure - a mixture of hardware and software (which you do not know too
well what it’s supposed to do).
You have three options:
(1) First option – “Paper audit”
(as I call it): You could follow each and every item from your security
checklist (in the exact order), jumping from one person to another (forth and
back) and from one equipment to another, trying to find the best answer. In
this way you think that you will cover the whole scope of the guideline or
standard,
(1.1) But everybody should agree that this is a fallacious argument.
(1.1.1) The terms in which the questions/items are formulated are usually
too general (and sometime people cannot even understand them) and
(1.1.2) the answer to one question/item is composed from many pieces scattered
throughout the entire client’s company.
(1.2) And even if you can go through all the items from checklist you
cannot say,
(1.2.1) that you really addressed all the IT security topics and
(1.2.2) that you (and respectively your client) understood the IT
security challenges faced by the client.
(1.2.3) And more than that, (3) you cannot make real recommendations for
improvement.
(2) Second option – “IT is binary” (as
I call it): You could ask for the IT
architecture documentation (from outlets to applications) and start the
assessment of each component’s security level (from technological point of view).
You have at your disposal a large variety of tools that can help you in this
endeavor. You can use Nessus/OpenVas (for example) or, (if the client really
wants to know if he is vulnerable) Metasploit Framework (another example).
But the downfall of this approach is
that it provides no real usable output. It doesn’t mean that the output is
false or anything, but it’s not knowledge, it’s only information. And this is
because:
(2.1) first: you cannot fully understand the role
played by a single piece of hardware or software (and you cannot pretend that
you did it only by probing it with your fancy tools, even if you have years of experience!).
The hardware and software are combined into (sometimes extremely complicated)
systems; with the systems the company is providing IT services; the IT services
are offered and maintained with the help of processes; the processes are sets
of activities performed by people. You are only looking at the bottom of the pyramid.
And :" you cannot say the taste of fruits/only by staring at
the roots".
(2.2) and second: you can only see
vulnerabilities and not threats. Missing the context and the big picture, will
make you blind to the real client company exposure to IT security risks. Or it
will make you look paranoiac.
(3) And the last option: “Going
after the people” (as I call it): You
could select relevant persons from different departments and discuss with them IT
security topics. If you have enough charisma and you ask the right questions you
may end up closer to the truth, because the people will explain how they are
using the technology. In this way you could discover (eventually) the information
flow and how this information is handled by people (in IT environment) at each
step. (By-the-way: If you are not dealing
with machine learning and/or AI, you should not accept data processing without
a human decision and human responsibility). However, it is not certain that
you will reach your goals. If the IT components cannot tell the full story, it
is also true for people. People can have more knowledge, but they do not have the
whole knowledge.
(4) And this is how we arrive to
the 4th option: “Follow the data” (as I call it): The principle that governs this approach is
the following:
The company (the subject of audit)
is bringing value to his clients thorough the mean of IT services. These IT services
are in fact nothing else then ways to create, store, move data using processes
(a set of predefined activities).
You – as an auditor – have to see the company
not as an old and hierarchical structure (teams, departments, organizations,
etc…), but as a mesh of pipelines through which the data is passing. IT
security means that
(4.1.1) you have to understand the
importance of the fluid (a metaphor of data) and
(4.1.2) you have to check the
integrity of the pipelines.
If you want to conduct a successful
and useful IT security audit, you have to put in the center of your audit - processes (and, respectively, the resources
and the capabilities that make the processes possible). You have to change the
audit scope. In this way you will understand
(4.2.1) the data importance and the
data flow and
(4.2.2) you will act in the spirit
of security standards/regulations/law, not in their dead letter.
So start any IT audit by asking the
responsible persons for the list of processes that are implemented in the
company or try to discover them (if they are not documented already)! When you
will understand all the client processes, you will also understand
(4.3.1) what security questions are
relevant and should receive answers and – equally important –
(4.3.) to whom you should address
the questions.
After that, any of the other approaches
(“Paper audit”, “IT is binary” or “Going for the people”) (or any combination
of them – my warm recommendation!) will provide good results, because now they
will serve the purpose of clarifying the security of the client processes, (client
data and client business).
And in the end this is what the
term “information security” means and this is what matters the most…
Niciun comentariu:
Trimiteți un comentariu