Seguridad Cibernetica

I. INTRODUCTION

The four concepts introduced here enable comparison and

evaluation of protection systems, including both analyzing

defeats by known exploits and also predicting likely vulnera-

bilities. In this section we will introduce these concepts which

will be expanded in the sections that follow.

These concepts resulted from one of the authors' partic-

ipation in an early test and evaluation program run by the

U.S. Department of Defense (DoD) [1]. The DoD engaged

penetration testers (a.k.a. ``white hat hackers'') to attack its

own computer protection systems and report back the results

of their attempts, with the intent that such testing would

expose weaknesses so that protections could be strength-

ened. In the early 2000s, the DoD sought an explanation for

how both the protection experts and the white hat hackers

could simultaneously claim victory in the same testing project

(i.e., the same hacking test).

The explanation is disturbing due to the potential that

the situation is spread across the cybersecurity community:

the protection experts and hackers each dened victory

differently. Protection experts dened victory as preventing

hackers from completing the specic attack vectors against

which the protections ostensibly defended, whereas hackers

dened victory as being able to complete at least some serious

attack vectors that they believed had injured the integrity of

the computing asset. In the early stages of the testing program,

the protection experts and the white hat hackers had each been

focusing on different attack vectors.

As a result, a signicant discovery was made: Each

of the ``protected'' computing assets had retained notable

vulnerabilities, despite being labeled as ``protected'' by

experts. Different protection systems left a different set of

vulnerabilities intact, but all protection systems that were

available in the commercial marketplace left at least some.

Although individual experts may have been quite competent

in addressing a particular set of attack vectors, it was apparent

that different experts had been concentrating on different

sets, without coordination to ensure completeness across all

potential attacks. There was some degree of overlap, but not a

common set of test vectors against which all experts had been

evaluating proposed protection systems.

Upon realization of this situation, and its gravity, the claims

of victory by the white hat hackers in the early tests were

analyzed for commonality. This differentiated security threats

into distinct classes, producing three threat classes that will

be discussed in the next section: piracy, tampering, and

reverse engineering [2]. A matching set of protection cate-

gories was then identied: license enforcement, anti-tamper,

and anti-reverse engineering. The test planning efforts then

leveraged this categorization in subsequent test projects to

analyze various available security products for effectiveness

against each different threat class. Another signicant dis-

covery was then made. There was no one-size-ts-all pro-

tection system available in the commercial marketplace.

This meant that an effective cybersecurity program would

require additional work. The owner of a computing asset

116

2169-3536

2014 IEEE. Translations and content mining are permitted for academic research only.

Personal use is also permitted, but republication/redistribution requires IEEE permission.

See http://www.ieee.org/publications_standards/publications/rights/index.html for more information. VOLUME 2, 2014

Wilson and Kiy: Some Fundamental Cybersecurity Concepts

would need to ascertain all threat classes against which a

defense was desirable. Only then could the proper security

product be selected for use, and in many situations, more

than a single security product would be needed. This added

a complicating factor. Not only would each security product

require evaluation for effectiveness against each threat class

for which protection was advertised, but each product would

also require evaluation for compatibility with other products

that might be used contemporaneously.

Additionally, it became obvious that a protection system

that was implemented using only programming techniques

within application software could be defeated by attack tools

that intercepted calls from the software to the operating

system (OS) and falsied or altered the outgoing or incoming

data [3]. This type of vulnerability persisted, even if the

protection system had been designed well enough to provide

a solid defense against software-based attacks, such as the

use of an application-layer debugger. The idea of ``tunneling

under the castlewall''  effective in medievalwarfare  turned

out to be similarly effective in cyber warfare. Essentially,

a protection system could only be reliably effective against

attacks that occurred at the same system layer in which the

protection system had been implemented, or attacks at higher

layers.

An easily-understood example of ``tunneling under'' a

protection system is the use of virtual machines and other

tools to perform execution run tracing and data falsication.

These tools can force many protections to reveal secrets that

are relied upon for security. Once the secrets are revealed,

protections that rely upon those secrets for security can be

defeated. Thus, even if well-designed, protections can be

vulnerable to attacks from lower layers. A denition of com-

puting layers is needed that enables meaningful analysis of

whether an attack is at the same layer as a protection system,

beneath it, or above it.

The common privilege ring model for computer

security [4] does not reach with sufcient renement into

hardware-based protections, and the TCP/IP stack model for

networked computing systems [5] is not sufciently tailored

to security issues to properly model protections and attacks.

A new ve layer model was developed that reaches down-

ward

...