Based on the question title, I need a IEEE paper format of at least 8 pages long (citations are must)and ppt slides of at least 25 which should summarize the written paper.The paper should contain 0(Zero) plagiarism. The uploaded files are the reference paper of the above title and IEEE format template.

Imp: Reference papers collected must be submitted at the end of the paper and ppt submission.

Computational Evaluation of Software Security Attributes

Gwendolyn H. Walton
Florida Southern College and

Software Engineering Institute/CERT

Carnegie Mellon University

Thomas A. Longstaff
Johns Hopkins University

Applied Physics Laboratory

Richard C. Linger
Software Engineering Institute/CERT

Carnegie Mellon University

Abstract
In the current state of practice, security

properties of software systems are typically assessed
through subjective, labor-intensive human
evaluation. Moreover, much of the quantitative
security analysis research to date is characterized by
the development of approximate solutions and/or
based on assumptions that severely constrain the
operational utility of the results. In order to achieve a
dramatic increase in maturing the discipline of
software security engineering, a fundamentally
different approach to analysis and evaluation of
security attributes is required. The computational
security attributes (CSA) approach to software
security analysis provides a new approach for
specification of security attributes in terms of data
and transformation of data by programs. This paper
provides an introduction to the CSA approach,
provides behavioral requirements for several security
attributes, and discusses possible application of the
CSA approach to support analysis of security
attributes during software development, acquisition,
verification, and operation.

1. Introduction

Dynamic security analyses are necessary if an
organization hopes to keep pace with the potential
impacts from ongoing program maintenance and
system evolution, changing threats in the operational
environments, and changes in organizational security
strategies. However, in the current state of practice,
security properties of software systems are typically
assessed through subjective, labor-intensive human
evaluation.

The behavior of users and administrators, the
operating environment, and data transmission
mechanisms are non-deterministic. Researchers have
typically addressed this non-determinism by using a
variety of analytical tools such as model checking,

concurrent sequential process modeling, and rule-
based systems to model, analyze, and verify security
protocols. In recent years, several research threads
have emerged that address security metrics and
quantitative and qualitative analysis and evaluation of
security attributes. Much of the security attribute
analysis research to date is characterized by the
development of approximate solutions and/or based
on assumptions that severely constrain the
operational utility of the results. In order to achieve a
dramatic increase in maturing the discipline of
software security engineering, a fundamentally
different approach to analysis and evaluation of
security attributes is required.

The CSA approach to software security analysis
provides theory-based foundations for precisely
defining and computing security attribute values. The
translation of a static security property expressed as
an abstraction of external data to dynamic behavior
of a program expressed in terms of its data and
functions is key to the CSA approach to verification
of behavior that meets a specific security property.
The ultimate goal of the CSA research is to develop
mathematical foundations and corresponding
automation to permit both rigorous evaluation and
improvement of the security attributes of software
during development and real-time evaluation of
security performance during operation.

2

. The CSA Analysis Approach

The CSA approach to security attribute analysis,
illustrated in Figure 1, consists of three steps:
• Define required security behavior: Specify

security attributes (such as authentication, non-
repudiation, etc.) in terms of required behavior
during execution expressed in terms of data and
transformation of data by programs.

• Calculate program behavior: Create a behavior
database using the new technology of function
extraction (FX) that contains the specification for

Proceedings of the

4

2nd Hawaii International Conference on System Sciences – 200

9

19

7

8

-0-7

6

9

5

–

3

450-3/09 $25.00 © 2009 IEEE

the complete �as built� functional behavior of the
code.

• Compare program behavior to required security
behavior: Compare the computed behavior
database with required security attributes to
verify whether the software meets its security
requirements.

2.1. Define required security behavior

Requirements for security attribute behavior
must explicitly define expected behavior of code in
all circumstances of interest. Thus, the requirements
for security attribute behavior must include a minimal
definition of required behavior for all inputs of
interest to the security attributes, including desired
inputs (for example, an authenticated user id) and
undesired inputs (for example: an unknown user id).
Usage environment conditions related to security
attributes are specified in the same manner as inputs
to the system. For example, availability of the
network might be specified by a Boolean value that
indicates whether or not the network is currently
available. Security successes and failures are also
specified in terms of data. For example, system
control data can be used to indicate whether the

current user has been authenticated using a trusted
authentication mechanism.

The level of abstraction at which a security
attribute is specified can depend on the specific
situation. For example, if all available data
transmission mechanisms have previously been
certified to be trusted, the security attribute
requirements would not need to include details about
data transmission. If there is one trusted data
transmission mechanism, X, and one or more data
transmission mechanisms that may not be trusted, the
security attribute requirements could specify that all
data transmissions will be performed using X. If none
of the data transmission mechanisms have been
previously certified as trusted, the security attribute
requirements will need to include required control
data effects for transmission security.

A �never responded� and �no output� case for
each external function call of interest must be
considered, including a definition of correct behavior
in the case of intentional and unintentional aborts and
hangs. In addition, security attribute requirements
may specify a specific order in which certain
functions can be called. For example: user
authentication must occur before any data access
functions can be called.

Function
Extractor

Behavior
Catalog

Required
Security
Attribute
Behavior

CS

A

Analyzer

Security property
satisfied (or not)

Input

Program

Calculate
Program
Behavior

Define
required
security
behavior

Compare
program
behavior

to
required

security

behavior

CSA Analysis

Function
Extractor
Behavior
Catalog
Required
Security
Attribute
Behavior
CSA
Analyzer
Security property
satisfied (or not)
Input
Program
Calculate
Program
Behavior
Define
required
security
behavior
Compare
program
behavior
to
required
security
behavior
CSA Analysis

Figure 1. CSA analysis

The requirements may specify that a certain set

of data transformations always occur. For example,
the control data that indicates that data transmission
is secure must always be set by the trusted data
transmission mechanism. The requirements may
specify that a certain set of data transformation must
never occur. For example, the control data that
indicates that data transmission is secure must never
be set by any code other than the trusted data

transmission mechanism. If a user is authorized to
only access specific data, the requirements may state
that no data transformations other than a specific set
of data transmissions can occur.

Any amount of traceability and control can be
specified in the requirements for security attribute
behavior. For example, the requirements may
include specifications of bounded behavior. (i.e., the
execution will proceed so long as the behavior is

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009

2

within a specified domain). Specifications for trusted
mechanisms can be included in the requirements as a
constraint. For example, one might specify that �a
call to method XXX that returns a value of y is
sufficient to satisfy a requirement that a trusted
mechanism must be used to perform authentication.�

A behavioral approach also supports dealing
with some uncertainty in the specification of the
security attribute requirements. For example, a
security requirement might state that the code must
guarantee security properties modulo some defined
value. Some constraints might be specified using a
stochastic component. For example, �The response
history of component X must indicate that the
component was available at least 94% of the time.�

2.2. Calculate program behavior

In this context, behavior means the as-built net
functional effect of a program (and its constituent
control structures and instructions) from entry to exit.
Behavior calculation means to create a behavior
database that specifies the behavior of the code.

Software with unknown behavior cannot be
certified as secure. Thus, a behavior database
containing all externally observable behaviors is an
essential input to security attribute analysis. For
software developed in-house, the behavior database
might be derived from the specification from which
the software is developed and verified. For procured
software, a complete behavior database might be part
of the acquisition requirements. For existing software
for which a behavior database is not available,
intensive manual effort to understand the code may
be necessary.

The CERT® organization of the Software
Engineering Institute is developing Function
Extraction (FX) theory and technology for
understanding program behavior. [1, 4, 5, 7] The
objective of this work is to compute the functional
behavior of programs with mathematical precision to
the maximum extent possible. The FX approach to
program comprehension eliminates the need to study
and understand code by manual means. The ultimate
goal of the FX technology project is to develop
theory and tools to automatically calculate program
behavior based on precise semantics of the
programming language, producing databases that
represent the net behavior of programs in terms of
disjoint conditional concurrent assignment
statements.

FX technology is based on a function-theoretic
view that treats programs and their parts as rules for
mathematical functions or relations subject to

compositional analysis to derive net effects. CERT®
researchers are currently developing an FX system to
support function extraction of assembly programs
using complete semantics for Intel 32-bit assembly
language code.

Behavior databases produced by the FX system
provide several advantages for security attribute
analysis:
• A behavior database lends itself to query and

thus can facilitate risk assessments and other
query-driven analyses of security attributes.

• Because the behavior database supports
examination of the functional transformations on
data and does not require examination of the
state space, this approach is more scalable than
formal methods approaches. For example, when
formal methods are used to examine the integrity
attribute, the entire state space must be
computed. Integrity exists if the system can
never map outside the state space. In contrast,
with CSA and the use of behavior databases,
only the calculated behavior is of interest.
Because only externally observable behavior is
relevant to security attribute analysis, only the
behavior at the boundary of the system is
required for the calculation. Thus, there is no
need to calculate the internal behavior of trusted
components, and there is no need to expose the
entire internal state space.

• If a property can be expressed in code, FX
technology can be used to determine if that
property holds within a program.

• FX technology can be used to describe the
behavior of a function that combines two
behaviors. Thus, FX can be used to give the
exact description of the composition of the
behaviors.

• Corporate policies and �intentions� can be
defined in a behavioral format in advance of the
design of the architecture and code. Queries to
examine the behavior database for the presence
or absence of desired properties can be
developed in parallel with design of the
architecture. If pre- and post-conditions are
defined behaviorally, they can be used to
evaluate all artifacts (i.e., the behavioral
databases, not just the code.)

2.3. Compare program behavior to required
security behavior

The translation of a static security property
expressed as an abstraction of external data to
dynamic behavior of a program expressed in terms of

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009
3

its data and functions is key to the verification of
behavior that meets a specific security property.
Verification that a security property is satisfied
requires verification of both the data at rest (i.e. the
control data values) and the data in motion (i.e., the
mechanisms used to perform the data
transformations). Some common tasks to verify data
at rest include checking to make sure that a specific
task (for example, an audit task) will always be
carried out to check the contents of a specific control
data structure.

The CSA approach to security attribute
verification includes the use of constraints and
boundary conditions to make any assumptions
explicit. People and process issues can be handled by
the CSA approach by using assumptions and
constraints as part of the behavior databases. In
addition, behaviors can embody requirements for a
given security architecture. Thus, the attribute
verification process will expose security
vulnerabilities, making it easier to address evolution
of code, environment, use, etc.

3. Behavioral requirements of security
attributes

The behavioral requirements for security
attributes can be completely described in terms of
data items and constraints on their processing. The
processing can be expressed, for example, as logical
or quantified expressions or even conditional
concurrent assignments, which can be mechanically
checked against the calculated behavior of the
software of interest for conformance or non-
conformance with security attribute requirements.

Security attributes are inter-related. For example,
authentication relies on non-repudiation as a strict
subset of the required security behavior. Thus,
quantitative reasoning about the attributes requires an
integrated set of security attribute definitions.

3.1. Use of a trusted mechanism

Each security attribute requires the use of one or
more trusted mechanisms that are implemented in
software components. A behavior database is needed
for each mechanism to describe all cases of behavior
in terms of the mechanism�s data and the
transformations it carries out on that data. This
behavior database is analyzed in terms of control data
and evidence data to ensure the following:
• The trusted mechanism sets the values of control

data, which indicates whether the mechanism
executed correctly.

• If control data indicates that the mechanism
executed correctly, there exists evidence data to
show that the data transformation was performed
in a manner that satisfies the defined security
specification.
Note that the implementation of a security

attribute may include a trusted third party to acquire,
authenticate, and adjudicate evidence of transactions.
However, for the purposes of behavior specification
of security attributes, the specific mechanism and
actors are not relevant. All that is needed is a precise
specification of the data and the transformations of
the data and any constraints concerning those
transformations.

3.2. Trusted data transmission

Figure 2 illustrates the requirements for trusted
data transmission:
• A trusted data transmission mechanism is used

for all data transmissions. If the mechanism is
not available or the mechanism fails, the
requirement fails.

• No mechanism outside this trusted data
transmission mechanism sets the value of the
control data that indicates whether the data
transmission mechanism executed correctly.
Figure 3 illustrates the process for determining

whether data transmission security properties are
satisfied by the data transmission components of a
system. This process consists of the application of the
CSA analysis process illustrated in Figure 1, where
the input is the data transmission components of the
system, and the output is a determination of whether
the data transmission security requirements have
been satisfied. Similarly, the process for determining
whether the remainder of the system can modify the
control data set by the data transmission components
consists of application of the CSA analysis process of
Figure 1, where the input to the process is the
software for the entire system, and the output is a
determination of whether the control data set by the
data transmission components can be modified by
any other part of the system.

The process for determining whether the
remainder of the system can modify the control data
set by the data transmission components, illustrated
in Figure 4, consists of the application of the CSA
analysis process of Figure 1, where the input to the
process is the software for the entire system, and the
output is a determination of whether the control data
set by the data transmission components can be
modified by any other part of the system.

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009
4

CSA Analysis:
data transmission

security
CSA Analysis:
data transmission
security

Data
Transmission
mechanism

Data
Transmission
mechanism

security
property

satisfied?

CSA Analysis:
no modification

of data transmission
control data

CSA Analysis:
no modification
of data transmission
control data

Remainder
of the

System

Remainder
of the
System

security
property
satisfied?

both
properties
satisfied?

No. Data
transmission
is not trusted.

Yes. Data
transmission

is trusted.

CSA Analysis:
data transmission
security
CSA Analysis:
data transmission
security
Data
Transmission
mechanism
Data
Transmission
mechanism
security
property
satisfied?
CSA Analysis:
no modification
of data transmission
control data
CSA Analysis:
no modification
of data transmission
control data
Remainder
of the
System
Remainder
of the
System
security
property
satisfied?
both
properties
satisfied?
No. Data
transmission
is not trusted.
Yes. Data
transmission
is trusted.

Figure 2. Requirements for trusted data transmission

Behavior
Catalog

Data
transmission

security
requirements

Analysis
of security
behavior

Data
Transmission

Program

Calculate
programmed

effects on

control data

Define required
control data
effects for

transmission
security

Compare
program
behavior

with required
effects on

control data
Function
Extractor

CSA Analysis: Data transmission security

Security property
satisfied (or not)
Behavior
Catalog
Data
transmission
security
requirements
Analysis
of security
behavior
Data
Transmission
Program
Calculate
programmed

effects on
control data

Define required
control data
effects for
transmission
security
Compare
program
behavior
with required
effects on
control data
Function
Extractor
CSA Analysis: Data transmission security

Security property
satisfied (or not)

Figure 3. CSA analysis of data transmission security

As illustrated in Figure 4, to verify that a data
transmission mechanism is trusted, it is necessary to
verify the data that provides the evidence related to
data transmission. For example, the specification for
the data that provides evidence of valid data
transmission may describe the mechanism by which
each data message output incorporates a shared
(between sender and receiver) data item that can be
used to verify that the transformation worked
correctly. Assignments to this shared data must not

be reversible (i.e., guaranteed encryption.) As another
example, suppose the behavior databases for all of
the code have been examined to verify that all data
transmissions in the system occur as a result of calls
to function YYY. To verify the necessary security
properties for data transmission, it is necessary to
examine function YYY�s behavior database to
determine the net effect of the data transformations
related to any conditions for which invalid data
transmission could occur.

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009
5

Behavior
Catalog

Requirements for
no modification

of specific control
data

Analysis
of security
behavior
Security property
satisfied (or not)

Remainder
of the system

Calculate
programmed
effects on
control data

Define requirements
for security property =

no modification
of data transmission

control data
Compare
program
behavior

with requirement
for no modification

of data transmission
control data

Function
Extractor

CSA Analysis: no modification of
data transmission control data

Figure 4. CSA analysis of modification of data transmission control data

3.3. The authentication security attribute

Authentication requires that a trusted user has
been bound to the behavior. That is, the system will
only allow the requested program to be executed if
the user has previously been determined to be a
trusted user. To verify authentication, one must
examine the net effects on the control data related to
authentication: verify the data that provides evidence
that the binding took place, and verify that this
evidence data was not changed before completion of
any operation that required authentication. The
requirements for authentication are as follows:
• A trusted data transmission mechanism is always

used for every data transmission.
• A trusted identification mechanism is always

used to provide proof of a user�s identification.
Note that the �user� to be identified may be a
person, a process, a program, or other entity.

• A trusted binding mechanism is always used to
bind user data (user identification, password, or
other information to confirm the identification,
and the system information that provides the
proof of the identification) to an execution
environment.

• No other mechanism outside the trusted
mechanisms sets the value of any of the control
data that indicates whether each of the trusted
mechanisms executed correctly and that indicates
the status of the bound data.

• If any of the above requirements or mechanisms
fails, authentication fails.
The mechanism for using CSA to determine

whether the data transmission is trusted was

discussed earlier. The application of the CSA
approach for analysis of the user identification
mechanism and the user binding mechanism proceeds
along the same lines as Figures 3 and 4 to determine
whether each of these mechanisms is trusted.

3.4. The authorization security attribute

Authorization requires that a user has the right
to do the requested process. To verify that an
authorized operation took place, one must examine
the net effects on the control data to verify that it
provides evidence that authorization occurred before
the operation, and that the evidence data for the
authorization was not changed before that operation
completed. The requirements for authorization are as
follows:
• A trusted authentication mechanism (subsection

3.3) is always used to authenticate the user. Note
that this requirement includes a requirement for
trusted data transmission and authentication.

• A trusted lookup mechanism is always used to
determine that the user has the right to complete
the specified request.

• No other mechanism outside the trusted
mechanisms sets the value of any of the control
data that indicates whether each of the trusted
mechanisms executed correctly and that
identifies the authorized user and the scope of
the authorization.

• If any of the above requirements or mechanisms
fails, authentication fails.
Analysis of the authentication mechanism was

discussed in the previous subsection. Analysis of the

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009
6

lookup mechanism applies the CSA approach by
proceeding along the same lines as Figures 3 and 4 to
determine whether this mechanism is trusted.

3.5. The non-repudiation security attribute

Non-repudiation of data transmission requires
that neither the sender nor the recipient of the data
can later refute their participation in the transaction.
Non-repudiation of changes to a dataset requires that
the means for authentication of changes cannot later
be refuted. For the purposes of this discussion we
treat data change as a special case of data
transmission, where receipt of the data transmission
includes making and logging the requested change to
the dataset. To verify non-repudiation, one must
examine the net effects on the control data related to
non-repudiation. The requirements for every data
transmission that is subject to non-repudiation are as
follows:
• Trusted authorization (subsection 3.3) is always

used for sender, receiver, and the scope of any
data changed or transmitted. Note that this
requirement includes a requirement for trusted
data transmission, trusted authentication of users,
and trusted authorization of users and processes
for the specific data scope.

• Trusted binding is used to bind the sender to the
data sent and to bind the receiver to data
received.

• The authorization, binding, and data
transmission are handled as a single atomic
operation within the boundary of the authorized
secure process.

• A trusted mechanism is always used to provide
traceability and audit. This trusted mechanism
ensures data persistence of the audit data so the
means of authentication and the data
transmission cannot later be refuted.

• Every data transmission is preceded by an
absolute definition of the data and identification
that binds the data to the sender.

• Every data receipt is preceded by an absolute
definition of the data and identification that
binds the data to the recipient.

• No other mechanism outside the trusted
mechanisms sets the value of any of the control
data that indicates whether each of the trusted
mechanisms executed correctly or the value of
any of the control data generated by the trusted
mechanisms.

• If any of the above requirements or mechanisms
fails, non-repudiation fails.

Analysis of the authorization mechanism was
discussed in the previous subsection. Analysis of the
binding mechanism and the traceability and audit
mechanism applies the CSA approach by proceeding
along the same lines as Figures 3 and 4 to determine
whether each of these mechanisms is trusted.

3.6. The confidentiality security attribute

Confidential data access or confidential data
transmission requires that unauthorized disclosure of
one or more specific data items will not occur.
Confidentiality is often described in terms of a
security policy that specifies the required strength of
the mechanisms that ensure that the data cannot be
accessed outside the system. For example, the
security policy may require verification that approved
encryption mechanisms are used for the output. To
verify confidentiality, one must examine the net
effects on the control data related to confidentiality.
The requirements for confidentiality are as follows:
• A trusted non-repudiation mechanism

(subsection 3.5) is always used to process
requests for confidential data access and
confidential data transmission. Note that this
requirement includes a requirement for trusted
data transmission, trusted authentication of users
and processes, and trusted authorization of users
and processes for the particular data scope.

• A trusted mechanism is always used to ensure
that the data cannot be read outside the system.

• No other mechanism outside the trusted
mechanisms sets the value of any of the control
data that indicates whether each of the trusted
mechanisms executed correctly or the value of
any of the control data set by the trusted
mechanisms.

• If any of the above requirements or mechanisms
fails, the request for confidential data access or
confidential data transmission fails.
Analysis of the non-repudiation mechanism was

discussed in the previous subsection. Analysis of the
data access mechanism applies the CSA approach by
proceeding along the same lines as Figures 3 and 4 to
determine whether this mechanism is trusted.

3.7. The privacy security attribute

Privacy requires that an individual has defined
control over how his/her information will be
disclosed. To verify privacy, one must examine the
net effects on the control data related to privacy. The
requirements for privacy are as follows:

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009
7

• A trusted confidentiality mechanism
(subsection 3.6) is always used for all
accesses of a user�s personal information.
Note that this requirement includes a
requirement for trusted data transmission,
trusted authentication of users and
processes, trusted authorization of users and
processes for the specific data scope, and
trusted non-repudiation for access to a user�s
personal information

• All access to a user�s personal information
satisfies an existing privacy and
confidentiality policy that includes control
data that defines the scope of access for each
user.

• A trusted non-repudiation mechanism
(subsection 3.4) is used for all changes to
the control data that defines the scope of
access for each user. Note that this
requirement includes a requirement for
trusted data transmission, trusted
authentication of users and processes and
scope of data

• No other mechanism outside the trusted
mechanisms sets the value of any of the
control data that indicates whether each of
the trusted mechanisms executed correctly
or the value of any data set by the trusted
mechanisms.

• If any of the above requirements or
mechanisms fails, the request for
confidential data access or confidential data
transmission fails.

Analysis of the confidentiality and non-
repudiation mechanisms was discussed in previous
subsections. Analysis of the access mechanism
applies the CSA approach by proceeding along the
same lines as Figures 3 and 4 to determine whether
this mechanism is trusted.

3.8 The integrity security attribute

Integrity requires that authorized changes are
allowed, changes must be detected and tracked, and
changes must be limited to a specific scope. Integrity
is defined as a property of the object, not of a
mission. To verify integrity, one must examine the net
effects on the control data related to integrity. That
is, one must be able to: isolate the object, isolate all
the behaviors that can modify the object, detect any
modifications to the data, and ensure that all
transformations of the data across the object are
within the pre-defined allowable subset. The
requirements for integrity are as follows:

• A security policy exists that describes the
scope of allowed changes as an invariance
function: certain data transformations must
hold; others must never hold.

• If the security policy data is changed to
remove any element from the allowable
subset, integrity of the data fails.

• A trusted non-repudiation mechanism
(subsection 3.4) is always used for changes
to data and changes to policy to ensure that
all changes to the security policy and
changes to data are performed using a
trusted non-repudiation mechanism. Note
that this requirement includes a requirement
for trusted data transmission, trusted
authentication of users and processes,
trusted authorization of users and processes
for the specific data scope, and trusted non-
repudiation for changes to the data. Every
authorization for data changes must be
restricted to the allowable subset as defined
in the security policy.

• No other mechanism outside the trusted
mechanisms sets the value of any of the
control data that indicates whether each of
the trusted mechanisms executed correctly
or the value of the control data set by any of
the trusted mechanisms.

• If any of the above requirements or
mechanisms fails, integrity of the data fails.

Analysis of the non-repudiation mechanism was
discussed in a previous subsection. Analysis of the
data change mechanism applies the CSA approach by
proceeding along the same lines as Figures 3 and 4 to
determine whether this mechanism is trusted.

3.9. The availability security attribute

Availability requires that a resource is usable
during a given time period, despite attacks or
failures. To verify availability, one must examine the
net effects on the control data related to availability.
To avoid having to consider temporal properties, one
can specify non-availability rather than availability.
(i.e., specify under what conditions the program�s
behavior database do not apply.) Liveness properties
are translated to the behavioral characteristics that are
evident when the system is actually available.
Specific behaviors associated with non-availability
due to denial of service must also be specified.

4. Miniature illustration of CSA with FX

Consider the screen image of behavior generated

by the CERT® Function Extraction for Malicious

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009
8

Code (FX/MC) prototype, as shown in Figure 5. This
system is under development by CERT® to compute
the behavior of malicious code expressed in Intel
assembly language. FX/MC produces the net
behavior of programs in terms of disjoint conditional
concurrent assignment statements. That is, each case
of behavior is expressed by a condition and a set of
non-procedural assignments that define the final
values of registers, flags, and memory locations on
exit from an assembly language program.

This notional example illustrates application of
the CSA approach to determine whether a security
requirement is satisfied. Suppose that the
specification of requirements for a security attribute
includes a constraint that the value of the second
argument to each call to function XXX must not be
equal to 4. A constraint such as this, expressed in
terms of concrete data operations and values, could
be part of the requirements specification for any of
the security attributes discussed above.

A

B

A
B

Figure 5: Computed behavior

Imagine that the behavior of Figure 5 defines the

behavior of a fragment of code that executes
immediately before the program calls function XXX
with the second argument equal to the value stored in
register EAX. The computed behavior highlighted as
section A is the behavior with respect to register
values for the condition ?(1 & EAX) == 0). This
condition means �if the value of register EAX at the
beginning of this fragment of code is even.� As
shown on the figure, if this condition is true, the
value of register EAX after executing this fragment
of code is equal to the initial value of register ECX,
and therefore the value of the second argument to
function XXX will be the initial value of register
ECX. In contrast, the computed behavior highlighted
as section B is the behavior with respect to register
values for the condition ?(1 & EAX) != 0). This
condition means �if the initial value of register EAX
is odd.� As shown on the figure, if this condition is
true, the value of register EAX is unchanged and
therefore the value of the second argument to
function XXX will be the initial value of register

EAX. Thus, the security constraint is not satisfied
because, under either of these conditions, it is not
possible to certify that the value of the second
argument will never be equal to 4.

Note that, using FX technology, this analysis can
take place in seconds through computational
automation, thereby eliminating the need to study and
understand the code by manual means.

5. Implications

The behavioral requirements for security
attributes provided in the previous section are
consistent with the general descriptions of the eight
security dimensions (access control, authentication,
non-repudiation, data confidentiality, communication
flow security, data integrity, availability, and
privacy), as contained in standard ISO/IEDC 18028-
2, Information Technology – Security Techniques – IT
Network Security – Part 2: Network Security
Architecture [3] and originally provided in the Bell

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009
9

Labs Security Framework [6]. We expect that the
CSA approach to security attribute analysis will be
very supportive of work to address the challenges of
security management and approaches to secure an
enterprise and regulatory mandates (Discussions of
the challenges of security management, are provided
in [2, 8].)

Advantages of the CSA approach include:
• A rigorous method is used to specify security

attributes in terms of the actual behavior of code
and to verify that the code being evaluated is
correct with respect to security attributes.

• The specified security behaviors can provide
requirements for the security architecture.

• Traceability capabilities can be defined and
verified outside of the code being evaluated.

• Vulnerabilities can be well understood, making it
easier to address evolution of code, environment,
use, and users.
CSA technology can address specification of

security attributes of systems before they are built,
specification and evaluation of security attributes of
acquired software, verification of the as-built security
attributes of systems, and real-time evaluation of
security attributes during system operation.

It should also be possible to verify that the
behavioral characteristics relating to security
properties are consistent with a global security policy
(e.g., running the code in the context of a system with
an expressed security policy). The use of a system
such as FX to perform this level of validation would
require a behavioral specification of the global
security policy in terms of system behavior, which
could then be automatically checked against program
behavior. As behavioral patterns scale through
different layers of abstraction, high-level security
behaviors can be expressed as a straight-forward
composition of program behavior.

6. Open Questions

Behavioral requirements for concurrency and
parallel system issues must be addressed. In addition,
because computational security attributes and
function extraction are emerging technologies, there
has been limited experience in applying the
technology to large systems. The computational
effort involved in analyzing large, complex
components and in analyzing large numbers of
component compositions to yield a system security
specification remains to be studied. However, it is
clear that the CSA approach can be effective in
addressing state space explosion while yielding
complete, correct answers.

7. Acknowledgement

CERT is a registered trademark and service mark of
Carnegie Mellon University.

8. References

[1] R.W. Collins, A.R. Hevner, G. H. Walton, R.C. Linger,
�The impacts of function extraction technology on program
comprehension: A controlled experiment�, Information and
Software Technology, 50(2008) 1165-1179. Elsevier, 2008.

[2] A.K. Gupta, U. Chandrashekhar, S. Sabnis, and F.A.
Bastry, �Building Secure Products and Solutions�, Bell
Labs Technical Journal, 12(3), p 23-38. Wiley Periodicals,
Inc. 2007.

[3] International Organization for Standardization and
International Electrotechnical Commission, Information
Technology – Security Techniques – IT Network Security –
Part 2: Network Security Architecture, ISO/IEC 18028-2 ,
Feb. 2006.

[4] R. Linger, M. Pleszkoch, L. Burns, A. Hevner, G.
Walton. �Next generation software engineering: Function
extraction for the computation of software behavior.
Proceedings of the 40th Annual Hawaii International
Conference on System Sciences (HICSS40), Hawaii. IEEE
Computer Society Press, Los Alamitos, CA 2007.

[5] R. Linger, S. Prowell, R. Bartholomew, L. Burns, T.
Daly. �Funcation extraction: automated behavior
computation for aerospace software verification and
certification� Proceedings of the American Institute of
Aeronautics and Astronautics (AIAA) Infotech & Aerospace
2007 Conference, California. IEEE Computer Society
Press, Los Alamitos, CA. May 2007.

[6] A.R. McGee, S.R. Vasireddy, C. Xie, D.D.
Picklesimer, U. Chandrashekhar, and S.H. Richman. �A
Framework for Ensuring Network Security�, Bell Labs
Technical Journal, 8(4), pages 7-27. Wiley Periodicals, Inc.
2004.

[7] M. Pleszkoch and R. Linger, �Improving Network
System Security with Function Extraction Technology for
Automated Calculation of Program Behavior,� Proceedings
of 37th Hawaii International Conference on System
Sciences, Hawaii, January, 2004, IEEE Computer Society
Press, Los Alamitos, CA, 2004

[8] S. Sabnis, U. Chandrashekhar, and F. Bastry.
�Challenges of Securing an Enterprise and Meeting
Regulatory Mandates�, Proceedings of the 12th
International Telecommunications Network Strategy and
Planning Symposium, 2006. NETWORKS 2006. Nov. 2006,
pages 1-6. IEEE Computer Society Press, Los Alamitos,
CA, 2002.

Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009

10

Title o

f

Paper

A. Author1, B. Co-author2, and C. Co-author2

1Department Name, Universit

y

Name, City, State, Country

2Department Name, Company / Institution Name, City, State, Country

Abstract –

Please consider these Instructions as guidelines for preparation of course reports. Note that these instructions are reasonably comparable to the standard IEEE typesetting format. Type the abstract

(

100 words minimum and 150 words ma

x

imum

)

using Italic font with point size 10. The abstract is an essential part of the paper. Use short, direct, and complete sentences. It should be brief and as concise as possible.

Keywords: A Maximum of 6 Keywords

1 Introduction

These are instructions for authors typesetting for paper reviews. This template has been prepared using the required format (Microsoft Word version 6.0 or later).

1.1 Instructions for authors

An electronic copy of your report must be uploaded to CSCADE.

2 Formatting instructions

Please use the styles contained in this document for: Title, Abstract, Keywords, Heading 1, Heading 2, Body Text, Equations, References, Figures, and Captions.

Do not add any page numbers and do not use footers and headers (it is ok to have footnotes).

2.1 Length

Check homework assignment for details.

2.2 Title

Type the title approximately 2.5 centimeters (1 inch) from the top of the first page and use 20 points type-font size in bold. Center the title (horizontally) on the page. Leave approximately 1 centimeter (0.4- inches) between the title and the name and address of yourself (and of your co-authors, if any.) Type name(s) and address(s) in 11 points and center them (horizontally) on the page. Note that authors are advised not to include their email addresses.

2.3 Section and subsection headings

2.3.1 Subsection within another subsection

Number section and subsection headings consecutively in numbers and type them in bold. Use point size 14 for section headings and 12 for subsection headings and 10 for subsection within a subsection.

2.3.2 Additional instructions on sections and subsections

Avoid using too many capital letters. All section headings including the subsection headings should be flushed left.

2.4 Main text

Use at least 2 centimeters (0.75 inch) for the left and right margins. Leave a 0.6 centimeters (0.25 inch) space between the two columns in the center of the page. Use font size (character size) 10 for text. The text should be prepared with single line spacing. Do not use bold in the main text. If you want to emphasize specific parts of the main text, use italics. Leave at least 2.0-2.5 centimeters margin at the page head (top of each page) for placing final page numbers and headers (final page numbers and running heads will be inserted by the publisher). Select a standard size paper such as A4 (210 X 297 mm) or letter (8.5 X 11 in) when preparing your manuscript.

2.5 Tables

All tables must be numbered consecutively. Table headings should be placed above the table. Tables should be as close as possible to where they are mentioned in the main text. Tables can span the two columns if need be within the page margins.

2.6 Figures

All illustrations, drawings, and photographic images will be printed in black and white. We recommend that you examine a printed copy of your paper (in black and white) and make the final adjustments before submission. All illustrations must be numbered consecutively (i.e., not section-wise). Center the figure captions beneath the figure. Do not assemble figures at the back of your article, but place them as close as possible to where they are mentioned in the main text. Figures can span the two columns if need be within the page margins.

2.7 Mathematical formulas

Mathematical formulas should be roughly centered and numbered, as in:

)
(
x
f
y

=

(1)

2.8 Page numbering

Do not number any pages in your reports and do not reference page numbers in the text.

2.9 Fine tuning

Do not end a page with a section or subsection heading. Keep footnotes to a minimum.

2.10 Finalization

Proofread your reports. Otherwise, you’ll lose points for your careless mistakes.

3 Conclusions

This template presents the formatting instructions for the reports. Please address any problems related to the use of this template to Dr. Hai Jiang by Email (

hjiang@astate.edu

).

4 References

Number in square brackets (“[ ]”) should cite references to the literature in the main text. List the cited references in numerical order at the very end of your paper (under the heading `References’). Start each referenced paper on a new line (by its number in square brackets).

[1] Leslie Lamport. “LaTeX: A Document Preparation System”. Addison-Wesley Publishing Company, 1986.

[2] Ree Source Person. “Title of Research Paper”; name of journal (name of publisher of the journal), Vol. No., Issue No., Page numbers (eg.728—736), Month, and Year of publication (eg. Oct 2006).