A HIGH-LEVEL ASPECT-ORIENTED BASED LANGUAGE FOR

SOFTWARE SECURITY HARDENING

Azzam Mourad, Marc-Andr

e Laverdi

ere and Mourad Debbabi

Computer Security Laboratory

Concordia Institute for Information Systems Engineering

Concordia University, Montreal (QC), Canada

Keywords:

Software Security Hardening, Aspect-Oriented Programming (AOP), Security Hardening Patterns, Security

Hardening Plans, Trusted and Open Source Software (FOSS), Aspect-Oriented Language.

Abstract:

In this paper, we propose an aspect-oriented language, called SHL (Security Hardening Language), for speci-

fying systematically the security hardening solutions. This language constitutes our new achievement towards

developing our security hardening framework. SHL allows the description and speciﬁcation of security harden-

ing plans and patterns that are used to harden systematically security into the code. It is a minimalist language

built on top of the current aspect-oriented technologies that are based on advice-poincut model and can also be

used in conjunction with them. The primary contribution of this approach is providing the security architects

with the capabilities to perform security hardening of software by applying well-deﬁned solution and without

the need to have expertise in the security solution domain. At the same time, the security hardening is applied

in an organized and systematic way in order not to alter the original functionalities of the software. We explore

the viability and relevance of our proposition by applying it into a case study and presenting the experimental

results of securing the connections of open source software.

1 INTRODUCTION

In today’s computing world, security takes an increas-

ingly predominant role. The industry is facing chal-

lenges in public conﬁdence at the discovery of vul-

nerabilities, and customers are expecting security to

be delivered out of the box, even on programs that

were not designed with security in mind. The chal-

lenge is even greater when legacy systems must be

adapted to networked/web environments, while they

are not originally designed to ﬁt into such high-risk

environments. Tools and guidelines have been avail-

able for developers for a few years already, but their

practical adoption is limited so far. Nowadays, soft-

ware maintainers must face the challenge to improve

programs security and are often under-equipped to do

so. In some cases, little can be done to improve the

situation, especially for Commercial-Off-The-Shelf

(COTS) software products that are no longer sup-

ported, or their source code is lost. However, when-

∗

This research is the result of a fruitful collaboration

between CSL (Computer Security Laboratory) of Concor-

dia University, DRDC (Defense Research and Develop-

ment Canada) Valcartier and Bell Canada under the NSERC

DND Research Partnership Program.

ever the source code is available, as it is the case

for Free and Open-Source Software (FOSS), a wide

range of security improvements could be applied once

a focus on security is decided.

As a result, integrating security into software is

becoming a very challenging and interesting domain

of research. In this context, the main intent of our re-

search is to create methods and solutions to integrate

systematically security models and components into

FOSS. Our proposition, introduced in (Mourad et al.,

2007), is based on aspect-oriented programming AOP

and inspired by the best and most relevant methods

and methodologies available in the literature, in addi-

tion to elaborating valuable techniques that permit us

to provide a framework for systematic security hard-

ening.

The main components of our approach are the se-

curity hardening plans and patterns that provide an ab-

straction over the actions required to improve the se-

curity of a program. They should be speciﬁed and de-

veloped using an abstract, programming language in-

dependent and aspect-oriented (AO) based language.

The current AO languages, however, lack many fea-

tures needed for systematic security hardening. They

are programming language dependent and could not

363

Mourad A., Laverdière M. and Debbabi M. (2007).

A HIGH-LEVEL ASPECT-ORIENTED BASED LANGUAGE FOR SOFTWARE SECURITY HARDENING.

In Proceedings of the Second International Conference on Security and Cryptography, pages 363-370

DOI: 10.5220/0002128403630370

 SciTePress

be used to write and specify such high level plans

and patterns, from which the need to elaborate a lan-

guage built on top of them to provide the missing fea-

tures. In this context, we propose a language called

SHL for security hardening plans and patterns speci-

ﬁcation. It allows the developer to specify high level

security hardening plans that leverage priori deﬁned

security hardening patterns, which are also developed

using SHL.

This paper provides our new contributions in de-

veloping our security hardening framework. The ex-

perimental results presented together with the secu-

rity hardening plans and patterns, which are elabo-

rated using SHL, explore the efﬁciency and relevance

of our approach. The remainder of this paper is or-

ganized as follows. In Section 2, we introduce the

contributions in the ﬁeld of AOP languages for secur-

ing software. Afterwards, in Section 3, we summa-

rize our approach for systematic security hardening.

Then, in Section 4, we present the syntax and seman-

tics of SHL. After that, in Section 5, we illustrate the

useability of SHL into case studies. Finally, we offer

concluding remarks in Section 6.

2 RELATED WORK

In this Section, we only present an overview on some

AOP languages and the use of AOP for software se-

curity. The related work on the current approaches

for securing software (e.g. security design patterns,

secure coding) has been discussed in (Mourad et al.,

2007). There are many AOP languages that have

been developed. We distinguish from them AspectJ

(Kiczales et al., 2001) built on top of the Java pro-

gramming language, AspectC (Coady et al., 2001)

built on top of the C programming language, As-

pectC++ (Spinczyk et al., 2002) built on top of the

C++ programming language, AspectC# (Kim, 2002)

built on top of the C Sharp programming language

and the AOP version addressed for Smalltalk pro-

gramming language (Bollert, 1999). However, these

languages are used for code implementation and can-

not be used to specify abstract security hardening

plans and patterns, which is a requirement in our

proposition.

Regarding the use of AOP for security, the fol-

lowing is a brief overview on the available contribu-

tions. Cigital labs proposed an AOP language called

CSAW (Cigital Labs, 2003), which is a small super-

set of C programming language dedicated to improve

the security of C programs. De Win, in his Ph.D. the-

sis (DeWin, 2004), discussed an aspect-oriented ap-

proach that allowed the integration of security aspects

Figure 1: Schema of Our Approach.

within applications. It is based on AOSD concepts

to specify the behavior code to be merged in the ap-

plication and the location where this code should be

injected. In (Bodkin, 2004), Ron Bodkin surveyed the

security requirements for enterprise applications and

described examples of security crosscutting concerns,

with a focus on authentication and authorization. An-

other contribution in AOP security is the Java Security

Aspect Library (JSAL), in which Huang et al. (Huang

et al., 2004) introduced and implemented, in AspectJ,

a reusable and generic aspect library that provides se-

curity functions. These research initiatives, however,

focus on exploring the usefulness of AOP for secur-

ing software by security experts who know exactly

where each piece of code should be manually injected

and/or proposing AOP languages for security. None

of them proposed an approach or methodology for

systematic security hardening with features similar to

our approach.

3 SECURITY HARDENING

APPROACH

This section illustrates a summary of our whole ap-

proach for systematic security hardening. It also ex-

plores the need and usefulness of SHL to achieve our

objectives. The approach architecture is illustrated in

Figure 1.

The primary objective of this approach is to al-

low the developers to perform security hardening of

FOSS by applying well-deﬁned solutions and with-

out the need to have expertise in the security solu-

tion domain. At the same time, the security harden-

SECRYPT 2007 - International Conference on Security and Cryptography

364

ing should be applied in an organized and systematic

way in order not to alter the original functionalities of

the software. This is done by providing an abstraction

over the actions required to improve the security of

the program and adopting AOP to build and develop

our solutions. The developers are able to specify the

hardening plans that use and instantiate the security

hardening patterns using the proposed language SHL.

The abstraction of the hardening plans is bridged

by concrete steps deﬁned in the hardening patterns us-

ing also SHL. This dedicated language, together with

a well-deﬁned template that instantiates the patterns

with the plan’s given parameters, allow to specify the

precise steps to be performed for the hardening, tak-

ing into consideration technological issues such as

platforms, libraries and languages. We built SHL on

top of the current AOP languages because we believe,

after a deep investigation on the nature of security

hardening practices and the experimental results we

got, that aspect orientation is the most natural and ap-

pealing approach to reach our goal.

Once the security hardening solutions are built,

the reﬁnement of the solutions into aspects or low

level code can be performed using a tool or by pro-

grammers that do not need to have any security exper-

tise. Afterwards, an AOP weaver (e.g. AspectJ, As-

pectC++) can be executed to harden the aspects into

the original source code, which can now be inspected

for correctness. As a result, the approach constitutes

a bridge that allows the security experts to provide the

best solutions to particular security problems with all

the details on how and where to apply them, and al-

lows the software engineers to use these solutions to

harden FOSS by specifying and developing high level

security hardening plans.

4 SHL LANGUAGE

Our proposed language, SHL, allows the description

and speciﬁcation of security hardening patterns and

plans that are used to harden systematically security

into the code. It is a minimalist language built on

top of the current AOP technologies that are based on

advice-pointcut model. It can also be used in conjunc-

tion with them since the solutions elaborated in SHL

can be reﬁned into a selected AOP language (e.g. As-

pectC++) as illustrated in Section 5. We developed

part of SHL with notations and expressions close to

those of the current AOP languages but with all the

abstraction needed to specify the security hardening

plans and patterns. These notations and expressions

are programming language independent and without

referring to low-level implementation details. The

following are the main features provided by SHL:

• Automatic code manipulation such as code addi-

tion, substitution, deletion, etc.

• Speciﬁcation of particular code join points where

security code would be injected.

• Modiﬁcation of the code after the development

life cycle since we are dealing with already ex-

isting open source software.

• Modiﬁcation of the code in an organized way and

without altering its functional attributes.

• Description and speciﬁcation of security.

• Dedicated to describe and specify reusable secu-

rity hardening patterns and plans.

• Parameterized language to allow the instantiation

of the security hardening patterns through the se-

curity hardening plans.

• Programming language independent.

• Highly expressive and easy to use by security non

experts.

• Intermediary abstractness between English and

programming languages.

• Easily convertible to available AOP languages

(e.g. AspectJ and AspectC++).

4.1 Grammar and Structure

In this section, we present the syntactic constructs and

their semantics in SHL. Table 1 illustrates the

BNF

grammar of SHL. The language that we arrived at can

be used for both plans and patterns speciﬁcation, with

a speciﬁc template structure for each of them. We im-

plemented this language speciﬁcation using ANTLR

V3 Beta 6 and its associated ANTLRWorks develop-

ment environment. We were also able to validate the

syntax of different plan and pattern examples within

this tool. The work on the language implementation

is still in progress. Examples of security hardening

plans and patterns are elaborated using SHL and pre-

sented in Section 5.

Hardening Plan Structure. A hardening plan

starts always with the keyword

Plan

, followed by

the plan’s name and then the plan’s code that starts

and ends respectively by the keywords

BeginPlan

and

EndPlan

. Regarding the plan’s code, it is com-

posed of one or many pattern instantiations that al-

low to specify the name of the pattern and its pa-

rameters, in addition to the location where it should

be applied. Each pattern instantiation starts with the

keyword

PatternName

followed by a name, then the

A HIGH-LEVEL ASPECT-ORIENTED BASED LANGUAGE FOR SOFTWARE SECURITY HARDENING

365

Table 1: Grammar of SHL.

Start ::= SH Plan

| SH

Pattern

Plan ::=

Plan

Plan Name

Plan Code

Plan

Name ::= Identiﬁer

Plan Code ::=

BeginPlan

Pattern Instantiation*

EndPlan

Pattern Instantiation ::=

PatternName

Pattern Name

(

Parameters

Pattern Parameter*)?

Where

Module Identiﬁcation+

Pattern

Name ::= Identiﬁer

Pattern

Parameter ::= Parameter Name Parameter Value

Parameter

Name ::= Identiﬁer

Parameter

Value ::= Identiﬁer

Module

Identiﬁcation ::= Identiﬁer

Pattern ::=

Pattern

Pattern Name

Matching

Criteria?

Pattern Code

Matching

Criteria ::=

Parameters

Pattern Parameter+

Pattern Code ::=

BeginPattern

Location Behavior*

EndPattern

Location Behavior ::= Behavior Insertion Point+ Location Identiﬁer+

Primitive*?

Behavior

Code

Behavior

Insertion Point ::=

Before

After

Replace

Location Identiﬁer ::=

FunctionCall <Signature>

FunctionExecution <Signature>

WithinFunction <Signature>

CFlow <Location Identifier>

GAflow <Location Identifier>

GDFlow <Location Identifier>

| ...

Signature ::= Identiﬁer

Primitive ::=

ExportParameter <Identifier>

ImportParameter <Identifier>

| ...

Behavior

Code ::=

BeginBehavior

Code Statement

EndBehavior

SECRYPT 2007 - International Conference on Security and Cryptography

366

keyword

Parameters

followed by a list of parame-

ters and ﬁnally by the keyword

Where

followed by

the module name where the pattern should be applied

(e.g. ﬁle name).

Hardening Pattern Structure. A hardening pat-

tern starts with the keyword

Pattern

, followed by

the pattern’s name, then the keyword

Parameters

followed by the matching criteria and ﬁnally the

pattern’s code that starts and ends respectively by

the keywords

BeginPattern

and

EndPattern

. The

matching criteria are composed of one or many pa-

rameters that could help in distinguishing the patterns

with similar name and allow the pattern instantiation.

The pattern code is based on AOP and composed of

one or many

Location Behavior

constructs. Each

one of them constitutes the location identiﬁer and the

insertion point where the behavior code should be in-

jected, the optional primitives that may be needed in

applying the solution and the behavior code itself. A

detailed explanation of the components of the pat-

tern’s code will be illustrated in Section 4.2.

4.2 Semantics

In this Section, we present the semantics of the im-

portant syntactic constructs in SHL language.

Pattern

Instantiation. Speciﬁes the name of the

pattern that should be used in the plan and all the

parameters needed for the pattern. The name and

parameters are used as matching criteria to iden-

tify the selected pattern. The module where the

pattern should be applied is also speciﬁed in the

Pattern Instantiation

. This module can be the

whole application, ﬁle name, function name, etc.

Matching

Criteria. Is a list of parameters added to

the name of the pattern in order to identify the pat-

tern. These parameters may also be needed for the

solutions speciﬁed into the pattern.

Location

Behavior. Is based on the advice-

pointcut model of AOP. It is the abstract rep-

resentation of an aspect in the solution part of

a pattern. A pattern may include one or many

Location Behavior

. Each

Location Behavior

is composed of the

Behavior Insertion Point

Location Identifier

, one or many

Primitive

and

Behavior Code

Behavior Insertion Point. Speciﬁes the point of

code insertion after identifying the location. The

Behavior Insertion Point

can have the follow-

ing three values:

Before

After

Replace

. The

Replace

means remove the code at the identiﬁed lo-

cation and replace it with the new code, while the

Before or After

means keep the old code at the

identiﬁed location and insert the new code before or

after it respectively.

Location

Identiﬁer. Identiﬁes the joint point or

series of joint points in the program where the

changes speciﬁed in the

Behavior Code

should

be applied. The list of constructs used in the

Location Identifier

is not yet complete and left

for future extensions. Depending on the need of the

security hardening solutions, a developer can deﬁne

his own constructs. However, these constructs should

have their equivalent in the current AOP technologies

or should be implemented into the weaver used. In the

sequel, we illustrate the semantics of some important

constructs used for identifying locations:

FunctionCall <Signature>

Provides all the join

points where a function matching the signature

speciﬁed is called.

FunctionExecution <Signature>

Provides all

the join points referring to the implementation of

a function matching the signature speciﬁed.

WithinFunction <Signature>

Filters all the join

points that are within the functions matching the

signature speciﬁed.

CFlow <Location Identifier>

Captures the join

points occurring in the dynamic execution con-

text of the join points speciﬁed in the input

Location Identifier

GAflow <Location Identifier>

Operates on the

control ﬂow graph (CFG) of a program. Its

input is a set of join points deﬁned as a

Location Identifier

and its output is a single

join point. It returns the closest ancestor join point

to the join points of interest that is on all their run-

time paths. In other words, if we are considering

the CFG notations, the input is a set of nodes and

the output is one node. This output is the clos-

est common ancestor that constitutes (1) the closet

common parent node of all the nodes speciﬁed in

the input set (2) and through which passes all the

possible paths that reach them.

GDFlow <Location Identifier>

Operates on the

CFG of a program. Its input is a set of join points

deﬁned as a

Location Identifier

and its out-

put is a single join point. It returns the closest

child join point that can be reached by all paths

starting from the join points of interest. In other

A HIGH-LEVEL ASPECT-ORIENTED BASED LANGUAGE FOR SOFTWARE SECURITY HARDENING

367

words, if we are considering the CFG notations,

the input is a set of nodes and the output is one

node. This output (1) is a common descendant

of the selected nodes and (2) constitutes the ﬁrst

common node reached by all the possible paths

emanating from the selected nodes.

The

Location Identifier

constructs can be

composed with algebraic operators to build up other

ones as follows:

Location Identifier && Location Identifier

Returns the intersection of the join points speci-

ﬁed in the two constructs.

Location Identifier || Location Identifier

Returns the union of the join points speciﬁed in

the two constructs.

! Location Identifier

Excludes the join points

speciﬁed in the construct.

Primitive. Is an optional functionality that allows

to specify the variables that should be passed between

two

Location Identifier

constructs. The follow-

ing are the constructs responsible of passing the pa-

rameters:

ExportParameter <Identifier>

Deﬁned at the

origin

Location Identifier

. It allows to spec-

ify a set of variables and make them available to

be exported.

Importparameter <Identifier>

Deﬁned at the

destination

Location Identifier

. It allows

to specify a set of variables and import them

from the origin

Location Identifier

where the

ExportParameter

has been deﬁned.

Behavior

Code. May contain code written in any

programming language, or even written in English as

instructions to follow, depending on the abstraction

level of the pattern. The choice of the language and

syntax is left to the security hardening pattern devel-

oper. However, the code provided should be abstract

and at the same time clear enough to allow a devel-

oper to reﬁne it into low level code without the need

to high security expertise. Example of such code be-

havior is presented in Listing 2.

5 CASE STUDY: SECURING

CONNECTION OF CLIENT

APPLICATIONS

In this section, we illustrate our elaborated solutions

for securing the connections of client applications by

following the approach’s methodology and using the

proposed SHL language. In this context, we devel-

oped our own client application and selected an open

source software called APT to secure their connec-

tions using GnuTLS/SSL library. Our application,

which is a client implemented in C, allows to connect

and exchange data with a selected server, typically an

HTTP request.

Regarding APT, it is an automated package down-

loader and manager for the Debian Linux distribu-

tion. It is written in C++ and is composed of more

than 23 000 source lines of code (based on version

0.5.28, generated using David A. Wheeler’s ’SLOC-

Count’). It obtains packages via local ﬁle storage,

FTP, HTTP, etc. We have decided to add HTTPS sup-

port to these two applications. In the sequel, we are

going to present the hardening plan, pattern and as-

pect elaborated to secure the connections of APT.

5.1 Hardening Plan

In Listing 1, we include an example of effective secu-

rity hardening plan for securing the connection of the

APT software. The hardening plan of the our client

application will be the same, except for the plan’s

name and the modules where the patterns should be

applied (i.e. the ﬁles’ names speciﬁed after

Where

Listing 1: Hardening Plans for Securing Connection.

Plan

APT Secure Connection Plan

BeginPlan

PatternName

Se cu re C on ne ct io n P at te rn

Parameters

Language C/C++

API GNUTLS

Peer Cl i e n t

Pro toc ol SSL

Where

h tt p . cc conne ct . cc

EndPlan

5.2 Hardening Pattern

Listing 2 presents the solution part of the pattern for

securing the connection of the two aforementioned

applications using GnuTLS/SSL. The code of the

functions used in the

Code Behavior

parts of the

pattern is illustrated in Listing 3. It is expressed in

C++ because our applications are implemented in this

programming language. However, other syntax and

programming languages can also be used depending

on the abstraction required and the implementation

language of the application to harden.

SECRYPT 2007 - International Conference on Security and Cryptography

368

Listing 2: Hardening Pattern for Securing Connection.

Parameters

Language C/C++

API GNUTLS

Peer Cl i en t

Pro t o col SSL

BeginPattern

Before

FunctionExecution

<main> / / S t a r t i ng Poin t

BeginBehavior

/ / I n i t i a l i z e th e TLS l i br a r y

I n it ia l i z eT L S L i b ra ry ;

EndBehavior

Before

FunctionCall

<connect> / / TCP Connection

ExportParameter

<xcred>

ExportParameter

BeginBehavior

/ / I n i t i a l i z e th e TLS se s s io n r e s o u r c e s

I n it i a l iz e TL S S e ss i on ;

EndBehavior

After

FunctionCall

ImportParameter

BeginBehavior

/ / Add th e TLS handshake

AddTLSHandshake ;

EndBehavior

Replace

FunctionCall

<send>

ImportParameter

BeginBehavior

/ / Change the send f u n c ti o n s usi ng t h a t

/ / s o cket by th e TLS send f u n ct io ns of th e

/ / used API when us ing a sec ured s o c k et

SSLSend ;

EndBehavior

Replace

FunctionCall

ImportParameter

BeginBehavior

/ / Change the re c ei v e fu n c t i o n s u sing t ha t

/ / s o cket by th e TLS r e c ei v e fu n c t i on s o f

/ / t he used API when using a s ecur ed socke t

SSLReceive ;

EndBehavior

Before

FunctionCall

<clo se> / / So c ket clo s e

ImportParameter

<xcred>

ImportParameter

BeginBehavior

/ / Cut the TLS co n n e ction

CloseA ndDealoca teTLSSess ion ;

EndBehavior

After

FunctionExecution

<main>

BeginBehavior

/ / D e i n it i a l i z e the TLS l i b r a r y

D e i ni t ia l iz e TL S L ib ra r y ;

EndBehavior

EndPattern

Listing 3: Functions used in the pattern.

InitializeTLSLibrary

gnutls_global_init();

InitializeTLSSession

gnutls_init (session , GNUTLS_CLIENT );

gnutls_set_default_priority (session);

gnutls_certificate_type_set_priority (session , cert_type_priority );

gnutls_certificate_allocate_credentials(xcred);

gnutls_credentials_set (session , GNUTLS_CRD_CERTIFICATE , xcred);

AddTLSHandshake

gnutls_transport_set_ptr(session , socket);

gnutls_handshake (session);

SSLSend

gnutls_record_send(session, data , datalength);

SSLReceive

gnutls_record_recv(session, data , datalength);

CloseAndDealocateTLSSession

gnutls_bye(session , GNUTLS_SHUT_RDWR);

gnutls_deinit(session);

gnutls_certificate_free_credentials (xcred);

DeinitializeTLSLibrary

gnutls_global_deinit ();

5.3 Hardening Aspect

We reﬁned and implemented (using AspectC++)

the corresponding aspect of the pattern presented

in Listing 2. Due to space limitation, Listing

4 shows only an excerpt of the aspect, speciﬁ-

cally the handshake code inserted after the function

connect

. The reader will notice the appearance of

hardening sockinfo t

. These are the data structure

(hash table) and functions that we developed to import

and export the parameters needed between the appli-

cation’s components at runtime (since the primitives

ImportParamter

and

ExportParameter

are not yet

deployed into the weavers).

Listing 4: Excerpt of Aspect for Securing Connections.

aspect SecureConnection {

...

advice call("% connect(...)") : around () {

hardening_sockinfo_t socketInfo;

...

tjp->proceed();

//original connect

...

//TLS handshake

gnutls_transport_set_ptr (socketInfo.session ,

(gnutls_transport_ptr) (*(

int

*)tjp->arg(0)));

*tjp->result() = gnutls_handshake (socketInfo.

session);

}... };

5.4 Experimental Results

In order to validate the hardened applications, we

used the Debian apache-ssl package, an HTTP server

that accepted only SSL-enabled connections. We

populated the server with a software repository com-

pliant with APT’s requirements, so that APT can con-

nect automatically to the server and download the

needed metadata in the repository. Then, we weaved

(using AspectC++ weaver) the elaborated aspect with

the different variants of our application and APT. We

ﬁrst executed our own hardened application and made

it connect successfully to our local HTTPS-enabled

web server using HTTPS. Then, after building and

deploying the modiﬁed APT package, we tested suc-

cessfully its functionality by refreshing APT’s pack-

age database, which forced the software to connect to

both our local web server (Apache-ssl) using HTTPS

and remote servers using HTTP to update its list of

packages.

The experimental results in Figure 2 show the

packet capture, obtained using WireShark software,

of the encrypted trafﬁc between our version of APT

and its remote package repositories. The highlighted

A HIGH-LEVEL ASPECT-ORIENTED BASED LANGUAGE FOR SOFTWARE SECURITY HARDENING

369

Figure 2: Packet Capture of SSL-protected APT Trafﬁc.

lines show TLSv1 application data exchanged in en-

crypted form through HTTPS connections, exploring

the correctness of the security hardening process.

6 CONCLUSION

We proposed in this paper a language called SHL

for security hardening plans and patterns speciﬁca-

tion. This contribution constitutes our new accom-

plishment towards developing our security hardening

framework. By using our approach, developers are

able to perform security hardening of software in a

systematic way and without the need to have exper-

tise in the security solution domain. At the same time,

it allows the security experts to provide the best solu-

tions to particular security problems with all the de-

tails on how and where to apply them. The exper-

imental results presented together with the security

hardening plans and patterns, which are elaborated

using SHL, explore the efﬁciency and relevance of our

proposition.

REFERENCES

Bodkin, R. (2004). Enterprise security aspects.

http://citeseer.ist.psu.edu/702193.html

(Accessed April 2007).

Bollert, K. (1999). On weaving aspects. In Interna-

tional Workshop on Aspect-Oriented Programming at

ECOOP99.

Cigital Labs (2003). An aspect-oriented security assurance

solution. Technical Report AFRL-IF-RS-TR-2003-

254.

Coady, Y., Kiczales, G., Feeley, M., and Smolyn, G. (2001).

Using aspectc to improve the modularity of path-

speciﬁc customization in operating system code. In

Proceedings of Foundations of software Engineering,

Vienne, Austria.

DeWin, B. (2004). Engineering Application Level Security

through Aspect Oriented Software Development. PhD

thesis, Katholieke Universiteit Leuven.

Huang, M., Wang, C., and Zhang, L. (2004). Toward

a reusable and generic security aspect library. In

AOSD:AOSDSEC 04: AOSD Technology for Applica-

tion level Security.

Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm,

J., and Griswold, W. (2001). Overview of aspectj.

In Proceedings of the 15th European Conference

ECOOP 2001, Budapest, Hungary. Springer Verlag.

Kim, H. (2002). An aosd implementation for c#. Tech-

nical Report TCD-CS2002-55, Department of Com-

puter Science, Trinity College, Dublin.

Mourad, A., Laverdi

ere, M.-A., and Debbabi, M. (2007).

Towards an aspect oriented approach for the secu-

rity hardening of code. In Proceedings of the 21st

IEEE International Conference on Advanced Infor-

mation Networking and Applications, SSNDS Sympo-

sium, (AINA 07), Niagara, ON, Canada. IEEE.

Spinczyk, O., Gal, A., and chroder Preikschat, W. (2002).

Aspectc++: An aspect-oriented extension to c++. In

Proceedings of the 40th International Conference on

Technology of Object-Oriented Languages and Sys-

tems, Sydney, Australia.

SECRYPT 2007 - International Conference on Security and Cryptography

370