technical problem, as there is no way to collect
sufficient amount of statistics because of specifics of
current (software development life cycle) SDLC and
software life cycle (SLC) models.
3 A PROPOSED APPROACH
Prior to introduction of the proposed approach for
designing of enterprise IT landscapes to perform
quantitative information security risk assessment
(QISRAP, where P stands for preparation) it is
necessary to provide some relevant mathematical
considerations.
3.1 Mathematical Considerations
As it was pointed out above, because of superfluous
changes, if to consider a given IT landscape from the
mathematic statistical point of view, it is not
possible to assume that the state of landscape is not
changing and thus there will be no way to collect
any reasonable amount of statistics, related to
occurred security incidents. Hence performing an
approximation of a cumulative distribution function
would also be unavailable. The main problem here is
that as it was written above, for a risk to occur there
must be a pair of threat and vulnerability. So, for a
given enterprise without drastic changes in its
organizational structure it is possible to assume that
the distribution of threats is permanent. But if to
consider vulnerabilities this would be an incorrect
assumption as an entity of software is nothing more
then a set of CPU instructions, like hardware is a set
of primitive electronic elements, which have some
given properties (let’s call both of them trivial
components). So vulnerability usually is not a
property of a trivial component itself, but of a fixed
set of such components. And it is quite clear that
though software entities could have the same name
or even version number but different add-ons
installed, they could potentially consist of different
sets of trivial components and only comparison of
hash values can guarantee that these entities are
really equal. Hence unequal software entities could
potentially lead to different vulnerabilities. To
conclude, a replacement of any software or even
hardware component leads to potential changes of its
vulnerability distribution function and hence
changes CDF for security risks. So without some
special preparation there would be several problems
which ravel ISRA:
There are no threat lists;
There are no threat probabilities;
There are no vulnerabilities lists;
There are no vulnerabilities probabilities;
There is no way to collect sufficient
information about vulnerabilities;
And if it is still possible to collect information
about threat distribution using data from different
surveys in other companies from the same industry,
which are often performed by different software
vendors and audit companies, obtainment of
information for vulnerabilities related to all software
components would be impossible because of
superfluous heterogeneity of IT landscapes of
enterprises even within the same industry.
3.2 QISRAP Approach to Prepare for
IS Risk Assessment
In the preceding paper (Romanov, 2009), the authors
introduced a framework for securely building and
managing ERP landscapes (landscapes which
include Enterprise Resource Planning systems as the
main component) where proposed unification of a
set of typical software components and its fixation
till the version number for all of the components as a
way to reduce maintenance cost of a given ERP
landscape and to increase the level of security
confidence, because if a security incident happened
for a single unified worksite, it would happen for all
others under the same external conditions, as all
worksites are equal from the hardware and software
point of view.
Though previously the accent was made to the
way of transference of major security investments
from an enterprise to vendors by establishing a set of
requirements, let’s consider the enhancement of that
approach for any random IT landscape from
information security risk assessment point of view.
If to consider any IT landscape, it would consist of
several types of servers (database, business
application, service application servers, DNS or
DHCP). Any of them could be represented as a set
of abstract layers, see “Figure 3”. Hence it is
possible to state that amount of total technical
vulnerabilities of a given workstation is the sum of
vulnerabilities at each layer. As most of users need
to perform very common set of business functions, it
is possible to fix a suite of all applications needed
for performing business functions and likewise there
are several types of servers. Thus, it is possible to
create a hardware and/or software configuration
profiles for a client worksite, mail server, ERP
server, database server etc. Of course, there could be
some exceptions, but it is better to try to avoid them
AN APPROACH FOR DESIGNING OF ENTERPRISE IT LANDSCAPES TO PERFORM QUANTITAVE
INFORMATION SECURITY RISK ASSESSMENT
315