Σχόλια 0

Το κείμενο του εγγράφου

Each asset seen as an individual component in asystem could let a security analyst see the risksat whichit is exposed,

but it would be seeninanisolatedenvironmentand not as part of asystem. This is what Topological VulnerabilityAnalysis propose,toview

each asset as part of asystem

to have a more subjective view ofpotential risks, not only an objective,vulnerability-specific viewpoint.

By nature, security is highlyindependent; eachservice has its own security issues.

The concerns

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

tool could facesecurity.This proposal does

notpretend

tochange this, it pretend to change the way thistools and frameworks are used, using objectivetools to create a subjective analysis, oriented tospecific processes and services.

A perfect first approach to this proposal is ananalogy with

the actual IT governancetheory;

Aset of logical elements of a system

representinga specific business function

is what in a business

is called a“business unit” approach

(actual TVAproposal),where the system is seen as aconnection of small business

units to reach aspecific goal.

Evolvingto

a“process oriented”

Operational Model, IT found

a better way tomanage services, where the goal is a specificfunction or service, not

the business unit. This iswhere TVA has to evolve, a service perspective,where the end is a specific service composed ofseveral assets, a Service Oriented TopologicalVulnerability Analysis (SOTVA).

Introduction

American English Cambridge dictionary definesService

as

“a system, organization, or businessthat provides for a public need, or the operationof such a system”, following this definition an ITservice could be understood as aset

of one ormoreassets that through a process provides aspecific function.

Critics like [4] give a reason to believe thatactual security methods aren’t the best way toface

actual security problems. Consultanciesand security audits are applied in an objectiveway, leaving aside the specific securityrequirements of an organization and just solvingsuperficial problems without giving a definitive

solution. This can be translated into anincomplete work, giving only aguideline of theactual security state of the system.

Tosuch problems, solutions like TVA appear,

givinga new perspective of vulnerabilityanalysis. If we place ourselves in the actual ITGovernance models, TVA still is a solutionoriented to IT assets, being difficult to frame

it

in IT standards such as COBIT [5] or ITIL [6],giving just a solution to specific technicalproblems. SOTVA is an extension of the actualTVA model that definesa set of parameters totake into account when making a vulnerabilityanalysis, not only with the objective of findingpotential risks orpossibleattacking vectors, butwith the possibility to frame this analysis withthe actual governance model of eachorganization, and giving a more precise vision ofwhat to protect (ideally everything, but not inevery case it’s possible to achieve, at least in amedium term).

SOTVApromises togive greater clarity to theadministrators or consultants of the dangersthey are exposed, a better understanding oftheir own system and an efficient system ofprevention, flexible and fast in terms of incidentmanagement.

Previous

research

Sushil

Jajodia and Steven Noel first propose anintegrated framework for vulnerabilityanalysis[1]. From their work, many studies have beenderived as seen in [2] [3] trying to find newtactics forIT

risk prevention

oriented not only ina specific asset, but in the correlation betweenthem.

their mayor “systemanalysis” resides in specific vulnerabilities likeweb-based SQL Injection where a RDBMS and aweb server is involved, providing a securityconsultant a very vague assessment of the realrisk of a system.

The same happened with

security analysis toolslike Nessus or Qualysis, they

provide

onlyinformation about a specific asset, andevaluate

the risk in an objective way, defined only by theimpact on ageneric

system configuration

in ageneric environment.

In the other hand IT Governance have beenforced to evolved, methodologies like ITILpropose a connectivity model between assets,processes and people, transforming a

“businessunit” governance approach to a “processbased”

governance, where complexity has animportant role.

This iswhere SOTVA is framed.

Asset Oriented Vulnerability Analysis Cube(CAVOA)

Conventional

vulnerability analysis and riskmanagement methodologies

cannot be leavedaside; actually they are the only way to exposeasset-oriented vulnerabilities.

A way torepresent

vulnerabilities found in a system,

thathelps de coupling between SOTVA and riskanalysis,

is to represent each vulnerability in away that clarify the possible exploiter (Actor),the responsible (Vulnerability Type) and theaccess level (Attack Level).

Actors would be described in detailwhentalking about perspectives. It refers to the onewho uses the service (or exploit thevulnerability)

The third dimension of the cube represents thelevel at which the attack is done; Network level(level from the TCP/IP Stack) defines attacksmade at Transport Level or above, like VLantrunking attacks, SYN Floods, etc. At a higherlevel Application attacks are defined, referringto attacks made to a specific application (bufferoverflow, telnet brute force) that could beexploited without the intervention of any otherasset or actor. At last, more complex attacks areframed in a “Service level attack”, referring toattacks that need two or more assets tomaterialize the attack. In this category attackslike SQL injection, web brute force, web servicehacking, 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. webservices andweb pages) where any externalactor could interact with the system, andinternalservices (e.g. data bases and workstations) where only an internal, authenticateduser could interact with it. Each one of thoseservices has certain priority whenseeing it froma “BusinessContinuity”perspective;

it’s not thesame to turn down a work station that turningdown theDatabase

server.

The first step of thisanalysis is the identificationof critical services, services from which theinfrastructure is highly dependent, core services(like web services or transactional services) orimportant

them in one of the two types ofservices (internal or external).The identificationand prioritization of each service in theorganizationis the way to identify the securityanalysis goal

and a first approach to see thedifferent attack vectors an attacker wouldexploit.

Based on the

previously collected information,each service (or the most critical

ones) shouldbe, if possible, divided in

the information assetsthatconforms

it. For example, a web servicehypothetically is made up of a webserver

(likeApache)

with an application server like JBoss, adatabase system (like MySQL), a mail server, aload balancing appliance, etc. Each of theminterconnectedto makethe service possible.After the identification of the assets, aconnectivity model should be identified,but notonly interconnected betweenthe assets of theservice, 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 makea more robust solution,

attacking perspectives are used over the assetsthat conforms the service, where all

points ofview from which the service can be accessed(and therefore attacked).

Topology

To talk about(perspectives)interconnectivitybetween IT assets and actors, it iscrucial todefine the topology on which the services areworking, in other words a network analysis interms of infrastructure and connectivitybetween assets.Based on this analysis,

thenetwork topology maps (graphs) could be donewith a TVA perspective.

The following examples show a basic networkgraph and connectivity graph for theWebService

(additional connectivityinformation can be given if considerednecessary). In this case, the client-servers routeris acting as a stateless firewall. It’s alsoimportant to note that each segment,surrounded by a black rectangle, meaning thatall components in the segment areinterconnected between them (this is done toexpose services like windows SMB that are notexplicitly shown in the graph).

Figure1

-

NetworkGraph

Figure2

-

Connectivity Graph

Visualizing IT assets as a complex system,wherecomplex relations happened, complex attackscould be identified, turning a simplevulnerability into a critical vulnerability.

Perspectives

The attack perspectives are view points ofdifferent stakeholders over the same service,different types of users could use a samesystem in different ways. For example, an bankemployee have LAN access to the network andseveral access levels over the transactionalprocesses,

unlike a common client that onlyhave access to the webpage and limitedtransactional services over Internet

(e.g.

ATM,webpage based transactions, etc.)

There are three main groups of users: InternalUsers, conformed by the organizationemployees that have internal access to theservices or IT assets (DBA, secretaries, etc.); It'sthe group with the greater access to theorganization IT services.

Partners, refers to external actors that haveaccess to one or more non-public services (webservices,transactional appliances, etc.). Thisgroup includes consultants, private serviceconsumers, and

any other type ofactors thatare not part of the organization, but have ahigher access level than a common user.

The lastgroup is

the external actors, they

areusers 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 theorganization.

Each of these 3 groupshas

differentperspectives on the services of the organization,therefore a different attack perspective anddifferent vector attacks should be consideredfor each of the three groups.

Scenarios

Commonly,organizations have

more than oneservice, or could divideits structure in one ormore units. To make a more manageable andcomprehensiblemodel

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

Fromthis point of view, the assessment of ITassets could be validated or recalculateddepending on the attacking vector, taking intoaccount the technological risk a

successfulexploitation of avulnerability could representover the service or the business.

Returning to the web

service example, thesuccessful exploitation ofa web server from anexternal actor could impact not only the service,but could put the attacker into a moreadvantageous position to overcome otherattacks.

Attacking Vectors

Eachpossible risk must

always

be given in avery specific context for it tomaterialize. Asshown in [3], a

number of conditions must bemet before an attacker could successfullyexploit a specific vulnerability.

A triad of factorsmust exists in the context

of the attack,theintrinsic

existence of a vulnerability, somedegree of interconnectivity between the hostand

the actor anda minimum set ofprivilegesfor the actoron

theservice.

If there

is a lack ofone ofthose three factor, even if those are not

adequately conjugated the risk could not bematerialized.

That is how an attack vector is defined, a groupof preconditions that could make a risk real.After the definition of different scenarios,theattacking vectors can

be identified. Avulnerability

analysis over assets can exposepotential risks, which analyzed in a TVAOScontext can expose most of the attackingvectors that can be used against the service.

Graph generation

The main work of this framework

is thegeneration of graphs as a useful way to realize aSOTVA. With the help of logs, automatedsecurity tools, and every instrument the analystcould use, are used to translate graphs intosecurity recommendations and servicearchitectural changes.

where thephysical connections are shown. Routers,servers, workstations and any other asset of thenetwork should be shown. The necessaryinformation to expose from each asset are theirservices, vulnerabilitiesand connectivity(physical connectivity), and any other kind ofinformation that the analyst considerimportant.

--

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

Connectivity

graphs

These types of graphs show the connectionsbetween services or assets, specifying thetopology of the service. The purpose of thisgraph is to identify the actors of the servicesand theactual logicalconnections betweentheservices

and assets

As sketching all logical connections may be a bitawkward and difficult, this graph should have atleast the “service specific” logical connections,and as seen in figure 2, a way to representother connection types that were not previouslyconsidered

or taken into account for theservice-specific connections (Services like SMB,Terminal service or RPC are not always takeninto account).

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

--

Gráfica de conectividad U.Andes–

Exploitation graphs

Finally,the next step is the identification ofservice scenarios to try to sketch all possibleattack vectors on the system.

This graph should first consider only knownvulnerabilities of specific assets (maybe asresult of an ethical hacking

or an internal audit).

VulnerabilityAssessment

Vulnerability assessment is a crucial statementwhen talking about riskanalysis to position theorganization in a security frame.Because of thisanalysis perspective, giving an impact value to aspecific vulnerability in an objective way cannotbe done. The assessment must be part of awhole process to try to value the impact onan

asset from different attack vectors, not just theassessment of a specific vulnerability. Forexample, a simple XSS vulnerability may have alow impact in the organization, but a badconfigured SMTP server in the same networkcould make the XSS impact high by turning theserver into a possible spam bot.

The assessment of potential vulnerabilities mustbe done tanking in mind thetopologicalvulnerability analysis, giving a value dependingon the impact in the service, in the amount ofaffected assets and its impact and the difficultyof exploitation.

Componentsof the

analysis

SOTVA must be a proactivetool, fed by allsecurity components available such as IDSs,security logs, system logs, network analysistools, automated security tools, etc.[1]

gives abetter approach of how to use these tools in aproduction environment. Using those tools, andup to date graphs, further attack vectors maybe considered, having an updated model andtherefore a better security perspective ofpotentialthreat.

After the first design of a SOTVA, newinformation could be identified, and answers toa sort of intriguing question.

An extensiveSOTVA analysis can identify which IT assets areexposed to a greater risk or which assets orappliances have the greatest impact on theorganization, letting the administrators toidentify what possible new vulnerabilities couldcause the most damage to a specific service orthe entire organization.

In a “hardening” perspective, this analysis helpto identify what network or service architecturechanges should be implemented to preventthecoupling between unsafe assets and how tomitigate unidentified vulnerabilities based onservice and network architectures. Through thisanalysis a new starting point of the hardeningprocesscould be written.

SOTVAand ITGovernance

One of the pillars of this methodology is itscoupling with common “service oriented” ITgovernance models like ITIL and COBIT. Theanalysis makes an important contribution in thedefinition of a security model and its securitypolicies and gives a new variable to consider inthe “delivery and support” domain defined inthe governance life cycle [5-COBIT], ServiceLevel Agreements and Service LevelRequirements, where security considerationsbecomes an obligation.

A new perspective of the BCP

[6-ITIL] could beformalized, especially in generating newstrategies and prevention plans.

Thismethodology is planned to be used in on-goingoperations [6] without disturbing actual ITprocesses based only on analysis for furtherimplementation of possible strategies definedin the SOTVA process. By giving a securityplanning environment, there is a clear view ofrisk assessment and mitigation and resourceplanning.

Changemanagement now could be understoodin a security context redefining SLA and SLR ofan organization. The application of the analysisgives another viewpoint to the service design(Plan & Organize), providing a better continualservice improvement in a security andavailability perspective.

Conclusion

Like

TVA models, SOTVA propose a change invulnerability analysis, now, a service oriented,coupled to IT governance. This approachhighlights the importance of security policiesand documentation to actual vulnerabilityanalysts, giving a stretch relation betweenspecific vulnerabilities and enterprise securityprocesses.

Having as a frame of reference specificorganization services,a “process oriented”security model could be define to give abeginning to the security process, a proactivesecurity model easily expandable to cover all (orat least most) IT processes in the organization.