Service Oriented Topological Vulnerability Analysis

idiotcanvasΑσφάλεια

17 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

90 εμφανίσεις

Service Oriented Topological

Vulnerability Analysis

Sergio Valderrama

Universidad de los Andes

Se
-
valde@uniandes.edu.co


Abstract


Each asset seen as an individual component in a
system could let a security analyst see the risks
at which
it is exposed
,

but it would be seen
in
an
isolated
environment
and not as part of a
system. This is what Topological Vulnerability
Analysis propose,
to
view

each asset as part of a
system

to have a more sub
jective view of
potential risks, not only an objective,
vulnerability
-
specific viewpoint.


By nature, security is highly
independent; each
service has its own security issues
.

T
he concern
s

of actual tools and most security methodologies
see it this way, actually, this is the only
“objective” way an automated

tool could face
security
.
This proposal does

not
pretend

to
change this
, it pretend to change the way this
tools and frameworks are us
ed, using objective
tools to create a subjective analysis, oriented to
specific processes and services.


A perfect first approach to this proposal is an
analogy with

the actual IT governance
theory;

A
s
et of logical elements of a system

representing
a spec
ific business function

is what in a business

is called a
“business unit” approach

(actual TVA
proposal)
,
where the system is seen as a
connection of small business

units to reach a
specific goal.

E
volving
to

a

process oriented”

Operational Model
, IT found

a better way to
manage services
, where the goa
l is a specific
function or service
, not

the business unit. This is
where TVA has to evolve, a service perspective,
where the end is a specific ser
vice composed of
several assets, a Service Oriented Topologica
l
Vulnerability Analysis (SOTVA).


Introduct
i
o
n


American English Cambridge dictionary defines
Service

as


a system, organization, or business
that provides for a public need, or the operation
of such a system”, following this definition an IT
service could be understood as a
set

of one or
more
assets that through a process provides a
specific function.


Critics like [4] give a reason to believe that
actual security methods aren’t the best way to
face

actual security problems. Consultancies
and security audits are applied in an objective
way, leaving aside the specific security
requirements of an organizat
ion and just solving
superficial proble
ms without giving a definitive

solution. This can be translated into an
incomplete work, giving only a
guideline of the
actual security state of the system.


To
such problems, solutions like TVA appear
,

giving
a new p
erspective of vulnerability
analysis. If we place ourselves in the actual IT
Governance models, TVA still is a solution
oriented to IT assets, being difficult to frame

it

in IT standards such as COBIT [5] or ITIL [6],
giving just a solution to specific tec
hnical
problems. SOTVA is an extension of the actual
TVA model that defines
a set of parameters to
take into account when making a vulnerability
analysis, not only with the objective of finding
potential risks or
possible
attacking vectors, but
with the po
ssibility to frame this analysis with
the actual governance model of each
organization, and giving a more precise vision of
what to protect (ideally everything, but not in
every case it’s possible to achieve, at least in a
medium term).


SOTVA
promises to
give greater clarity to the
administrators or consultants of the dangers
they are exposed, a better understanding of
their own system and an efficient system of
prevention, flexible and fast in terms of incident
management.

Previous

research


Sushil

Jajodi
a and Steven Noel first propose an
integrated framework for vulnerability
analysis
[1]. From their work, many studies have been
derived as seen in [2] [3] trying to find new
tactics for
IT

risk prevention

oriented not only in
a specific asset, but in the c
orrelation between
them.



If we take a closer look to

some

widely used
methodologies like OCTAVE or OWASP
, they
still
propose to
manage

vulnerability analysis in a
isolated
way, where

their mayor “system
analysis” resides in specific vulnerabilities like
web
-
based SQL Injection where a RDBMS and a
web server is involved, providing a security
consultant a very vague assessment of the real
risk of a system.


The same happened with

securi
ty analysis tools
like Nessus or Qualysis
, they

provide

only
information about a specific asset, and
evaluate

the risk in an objective way
, defined only by the
impact on a
generic

system configuration

in a
generic environment
.


In the other hand IT Governa
nce have been
forced to evolved, methodologies like ITIL
propose a connectivity model between assets,
proce
sses and people, transforming a

“business
unit” governance approach to a “process
based”

governance, where complexity has an
important role.

This is
where SOTVA is framed.


Asset Oriented Vulnerability Analysis Cube
(CAVOA)


Conventional

vulnerability analysis and risk
management methodologies

cannot be leaved
aside; actually they are the only way to expose
asset
-
oriented vulnerabilities.

A way to
repr
esent

vulnerabilities found in a system
,

that
helps de coupling between SOTVA and risk
analysis
,

is to represent each vulnerability in a
way that clarify the possible exploiter (Actor),
the responsible (Vulnerability Type) and the
access level (Attack Leve
l).

Actors would be described in detail
when
talking about perspectives. It refers to the one
who uses the service (or exploit the
vulnerability)

seeing it from a connectivity
perspective
, divided in 3 groups, external actor
(non privileged), Partner (medi
um privileged),
and Internal (full access to the organization).


Also,
vulnerabilities can

be represented in three
ways: “Human Factor” vulnerability, described
as a personal or policies failure, for example a
weak password, unprotected confidential
docume
nts, etc. A Technical Vulnerability refers
to a vulnerability in a specific service, given by a
programming bug or a service definition failure,
like buffer overflows,
ARP Poison Routing, etc.
A
Configuration Vulnerability talks about
vulnerabilities
caused by miss configuration, like
default passwords, default web
-
administration
directories, etc.


The third dimension of the cube represents the
level at which the attack is done; Network level
(level from the TCP/IP Stack) defines attacks
made at Transp
ort Level or above, like VLan
trunking attacks, SYN Floods, etc. At a higher
level Application attacks are defined, referring
to attacks made to a specific application (buffer
overflow, telnet brute force) that could be
exploited without the intervention o
f any other
asset or actor. At last, more complex attacks are
framed in a “Service level attack”, referring to
attacks that need two or more assets to
materialize the attack. In this category attacks
like SQL injection, web brute force, web service
hacking
, etc. can be in this category.



Service identification


It is common to find 2 types of services in IT,
services oriented to extern costumers
(
e.g
. web
services and
web pages
) where any external
actor could interact with the system, and
internal
services (
e.g. data bases and work
stations) where only an internal, authenticated
user could interact with it. Each one of those
services has certain priority when
seeing it from
a “Business
C
ontinuity”
perspective;

it’s not the
same to turn down a work s
tation that turning
down the
Database

server.


The first step of this
analysis is the identification
of critical services
, services from which the
infrastructure is highly dependent, core services
(like web services or transactional services) or
important

support services (like e
-
mail,
informationa
l databases or backup services),
and
categoriz
e

them in one of the two types of
services (internal or external).
The identification
and prioritization of each service in the
organization
is the way to identify th
e security
analysis goal

and a first approach to see the
different attack vectors an attacker would
exploit
.


Based on the

previously collected information,
each service (or the most critical

ones
) should
be, if possible, divided in

the information assets
that
conforms

it. For example, a web service
hypothetically is made up of a web
server

(like
Apache)

with an application server like JBoss
, a
database system (like MySQL), a mail server, a
load balancing appliance, etc. Each of them
interconnected
to make
the service possible.
After the identification of the assets, a
connectivity model should be identified,
but not
only interconnected between
the assets of the
service
, but between each actor on the system
(users, administrators, other applications, etc.),
sketching a connectivity model of the service,
and of each asset with the organization.



In general
, to make
a more robust solution
,

attacking perspectives are used over the assets
that conforms the service, w
here all

points of
view from which the servic
e can be accessed
(and therefore attacked).


Topology



To talk about
(perspectives)
interconnectivity
between IT assets and actors, it is
crucial to
define the topology on which the services are
working, in other words a network analysis in
terms of infr
astructure and connectivity
between assets.
Based on this analysis
,

the
network topology maps (graphs) could be done
with a TVA perspective.


The following examples show a basic network
graph and connectivity graph for the
Web
Service

Example. Figure 1 sho
ws a basic
network configuration for a production
environment divided in 3 segments, Internet,
“Server Segment” and “
Internal Users
Segment”. Figure 2 shows how the services are
interconnected, where C = Client, A = Apache,
M = MySQL, S=SendMail, I = Inter
net and F =
Firewall server

(additional connectivity
information can be given if considered
necessary)
. In this case, the client
-
servers router
is acting as a stateless firewall. It’s also
important to note that each segment,
surrounded by a black rectangl
e, meaning that
all components in the segment are
interconnected between them (this is done to
expose services like windows SMB that are not
explicitly shown in the graph).



Figure
1

-

Network
Graph


Figure
2

-

Connectivity Graph

Visualizing IT assets as a complex system,
where
complex relations happened, complex attacks
could be identified, turning a simple
vulnerability into a critical vulnerability.


Persp
ective
s


The attack perspe
ctives are view points of
different stakeholders over the same service
,
different types of users could use a same
system in different ways. For example, an bank
employee have LAN access to the network and
several access levels over the transactional
proces
ses
,

unlike a common client that only
have access to the webpage and limited
transactional services over Internet

(e.g
.

ATM,
webpage based transactions, etc.)


There are three main groups of users: Internal
Users, conformed by the organization
employees th
at have internal access to the
services or IT assets (DBA, secretaries, etc.); It's
the group with the greater access to the
organization IT services.


Partners
, refers to external actors that have
acce
s
s to one or more non
-
public services (web
services,
transactional appliances, etc.). This
group includes consultants
, private service
consumers
, and

any other type of
actors that
are not part of the organization, but have a
higher access level than a common user.


The last
group is

the external actors, they

are
users that aren’t related with the organization,
and therefore

they only have access to public

Information (public WLAN, web pages, etc.),
being the group with least access to the
organization.

Each of these 3 groups
has

different
perspectives on the services of the organization,
therefore a different attack perspective and
different vector attacks should be considered
for each of the three groups.


Scenarios


Comm
only,
organizations have

more than one
service, or could d
ivide
its structure in one or
more units. To make a more manageable and
comprehensible
model

to
target security issues,
the creation of different scenarios is useful.
Each scenario should aim to have a single
“actor” perspective and a common service.

From
this point of view, the assessment of IT
assets could be validated or recalculated
depending on the attacking vector, taking into
a
ccount the technological risk a

successful
exploitation of a
vulnerability could represent
over the service or the business
.


Returning to the web

service example, the
successful exploitation of
a web server from an
external actor could impact not only the service,
but could put the attacker into a more
advantageous position to overcome other
attacks.


Attacking Vectors



Each
possible risk must

always

be given in a
very specific context for it to
materialize
. A
s
shown in [3], a

number of conditions must be
met before an attacker could successfully
exploit a specific vulnerability.

A triad of factors
must exists in the context

of the attack,
the
intrinsic

existence of a vulnerability, some
degree of interconnectivity between the host
an
d

the actor and
a minimum set of
privileges
for the actor
on

the
service
.

If the
re

is a lack of
one of
those three factor
, even if those are not

adequately conjugated the risk could not be
materialized.


That is how an attack vector is defined, a group
of preconditions that could make a risk real.
After the definition of different scenarios,
the
attacking vectors c
an

be identified. A
vulnerability

analysis over assets can expose
potential risks, which analyzed in a TVAOS
context can expose most of the attacking
vectors that can be used against the service.


Graph generation


The main work of this framework

is the
generation of graphs as a useful wa
y to realize a
SOTVA. With the help of logs, automated
security tools, and every instrument the analyst
could use, are used to translate graphs into
security recommendations and service
architectural changes.


Network

Graphs


Network Graphs specify the net
work topology,
a component oriented schema

where the
physical connections are shown
. Routers,
servers, workstations and any other asset of the
network should be shown. The necessary
information to expose from each asset are their
services, vulnerabilities
and connectivity
(physical connectivity), and any other kind of
information that the analyst consider
important.


--

Gráfica de topología de red U.Andes



Connectivity

graphs


These types of graphs show the connect
ions
between services or assets, specifying the
topology of the service. The purpose of this
graph is to identify the actors of the services
and the
actual logical
connections between
the
services

and assets


As sketching all logical connections may be a b
it
awkward and difficult, this graph should have at
least the “service specific” logical connections,
and as seen in figure 2, a way to represent
other connection types that were not previously
considered

or taken into account for the
service
-
specific conn
ections (Services like SMB,
Terminal service or RPC are not always taken
into account).

The following example could give
a clear view of how this could be applied.


--

Gráfica de conectividad U.Andes



Exploitation graphs


Finally,
the next step is the id
entification of
service scenarios to try to sketch all possible
attack vect
ors on the system
.

Each scenario is
modeled by defining the use cases to recognize
the initial zones where an attack could
materialize (a login page, telnet servi
ce, SQL
injection a
ttack, etc.)
.


This graph should first consider only known
vulnerabilities of specific assets (maybe as
result of an ethical hacking

or an internal audit
)
.


Vulnerability
Assessment


Vulnerability asse
s
sment is a crucial statement
when talking about risk
analysis to position the
organization in a security frame.
Because of this
analysis perspective, giving an impact value to a
specific vulnerability in an objective way cannot
be done. The assessment must be part of a
whole process to try to value the impac
t on
an

asset from different attack vectors, not just the
assessment of a specific vulnerability. For
example, a simple XSS vulnerability may have a
low impact in the organization, but a bad
configured SMTP server in the same network
could make the XSS imp
act high by turning the
server into a possible spam bot.


The asses
s
ment of potential vulnerabilities must
be done tanking in mind the
topological
vulnerability analysis, giving a value depending
on the impact in the service, in the amount of
affected asse
ts and its impact and the difficulty
of exploitation.


Component
s
of the

analysis


SOTVA must be a proactive
tool, fed by all
security components available such as IDSs,
security logs, system logs, network analysis
tools, automated security tools, etc.
[1]

gives a
better approach of how to use these tools in a
production environment. Using those tools, and
up to date graphs, further attack vectors may
be considered, having an updated model and
therefore a better security perspective of
potential
threat.


After the first design of a SOTVA, new
information could be identified, and answers to
a sort of intriguing question.

An extensive
SOTVA analysis can identify which IT assets are
exposed to a greater risk or which assets or
appliances have the greatest imp
act on the
organization, letting the administrators to
identify what possible new vulnerabilities could
cause the most damage to a specific service or
the entire organization.


In a “hardening” perspective, this analysis help
to identify what network or se
rvice architecture
changes should be implemented to prevent
the
coupling between unsafe assets and how to
mitigate unidentified vulnerabilities based on
service and network architectures. Through this
analysis a new starting point of the hardening
process
could be written.


SO
TVA
and IT
Governance


One of the pillars of this methodology is its
coupling with common “service oriented” IT
governance models like ITIL and COBIT. The
analysis makes an important contribution in the
definition of a security model a
nd its security
policies and gives a new variable to consider in
the “delivery and support” domain defined in
the governance life cycle [5
-
COBIT
], Service
Level Agreements and Service Level
Requirements, where security considerations
becomes an obligation.


A new perspective of the BCP

[6
-
ITIL] could be
formalized, especially in generating new
strategies and prevention plans.

This
methodology is planned to be used in on
-
going
operations [6] without disturbing actual IT
processes based only on analysis for f
urther
implementation of possible strategies defined
in the SOTVA process. By giving a security
planning environment, there is a clear view of
risk assessment and mitigation and resource
planning.


Change
management now could be understood
in a security co
ntext redefining SLA and SLR of
an organization. The application of the analysis
gives another viewpoint to the service design
(Plan & Organize), providing a better continual
service improvement in a security and
availability perspective.


Conclusion


Like

TVA models, SOTVA propose a change in
vulnerability analysis, now, a service oriented,
coupled to IT governance. This approach
highlights the importance of security policies
and documentation to actual vulnerability
analysts, giving a stretch relation bet
ween
specific vulnerabilities and enterprise security
processes.


Having as a frame of reference specific
organization services,
a “process oriented”
security model could be define to give a
beginning to the security process, a proactive
security model eas
ily expandable to cover all (or
at least most) IT processes in the organization.