Aspectizing Honeytokens to Contain the Insider Threat
Keshnee Padayachee
(University of South Africa, South Africa
padayk@unisa.ac.za)
Abstract: The aim of this paper is to provide a generic implementation strategy for
honeytokens deployed within a database management system that leverages the aspect-oriented
paradigm to contain the insider threat. This approach is tested by developing a proof-of-concept
prototype in an aspect-oriented language, namely AspectJ. The paper also reflects on design
and implementation challenges involved with deploying honeytokens to contain the insider
threat. Consequently aspect orientation is proposed as a means to resolve some of these
challenges.
Keywords: Aspect-oriented programming; Insider threat; Honeypots; Honeytokens; Database
Management Systems
Categories: D.4.6, H.2.0, K.6.5
1
Introduction
The CyberSecurity Watch Survey 2011 indicates that the insider threat (i.e. by users
who have legitimate access) accounts for 21% of all cyber security attacks [1]. The
term ‘insider threat’ refers to any individual who works in an organization and uses
the authority granted to him/her for illegitimate gain (see [2] for a detailed discussion
of the term). Chinchani et al. [3] maintain that there are several challenges associated
with the insider threat. They argue that since insiders have legitimate access, security
administrators usually consider this type of threat as inevitable as insiders are familiar
with security controls and may consequently go undetected. They also suggest that
security tools are typically designed to consider the external threat. According to
Spitzner [4], honeypots may be a way of containing the insider threat, that is, limiting
the damage caused by deflecting the malicious insider to a honeypot or honeytokens.
While in theory the idea has merit, the practical considerations of developing such a
system have not yet been fully explored within a database management system
(DBMS). The first consideration involves the consequences of supplementing a nonfunctional concern to a legacy system, which will involve additional maintenance
costs. Aspect-oriented programming has long been advocated as a suitable
methodology to augment a legacy system with supplemental functionality while
reducing the maintenance overhead [5]. This paper aims to provide an insightful
review of the use of aspect orientation to implement honeytokens as a separable
concern and explores the general design challenges involved in designing
honeytokens.
The insider threat involves more than a disgruntled employee. It may also include
insiders who no longer work for the company but whose system credentials are still
valid, or it may include a system developer who has in-depth knowledge of the system
[6]. Examples of attacks include unauthorized extraction, duplication or exfiltration of
data, tampering with data, deletion of critical assets, etc. [7]. The motivations of
malicious insiders range from espionage, sabotage, terrorism, embezzlement,
extortion, bribery, corruption, ignorance to apathy [8]. In this paper, honeytokens are
advocated as a means of containing the insider threat as far as tampering with data
within a DBMS is concerned.
A honeypot is an information system resource whose value lies in the
unauthorized use of that resource [9]. Using honeypots should confirm insiders’
actions and potentially analyse their motivations and resources [4]. Recent research
has recommended honeypots or decoys to counter the insider threat [10, 11].
According to Spitzner [9], a honeypot is more than just a computer or a physical
resource. In fact, it may be anything from a Windows program to an entire network of
computers. However, in its most rudimentary form, it may be a credit card number, an
Excel spreadsheet, or a password. In this form, a honeypot is called a honeytoken [4].
The power of deploying honeytokens to counter the insider threat lies in their
simplicity. Honeytokens are easily customisable and easily integrated [4]. However,
there are few practical examples that demonstrate how honeytokens may be integrated
or optimized in an extant system. Typically these types of security concerns are not
considered in the original design and implementation of a system. As problems
become evident, systems are constantly upgraded with better protection mechanisms.
Fortunately, aspect-oriented programming facilitates the integration of security
concerns like honeytokens into extant systems.
Aspect orientation has been recommended for several design issues, such as
security [12, 13], persistence [14], exception handling [15] and program
instrumentation [16, 17]. Aspect orientation has the potential to enhance the
implementation of such crosscutting concerns in terms of reusability and extensibility,
thereby improving the robustness and maintainability of a system [18]. The objective
in this paper is to seamlessly augment existing systems with honeytokens, with no
perceptible perturbation to the extant system. It results in an implementation that is
easier to maintain and port to different environments. Aspects improve the separation
of concerns by making it possible to cleanly localize crosscutting design concerns.
They also allow programmers to write, view and edit a crosscutting concern as a
separate entity.
An effort is made in this study to employ aspect-oriented programming to deploy
honeytokens in database management systems so as to contain the insider threat. The
rest of the paper is structured as follows: Section 2 presents related work on the
current mechanisms deployed to undermine the insider threat, while the design
challenges involved in implementing honeytokens in general are elaborated on in
Section 3. Section 4 contains a discussion of the concepts underlying aspect-oriented
programming and design. In Section 5, an aspect-oriented prototype is demonstrated
as a proof of concept. A case-in-point example is also provided in Section 6 to
demonstrate how the prototype may be applied to contain an insider threat. The
implication for practice is described in Section 7 and the paper concludes with Section
8 and possible future research opportunities.
2
Related Work
In terms of dealing with the insider threat, it is often suggested that access controls
may be the key. However, Hunker and Probst [6] caution that access controls may be
too limiting and may affect productivity, while Chinchani et al. [3] assert that
restrictive controls send out a message of distrust between employers and
management. Mechanisms to counter the insider threat include monitoring, detection,
mitigation [10] and deterrence. Monitoring alone is not sufficient to manage the
insider threat. It captures the intent but not the motivation and it is difficult to identify
patterns of misuse [6]. Deterrents alone cannot provide insight into the actual act of
insider threat [19]. A methodical review of technological tools that are available to
circumvent the insider threat may be found in Zeadally et al. [20], while Hunker and
Probst [6] provide a comprehensive review of the tools from all dimensions:
technological, psychological, socio-technical and organizational.
Several researchers promoted profiling to predict future threats (see [7], [2] and
[21]). Moreover honeypots have been deployed in profiling (see [22] and [23]).
Hunker and Probst [6] claim that profiling has its disadvantages, as it assumes that
individuals are not ‘changeable’. A defamatory profile may have serious
consequences if proven to be false. According to Bowen et al. [10], intrusion
detection mechanisms also present a number of challenges. These challenges stem
from false positives through to the effort required to correctly identify anomalous
behaviour. The insider may also have knowledge of how to deactivate an intrusion
detection system [2].
In view of the challenges associated with existing mechanisms to contain the
insider threat, Spitzner [4] highlighted several advantages to using honeypots as an
alternative. Unlike intrusion detection systems, data is only collected when an insider
interacts with a honeypot– they are hence easier to analyse and manage. Further it
reduces false positives as any interaction with a honeypot is guaranteed to be illicit.
Honeypots are adaptable and may vary from a simple honeytoken embedded in a
database management system to an entire network of computers. Honeypots, and
specifically honeytokens, require minimal resources. A limited number of
applications have been developed to use honeytokens to combat the insider threat.
The terminology in this field has not been established either, as some researchers refer
to honeytokens as decoys, honeyfiles or lures.
Yuill et al. [24] considered using honeyfiles to bait hackers, but as this system is
intended for outsiders, it is not appropriate for the insider threat. The challenges
indicated by Yuill et al. [24] are nevertheless still relevant to the current study. They
argued that the implementation of honeyfiles was non-trivial – constructing deceptive
files, file content and system footprints was challenging as the process had to be
consistent and believable. In the context of the insider threat, Bowen et al. [10, 25, 26]
considered using decoy documents. Their work provides a basis for the work done in
this paper. The aforementioned authors developed a comprehensive baiting technique
using decoy documents, which considers the level of sophistication of the end-user
and the search habits of end-users. Their approach considered the properties of
honeytokens, such as believability. This approach was also adopted by Salem and
Stolfo [27] who suggested that profiling be combined with honeytokens in order to
increase the coverage for suspicious activity. However, Bowen et al. [10, 25, 26]
experienced several challenges in this regard (some of these design concerns will be
discussed in more detail in Section 3). Although they were able to test each
component of deployment and the distribution of decoys, they were not able to
integrate all the systems. They were also unable to develop a fully integrated
detection system without a ‘response component’. The current paper therefore
suggests aspect-oriented programming as a possible technique to resolve this problem,
as it allows the seamless augmentation of supplemental functionality as a separable
concern into an extant system.
In this paper, a specific form of honeypot, namely the honeytoken, will be
explored from a database management system perspective. Čenys et al.[28] also
integrated honeytokens into a database management system. They considered
incorporating a honeytoken table, where any interaction with the table indicates
malicious activity. They also experienced challenges with implementing honeytokens,
related the complexities of developing triggers and external procedures for alerting
security personnel, and stated that since a DBMS like Oracle was more adequate in
realising the design, the solution was not generic. The solution provided by Čenys et
al. [28] with respect to creating a honeytoken table does not describe how this table
would be made conspicuous to the insider threat. Honeypots are only of value when
an attacker interacts with them and they capture only actions related to this activity
[4]. Hence this paper considers how honeytokens may be distributed to increase the
odds of a malicious insider discovering them. Also, considering the micro-level of
honeytoken records rather than the macro-level of a honeytoken table, allows the
reconnaissance process to be more fine-grained. The solution offered by Čenys et al.
[28] lies at the database level, whereas the solution presented in this paper is at the
application level. Salem et al. [7] contend that insider attacks take place at application
level where insiders have access to customer records. Integrating honeytokens at the
database level may prove difficult to maintain, as the procedures will be dependent on
the database product. Furthermore, it does not localize all the concerns related to
honeytokens, which results in easier maintenance and optimizations, and this is easily
facilitated by a high-level expressive aspect-oriented language like AspectJ.
According to Bowen et al. [26], honeytoken creation is ‘laborious and manual
processes require large amounts of administrator intervention’ – hence the creation
and deployment of honeytokens must be automated. In the next section, the design
concerns involved in automating honeytokens are explored.
3
Design Concerns for Implementing Honeytokens
As a motivating example, consider a DBMS that maintains the voters’ roll for an
election and aids in planning the forthcoming election for candidates. Suppose a
malicious insider modifies the voters’ roll to ensure that a particular candidate wins.
Inserting honeytokens of fictitious records may help in detecting such an offence. If
the insider unknowingly alters a honeytoken record as well, it is clear that such
insider’s intent is malicious, as this instruction would not have been authorized for a
fictitious person. The issue under consideration in this section is how to generate
honeytokens for such a scenario – which is a non-trivial task.
According to Bowen al. [25], decoys (i.e. honeytokens) must display a number of
properties in order to bait an insider. They must be believable, enticing and
conspicuous; decoys must not be easily identifiable, and a decoy should not hinder,
obstruct or impede normal operation. Gupta et al. [29] recommend that lure data must
remain static until confirmation/elimination of suspicion about a suspected user and
suggest that lure data should be different for each suspected user. In this context, it
implies that honeytokens should not behave unexpectedly and they should be based
on the insider’s motivations. Bowen et al.[25] in turn specify that a decoy should be
detectable (i.e. decoys must generate an alert). However, a honeypot will not be
effective if the insider decides not to select a honeypot as he/she suspects that the
luring honeypot is a trap. Hence, interactions with a honeypot should be detectable to
the system administrator, but not to the malicious insider.
The properties identified by Bowen et al. [25] and Gupta et al. [29] were used to
delineate four basic operations associated with honeytokens. Firstly, there has to be a
means of generating honeytokens that are be believable, enticing, unidentifiable and
specific to each insider. Secondly, honeytoken should function as normal data, so
there has to be a management mechanism to update the honeytokens to allay
suspicion. Thirdly, a honeytoken should be detectable to security administrators,
meaning that there has to be a means of detecting that a honeytoken has been
‘attacked’. Fourthly, a honeytoken has to be conspicuous, so there has to be an
effective means of distributing the honeytokens. To conclude, four components have
been identified for the design: generation, management, detection and distribution.
3.1
Honeytoken Generation
There several design challenges that have to be taken into account when generating
honeytokens. Firstly, honeytokens are designed to mimic real data, hence there has to
be means of distinguishing them from real data. Bowen et al. [10, 25, 26] for example
used embedded beacons that signal when the decoy document is opened. They
concede that beacons may be used to snare the least sophisticated user, as the network
connection of the beacon may be used as distinguishing feature and the beacon may
fail. Bowen et al. [26] also tagged decoys with a cryptographic hash function.
Although they argued that these would be undetectable to the average user, they
conceded that the highly privileged user may be able to distinguish decoys from nondecoys. In order to create true in-distinguishability from decoys and non-decoys,
Bowen et al. [26] tagged both decoys and non-decoys – a technique that may prove to
be cumbersome in a real-world context, since integrating a tag in all records to
identify a few malicious insiders may result in system performance issues.
Furthermore, as discussed earlier, implementing this technique into an extant system
could prove difficult. To address this problem, it may be prudent to store honeytokens
in a separate database management system without compromising the integrity of an
organization’s genuine data. This also supports the ‘separation of concerns’ principle.
The second challenge involves generating honeytokens that are believable and
enticing. White [30] and Bercovitch et al. [31] attempted to resolve this problem by
using real data as a basis. White [30] selected random real data and designed a
honeytoken program to generate honeytokens that had similar attributes by defining
relationships between fields for the honeytoken to appear realistic. He also used
statistical probability. For example, a surname like Smith is ubiquitous; hence several
honeytokens with the surname Smith would be plausible to the insider. Bercovitch et
al. [31] proposed HoneyGen to automatically generate honeytokens for a data
management system. HoneyGen generates honeytokens from a set of genuine data
items by extrapolating rules, data structure, attributes, constraints and logic to
generate the artificial data. Yet, a honeytoken is useless if it is not conspicuous and
hence not selected by a malicious insider. This paper recommends seeding the
database with honeytoken records as described by either White [30] or Bercovitch et
al. [31] and updating the honeytokens to match the queries that the insider executes.
For example, consider an insider who queries a table named VoterRoll table for all
voters who live in ‘Menlyn’, as shown in Figure 1. The honeytoken generator will reengineer a number of honeytoken records to match that query by changing the city to
‘Menlyn’. This ensures that the insider will be enticed by the honeytoken
Figure 1: Query-based Honeytokens
The next issue under consideration involves the distribution of the honeytokens
generated.
3.2
Honeytoken Distribution
As it is not practical to distribute all the honeytokens instantaneously, a mode has to
be associated with each honeytoken record. For instance, some honeytoken records
should be set with a mode of being available for selection and others will be set on
reserve. In case some honeytoken records have been tampered with, they should be
updated as the insider expects otherwise this may arouse the insider’s suspicion.
When some honeytokens have been ‘deleted’ by the insider (of course they are not
actually deleted), they should not appear in subsequent searches and should be
marked with a closed mode. In order to maintain this system, each honeytoken record
should contain an extra field for the mode. It will also be pragmatic for each
honeytoken record to contain a field to associate the insider who has tampered with
that specific honeytoken. These two fields will not be visible to the insider and may
be encrypted. In fact, all updates on the honeytokens will have to be managed by a
separate process.
3.3
Honeytoken Management
The management process addresses a salient property of honeytokens, that is, they
should not hinder, obstruct or impede normal operation and that they must remain
static until confirmation/elimination of suspicion about a suspected insider has been
ratified. Hence the user should be able to update the honeytoken table as was
intended. This keeps the insider from realizing that the honeytokens are mere lures
and maintains the integrity of the reconnaissance process. The honeytoken manager
needs to re-engineer the query to be applicable to the honeytoken, as the insider
assumes it exists within the actual database.
3.4
Honeytoken Detection
This involves detecting when the user is performing some operation related to the
honeytoken record, such as updating or deleting. The purpose of detection is to start a
reconnaissance mission, to alert the security officer and to invoke methods to handle
the management of the update as described in Section 3.3.
While it is sensible to deploy honeytokens into a DBMS, the problem remains
their implementation. It is difficult to evolve an extant system to contain honeytokens.
The questions to be addressed are: How would the system integrate these honeytokens
into the normal operation of the system? How would the system detect when a
honeytoken is being tampered with and how would the system invoke the relevant
processes? This type of upgrade will subject an extant system to numerous regression
errors during maintenance. These processes will have to be invoked at several
instances in the original implementation. Hence, it is sensible to implement the
processes of honeytoken generation, management, detection, and distribution as a
separable concern. This also facilitates development of the honeytoken processes by
an external task team that has no association with the organization, thus ensuring the
security of the system and the anonymity of the honeytokens. The current paper
advocates that the aspect-oriented paradigm be used to resolve this problem.
4
Aspect-oriented Programming and Design
The object-oriented paradigm was found to be inadequate in terms of design and the
implementation of crosscutting concerns, as there is no elegant way of modularising
these crosscutting concerns. Aspect-oriented programming provides explicit language
support for modularising design decisions that crosscut a functionally decomposed
program [32], which allows the developer to maintain the code (crosscutting
functionality) in a modularised form. It is important to note that aspect orientation
maintains all the benefits of the object-oriented paradigm and it should be viewed as
an extension rather than a replacement of object-oriented technologies. Kiczales et al.
[33] emphasise the importance of being able to deal with a concern separately as it is
a way to reflect on it without being hampered by other constraints.
The advantages of aspect-oriented programming are numerous, as indicated by.
[34]:
 Increased modularity
 Less code needs to be written, hence faster development
 Easier maintenance as code is localised
 Easier code reuse as concerns are localised
 Easier understanding as concerns are not tangled with other functionality
 More flexibility
 Reduced inheritance anomalies as the aspects are orthogonal to inheritance
The key concepts of aspect-oriented programming as described next are derived
from Kiczales et al. [35]. Aspect-oriented programming has a construct similar to
classes in object-oriented programming, called an aspect. An aspect consists of
constructs termed pointcuts and advices. The pointcut designators are a set of join
points described by a pointcut expression. Specifically, join points refer to welldefined points in a program's execution such as when a method is called, when an
exception is thrown, etc. An advice defines the functionality to be executed before
(i.e. the before advice) or after (i.e. the after advice) a defined join point, or even
possibly instead of the defined join point (i.e. the around advice). An aspect weaver is
then used to merge extant code (i.e. the base code) and aspects into a final program.
Simply put, aspects seek for specific hooks (i.e. join points) as an extant program
executes and introduces additional code (i.e. the advice) at these execution points.
Aspect-oriented programming has been strongly advocated for security-related
concerns [36]. Aspect orientation is relevant for all the major pillars of security:
authentication, access control, integrity and non-repudiation, as well as for
administration and monitoring disciplines required for effective security [37]. The
Taxonomy of Aspect-Oriented Security derived by Padayachee and Wakaba [38]
demonstrated that the application of aspect-oriented programming in implementing
information security concerns is widespread. Aspect orientation is advocated for
access controls [12], authentication [39], cryptographic controls [40], information
flow controls [41], software tampering detection [42], security kernels [43],
verification [44] and security software engineering [37, 45] in general. Moreover,
Chew et al. [46] advocated the use of aspect orientation to weave honeytokens into
existing web applications. However, they did not provide any further details on how
this would be accomplished.
The abstraction offered by the aspect-oriented paradigm assists in separating the
roles of application developers and security specialists [37]. Aspect-oriented
programming is also flexible in that it supports wildcards, so there is no need for
explicit naming [47]. As security evolves, aspect-oriented programming makes it
easier to ‘swap in and out and evaluate alternative treatment options’ as asserted by
Houmb et al. [48] with respect to verification techniques. This flexibility is especially
vital for information security as threats are constantly evolving. Aspect-orientation
has the potential to reduce the complexity of programs and to improve maintainability
of software due to the additional level of abstraction offered. Moreover, this
abstraction increases the reusability of the concern in another system. The
requirements for a honeytoken deployment would be similar in any DBMS, hence the
implementation strategy presented in the next section is highly extensible and
reusable.
5
Aspectizing Honeytokens
In this section, an implementation strategy for deploying honeytokens is presented
leveraging the aspect-oriented paradigm as a proof-of-concept. The implementation
language of choice is AspectJ, using the Eclipse platform. AspectJ is a seamless
extension to Java − hence Structured Query Language (SQL) instructions can be
issued to manipulate a DBMS.
5.1
The aspect-oriented honeytoken deployment architecture
The aspect-oriented architectural design (Figure 2) is based on the recommendations
presented in Section 3. An overview of the core operations of the aspect is shown in
Listing 1. From the discussion in Section 3 it is clear that the aspect will need to
satisfy four focus areas, namely generation, management, detection and distribution.
Determining where these operations should be invoked depends on specific points in
the execution. As the generation is based on queries, the aspect needs to crosscut all
join points where the user executes a query before activating a module to generate
honeytokens (i.e the Honeytoken Generator). The detection and management process
occurs when an update is performed on a honeytoken. Therefore the aspect crosscuts
before the join point where the insider executes an update. The module that handles
the detection (i.e the Honeytoken Detector) simultaneously triggers an alert (for
instance to a security administrator) and activates the Honeytoken Manager. The
Honey TokenManager module processes the updates on honeytokens to appear to be
executed exactly as the insider predicts, so as not to arouse suspicion. As the
honeytokens need to be interwoven with real data, an alternative method for
distributing real data with honeytokens needs to be invoked. This alternative
distribution method (i.e. the Honeytoken Distributor) crosscuts the current
distribution or output module and therefore operates around the extant distribution
method. The Honeytoken Distributor is concerned with the output of honeytokens
interwoven with real data.
Figure 2: An Overview of an Aspect-Oriented Honeytoken Deployment Architecture
The pointcuts InterceptQuery identifies those execution points where the insider
performs a query and activates the Honeytoken Generator.The InterceptUpdate
identifies those execution points where the insider performs an update and activates
the Honeytoken Detector and Honeytoken Manager modules. The
InterceptDistribution identifies those execution points where the insider performs an
output functionally and activates the Honeytoken Distributor module.
5.2
Proof-of-concept
The implementations described here demonstrate the feasibility of the aspectoriented design in Figure 2. The architectural design described in Figure 2 was
codified into an aspect. The HoneyTokenAspect consists of the core methods and the
pointcuts shown in Figure 2 as well as a few auxiliary methods (listing 1). The core
methods and the pointcuts will be discussed in further detail in the next elaboration
public aspect HoneyTokenAspect{
…
HoneyTokenAspect() throws Exception{…} //constructor
//core methods
public void honeytokenGenerator(…){…}
public boolean honeyTokenDetector(…){…}
public void honeyTokenDistributor(…) {…}
public int honeyTokenManager(…){…}
//pointcuts
pointcut interceptQuery (….): call (* executeQuery(…)) …;
before (…): interceptQuery (query) {…}
pointcut interceptDistribution(…): call (* Distributor(…)) …;
Object around (…): interceptDistribution(….) {…}
pointcut interceptUpdate (…):call (* executeUpdate (…))…;
before (…): interceptUpdate (…) {…}
//Auxillary Methods
public void honeyTokenSeed(…){…}
public String reEngineerSelectionQuery(…){…}
public String reEngineerQuery4HoneyTokenTable(…){…}
void alert(….){…}
}
Listing 1: Outline of the HoneyTokenAspect
For simplicity, it is assumed that there is only one table of real data in the extant
DBMS. The constructor in HoneyTokenAspect is responsible for creating a database
that is nearly identical to the real database, except for the fact that the honeytokens
table (i.e. HoneyTokens) contains two additional fields, mode and userName to hold
the username of an insider who tampers with the record (as discussed in Section 3).
The mode is set to either open, closed, tampered, or reserved. If the status is
tampered, then the userName is set to the insider who tampered with the honeytoken
by performing a delete or an update. Honeytokens will be set to closed mode if the
insider deletes them. The tokens are set to closed as if the insider performs a query on
them – they will not be visible.
5.2.1 Honeytoken Generation
The honeyTokenGenerator method generates the honeytokens for the HoneyTokens
table (listing 2). The pre-defined Java method, getConnection (line 2) is used to
establish a connection to the honeytoken database. The predefined Java method,
createStatement (line 3) is used to create a Statement object which is used for
executing SQL statements on the honeytoken database. The honeyTokenGenerator
method invokes the auxiliary method honeyTokenSeed (line 4) to seed the
HoneyTokens table with numerous representative records. It is beyond the scope of
this paper to discuss the seed technique, as these issues are context dependent. To
create conspicuous honeytokens, the honeytokens are refined using user-based
queries. The method reEngineerSelectionQuery (line 5) re-engineers the selection
query into update query on the HoneyTokens table, thereby ensuring that the insider is
supplied with tokens that match their query. The predefined Java method
executeUpdate executes the SQL statement to update the honeytoken table (line 7).
1 public void honeyTokenGenerator(String query) throws Exception{
2
connection = DriverManager.getConnection(url);
3
statement = connection.createStatement();
4
honeyTokenSeed(connection,statement);
5
String updateQuery = reEngineerSelectionQuery(query);
6
if (updateQuery!=null) {
7
statement.executeUpdate(updateQuery);
8
}
9
connection.close();
10 }
Listing 2: Implementation of method honeyTokenGenerator
The method reEngineerSelectionQuery re-engineers a query such as “SELECT * FROM
VoterRoll where voterCity = 'Menlyn'” into “update HoneyTokens set voterCity =
'Menlyn' WHERE Status = 'OPEN'”. This re-engineered query is used by the generator
to update the HoneyToken table to match the insider’s query. The
reEngineerSelectionQuery method re-engineers the query into an update on the
HoneyTokens table for those tokens where the status is open and voterCity is reset to
‘Menlyn’. Currently, the reEngineerSelectionQuery functionality is limited to specific
types of queries. However, this is an area for further research.
5.2.2 Honeytoken Management
The honeyTokenManager method allows updates on honeytokens to appear to be
executed exactly as the insider presumes, so as not to arouse suspicion (listing 3). The
honeyTokenManager ignores ‘DROP’ or ‘CREATE’ commands, as this may
compromise the integrity of the database. A DROP deletes a table and a CREATE
creates a new table (line 3). The getConnection, and createStatement methods are
applied as described previously (lines 4-5). As the insider assumes that the update is
on real data, the query has to be adapted to update the HoneyTokens table instead. The
reEngineerQuery4HoneyTokenTable method is responsible for re-engineering the
query accordingly (line 6). The pre-defined Java method executeUpdate executes the
updated SQL statement to update the HoneyTokens table (line 7). A count
numberOfUpdates (line 10) is returned to reflect the number of records that were
updated in the HoneyTokens table.
1
public int honeyTokenManager(String query) throws Exception{
2
3
4
5
6
7
8
9
10
11 }
int numberOfUpdates = 0; //indicates the number of records updated
if ((!query.contains("DROP")) && (!query.contains("CREATE"))){
connection = DriverManager.getConnection(url);
statement = connection.createStatement();
String updateQuery = reEngineerQuery4HoneyTokenTable(query);
numberOfUpdates = statement.executeUpdate(updateQuery);
connection.close();
}
return numberOfUpdates;
Listing 3: Implementation of method honeyTokenManager
5.2.3 Honeytoken Detection and Management
The honeyTokenDetector method is self-explanatory (listing 4). It merely invokes the
honeyTokenManager (line 3) and if the honeyTokenManager does perform an
update, this implies that a honeytoken has been tampered with. The
honeyTokenDistributor method simply manages the output by weaving in
honeytokens with real data.
1 public boolean honeyTokenDetector(String query){
2
try {
3
if (honeyTokenManager(query) > 0){
4
return true;
5
}
6
}
7
catch (Exception e) {
8
e.printStackTrace();
9
}
10
return false;
11 }
Listing 4: Implementation of method honeyTokenDetector
The methods discussed previously cannot be injected into the extant code without
accompanying the pointcuts.
5.2.4 The Interceptor Pointcuts
The first pointcut interceptQuery (listing 5) intercepts database queries and invokes
the honeyTokenGenerator to generate tokens similar to the query (line 6). The first
expression !within(HoneyTokenAspect+) is to prevent the aspect from selfreferencing itself (line 2). The second expression call(* executeQuery(String)) is to
identify any call to the predefined Java method executeQuery (line 2). The wildcard
(*) ensures that ALL calls are identified without any explicit naming. The third
expression (i.e. args(query)) is to capture the arguments of the executeQuery method
(line 2). The && operator (i.e. the logical AND) implies that all three expressions
have to be satisfied in order for this pointcut to pick out a join point. Simply put, this
pointcut intercepts any call to the method executeQuery and captures the augments at
the point. The augments are required in the advice (lines 3-15) to process the query.
This advice is executed before the executeQuery method in the extant base code
executes. An executeQuery method is called to perform an SQL query. Typically, an
SQL SELECT statement is executed, where records matching the search condition in
the WHERE clause is returned [49]. The output from a SELECT statement is
normally displayed on the screen; hence it clear that a display type method to
distribute this data should be invoked next. If this occurs, the aspect will need to
weave in tokens with the real data. To prepare for this possibility, a connection to the
honeytoken
database
is
established
(lines
7-8),
the
reEngineerQuery4HoneyTokenTable (line 9) is called to re-engineer the query to be
performed on the honeytoken database and an executeQuery is invoked (line 10) on
the updated query. The results of the query are returned as a ResultSet object, named
rsHoneyToken, which is a table of data representing the database result set of the
query on the honeytokens table. The aspect will retain the rsHoneyToken as a global
variable, should a method to display the data attained from this query be invoked in
the future which is highly probable.
1 pointcut interceptQuery (String query):
2 !within(HoneyTokenAspect+) && call (* executeQuery(String)) && args(query);
3 before (String query) : interceptQuery (query){
4
String updateQuery;
5
try {
6
honeyTokenGenerator(query);
7
connection = DriverManager.getConnection(url);
8
statement = connection.createStatement();
9
updateQuery = reEngineerQuery4HoneyTokenTable(query);
10
rsHoneyToken = statement.executeQuery(updateQuery);
11
}
12
catch (Exception e) {
13
e.printStackTrace();
14
}
15 }
Listing 5: Implementation of the interceptQuery pointcut and the associated advice
The second pointcut interceptDistribution intercepts the method that distributes
(i.e. outputs) genuine data in order to interweave honeytokens with the real data. The
method honeyTokenDistributor merges real data with those honeytokens that are
available, that is, those in open mode. The interceptDistribution pointcut (listing 6) is
composed of three expressions. The significance of the first expression and the third
expression is as discussed previously. The second expression is to identify any call to
a distributor method and the third expression captures the arguments of the
distribution method. In this case the argument would be a resultSet object. If all three
expressions are true, the advice (lines 4-12) advises around the joinpoint and invokes
the honeyTokenDistributor method. The resultSet objects are determined from the
real data set and the honeytoken table, which is rsTrueData and rsHoneyToken
respectively as arguments (line 6). Note that the rsHoneyToken object was captured
by the previous pointcut.
1
2
3
4
5
6
7
8
9
10
11
12
pointcut interceptDistribution(ResultSetrsTrueData):
!within(HoneyTokenAspect+) && call (* Distributor(ResultSet))
&& args (rsTrueData);
Object around (ResultSet rsTrueData): interceptDistribution(rsTrueData) {
try {
honeyTokenDistributor(rsTrueData,rsHoneyToken);
}
catch (Exception e) {
e.printStackTrace();
}
return 0;
}
Listing 6: Implementation of the interceptDistribution pointcut and the associated
advice
The third pointcut interceptUpdate (listing 7) detects updates on honeytokens by
intercepting calls to executeUpdate. The significance of the first and the third
expression is again as discussed previously (line 2). The second expression will
identify any join point where the executeUpdate method is invoked. The method
executeUpdate executes SQL statements to update a table: these include UPDATE
and DELETE instructions [49]. This advice (lines 3-11) is executed before the
executeUpdate method in the base code executes. The method honeyTokenDetector
(line 4) determines whether a query contains a honeytoken; it then invokes the
honeyTokenManager, which will update the HoneyTokens table if the query is related
to a honeytoken. If the HoneyTokens table was successfully updated,
honeyTokenDectector returns true. The alert method is intended for surveillance
purposes (line 6). If the executeUpdate method invoked in the base code does not
contain a honeytoken, the extant code is allowed to proceed as normal.
1
2
3
4
pointcut interceptUpdate (String query) :
!within(HoneyTokenAspect) && call (* executeUpdate (String)) && args(query);
before (String query): interceptUpdate (query) {
if (honeyTokenDetector(query)){
5
6
7
8
9
10
11
}
12 }
try {
alert(query);
}
catch (Exception e)
{e.printStackTrace();
}
Listing 7: Implementation of the interceptUpdate pointcut and the associated advice
The aspect is fairly generic, and the outline provided may be reused on other
extant systems. The interceptDistribution pointcut assumes that there is a method
named Distributor in the base code. This element may, however, be easily adapted to
the naming conventions of the extant system. Also, the honeytoken table may be
exploited at a macro level. Čenys et al. [28] proposed that this may be circumvented
by using typical database auditing options that track user actions at the macro level.
The current prototype demonstrates that processes of honeytoken generation,
detection, distribution and management may be completely abstracted from the extant
code base and treated as a separable concern. To understand the inner workings of the
aspect, a worked example is presented next.
6
A Worked Example
Consider a database that maintains the voters’ roll for an election as described in
Section 3. The database has one table named VoterRoll. The VoterRoll table keeps a
record of each voter with the following attributes: Identity Number, Name, City and
canVote (i.e. whether the voter is eligible to vote). Suppose VoterRoll has the
following subset of records as shown in Table 1:
VoterRoll: Table
Identity Number
7312099981
7505062929
7605062929
7705062929
Name
Paul Smith
David Alan
Cindy Shaw
Mandy Ryan
City
Menlyn
Menlyn
Sunnyside
Menlyn
canVote
True
False
False
False
Table 1: Extract from Table VoterRoll
Consider that if a malicious insider is aware that a certain candidate will win the
election in a particular area, he may decide to tamper with the electorate details in this
area. To avoid suspicion, a sophisticated insider would tamper with several random
voters’ records, rather than to perform a drastic update on all the records. He first
begins by querying the database. Suppose the city of concern is ‘Menlyn’. To avoid
suspicion, he randomly changes (or deletes) the records of voters who are entitled to
vote to a status where they are no longer eligible to vote. To catch out such an insider,
interaction with a honeytoken would be helpful in containing the insider. Assume the
HoneyTokens table has been seeded with the following subset of honeytokens as
shown in Table 2.
HoneyTokens: Table
Identity
Name
Number
7677744455
Alice David
7667389999
Sam Well
City
CanVote
Mode
Sunnyside
Brooklyn
True
False
OPEN
OPEN
Table 2: Extract from Table HoneyTokens
Suppose that the following lines of code are executed in the extant system as
shown in Figure 3.
Figure 3: An extract of code from an extant code base advised by pointcuts
The statement at point A implies that the user would like to select all records
from table VoterRoll where the voterCity is Menlyn. The pointcut interceptQuery
advises all executeQuery statements before they are executed, as shown symbolically
on the left-hand side of the code. The pointcut advises this join point by calling the
honeyTokenGenerator to generate a few tokens to match this query. This results in
the HoneyTokens table being updated to suit the selection so as to give insiders tokens
that are both believable and enticing. The honeyTokenGenerator will select those
honeytokens that are in open mode and change their fields appropriately. Hence the
city attribute in the subset of records in the honeytoken table will be reset to Menlyn.
The pointcut interceptDistribution is based on the premise that there will be a
method to distribute the records in the base code after a query. This pointcut will wrap
around the Distributor method (indicated at point B). The advice of the pointcut
invokes the honeyTokenDistributor method. The Distributor method in the base code
does not execute; instead, the method honeyTokenDistributor is executed. This
displays the honeytokens woven with the real data as shown in Table 3.
Identity Number
7312099981
7505062929
7667389999
7677744455
7705062929
Name
Paul Smith
David Alan
Sam Well
Alice David
Mandy Ryan
City
Menlyn
Menlyn
Menlyn
Menlyn
Menlyn
CanVote
True
False
False
True
False
Table 3: Honeytokens distributed with records from Table VoterRoll
Now suppose the insider attempts to execute the following updates indicated at
points C and D. It is clear that the insider is updating the honeytokens. The statement
at point C attempts to reset the canVote field of a honeytoken record (i.e. Alice
David’s record) to false. The statement (point D) attempts to delete a honeytoken
record (i.e. Sam Well’s record). The interceptUpdate pointcut identifies this join
point as it contains a call to executeUpdate. The advice of interceptUpdate is
executed before this statement is executed. It determines whether any honeytokens are
involved in these updates by calling honeyTokenDetector, which in turn calls
honeyTokenManager. The honeyTokenManager revises the query to a query
applicable to the Honeytokens table. If this query executes successfully, then this
implies that there was a honeytoken involved. In this case, the interceptUpdate
advice invokes the alert method. The statements at points E and F are invoked to
display the updated table. The Distributor method is intercepted by the
interceptDistribution pointcut and the executeQuery is intercepted by interceptQuery
pointcuts. The output will appear as shown in Table 4.
Identity Number
7312099981
7505062929
7605062929
7677744455
Name
Paul Smith
David Alan
Cindy Shaw
Alice David
City
Menlyn
Menlyn
Sunnyside
Menlyn
CanVote
True
False
False
False
7705062929
Mandy Ryan
Menlyn
False
Table 4: Extract of Honeytokens distributed with records from Table VoterRoll
The honeytokenDistributor does not display the record that has been deleted,
though the record still exists in the HoneyTokens table. However, the mode is set to
closed, while the Alice David honeytoken record has been updated to false as the
insider expects. The mode of the record is changed to tampered. Both records will
reflect the username of the insider who updated the records.
The worked example proves that aspect consistently intercepts calls to query,
update or display the database and that it deploys honeytoken processes effectively.
The extant base code does not have to be altered in any way to accommodate the
aspect and it may operate as a standalone without the aspect.
7
Implications for Practice
As shown in previous studies, embedding the supplemental code within the extant
code does not impact the performance over the aspect-oriented version (see [50]).
However, consider attempting to rewrite a legacy system with honeytokens
deployment. The four basic operations of generation, distribution, detection and
management would have been scattered throughout the extant code base. This will
result in numerous updates and regression errors being introduced into the system,
which may have to be offline for a lengthy period during this upgrade. As indicated
earlier, the same technique to lure insiders cannot be used twice. Hence the
honeytokens will have to be upgraded constantly, resulting in more downtime. If the
aspect orientation is used, the system can execute without the honeytokens concern
during an upgrade. During peak periods, the honeytokens may even be turned off. As
honeytokens are treated as a separable concern, this is fairly simple. This approach is
agile and allows for optimisations.
It is important for organizations to weigh the costs of implementing such a system
against the benefit obtained. For smaller companies with less confidential
information, it may be impractical to implement the supplemental functionality
described in this paper, while for larger companies with highly confidential
information (such as banks) such a strategy may prove invaluable.
The derived design may empower administrators to prevent, detect, contain and
possibly counteract the insider threat. Furthermore, the design derived may assist in
reassessing the granularity of access that a malicious insider could possibly be
entrusted with. For example, an individual who is found to be tempted by the luring
honeytoken should not be given access to highly classified information in the future.
8
Conclusions
In this study, aspect-oriented programming was used to seamlessly augment an extant
database management system with the four basic processes associated with
honeytoken deployment. The purpose was to contain and prevent a malicious insider
from effecting further maleficence. It is based on a containment strategy where the
insider is deflected to honeytokens instead of being allowed to attack real data. This
paper provided a comprehensive discussion of the challenges associated with
implementing honeytokens and presented an aspect-oriented design to streamline the
design challenges. To demonstrate the validity of the design, a generic aspect
prototype was implemented and tested. Further research would involve evaluating the
prototype with security specialists. In addition, generating both believable and
enticing honeytokens requires further exploration as honeytokens are only useful if
the insider is attracted to them. This may involve considering the psychological and
criminal aspects of a malicious insider and his/her rational choices. While there may
be several advantages to using honeytokens, there are several disadvantages to using
them as indicated by Spitzner [4]. There is a risk that an insider may use a honeytoken
to damage the integrity of other systems. The current study confirmed that
honeytokens are only of value when an attacker actually interacts with them and they
capture only actions related to this activity. Moreover, there are legal and ethical
challenges such as entrapment, privacy and liability as defined by Spitzner [51].
These issues have to be deliberated upon before an organisation attempts to
implement them.
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
CSO MAGAZINE, USSS, CERT, and Deloitte. (2011, 12 March 2013). 2011
Cybersecurity Watch Survey: Organizations need more skilled cyber professionals to
stay secure. Available: www.cert.org/archive/pdf/CyberSecuritySurvey2011.pdf
E. E. Schultz, "A framework for understanding and predicting insider attacks,"
Computers & Security, vol. 21, pp. 526-531, October 2002.
R. Chinchani, A. Iyer, H. Q. Ngo, and S. Upadhyaya, "Towards a theory of insider
threat assessment," in International Conference on Dependable Systems and
Networks, Yokohama, Japan, 2005, pp. 108-117.
L. Spitzner, "Honeypots: Catching the insider threat," in 19th Annual Computer
Security Applications Conference(ACSAC 2003), Las Vegas, USA, 2003, pp. 170179.
C. R. Laney, J. Van der Linden, and P. Thomas, "Evolution of Aspects for Legacy
System Security," in AOSD workshop on dynamic aspects AOSDSEC'04, Lancaster,
UK, 2004, pp. 1-7.
J. Hunker and C. W. Probst, "Insiders and insider threats-an overview of definitions
and mitigation techniques," Journal of Wireless Mobile Networks, Ubiquitous
Computing, and Dependable Applications, vol. 2, pp. 4-27, March 2011.
M. B. Salem, S. Hershkop, and S. J. Stolfo, "A survey of insider attack detection
research: Beyond the hacker," in Insider Attack and Cyber Security. vol. 39, S. J.
Stolfo, S. M. Bellovin, A. D. Keromytis, S. Hershkop, W. S. Smith, and S. Sinclair,
Eds., ed New York: Springer US, 2008, pp. 69-90.
K. Nance and R. Marty, "Identifying and visualizing the malicious insider threat
using bipartite graphs," in 44th Hawaii International Conference on System Sciences
(HICSS), Koloa, Kauai, Hawaii, USA, 2011, pp. 1-9.
L. Spitzner. (2003, 12 March 2012). Honeytokens: The other honeypot. Available:
http://www.securityfocus.com/infocus/1713
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
B. M. Bowen, M. B. Salem, S. Hershkop, A. D. Keromytis, and S. J. Stolfo,
"Designing host and network sensors to mitigate the insider threat," IEEE Security &
Privacy, vol. 7, pp. 22-29, November-December 2009.
J. White and B. Panda, "Implementing PII honeytokens to mitigate against the threat
of malicious insiders," in IEEE International Conference on Intelligence and Security
Informatics (ISI'09), 2009, p. 233.
B. De Win, W. Joosen, and F. Piessens, "Developing Secure Applications through
Aspect-Oriented Programming," in Aspect-Oriented Software Development, M.
Aksit, S. Clarke, T. Elrad, and R. E. Filman, Eds., ed Boston: Addison-Wesley, 2002,
pp. 633–650.
B. Vanhaute and B. De Win, "AOP, Security and Genericity," in 1st Belgian AOSD
Workshop, Vrije Universiteit Brussel, Brussels, Belgium, 2001, pp. 1-2.
A. Rashid and R. Chitchyan, "Persistence as an aspect," in Proceedings of the 2nd
International Conference on Aspect-Oriented Software Development, Enschede, The
Netherlands, 2003, pp. 120-129.
M. Lippert and C. V. Lopes, "A study on exception detection and handling using
aspect-oriented programming," in Proceedings of the 22nd International Conference
on Software Engineering, Limerick, Ireland, 2000, pp. 418-427.
M. Deters and R. K. Cytron, "Introduction of Program Instrumentation using
aspects," in Proceedings of the OOPSLA 2001 (Workshop on Advanced Separation of
Concerns), Tampa Bay, Florida, 2001.
M. Debusmann and K. Geihs, "Efficient and Transparent Instrumentation of
Application Components Using an Aspect-Oriented Approach," in Self-Managing
Distributed Systems. vol. 2867, ed: Springer, 2003, pp. 227-240.
K. Padayachee and J. H. P. Eloff, "The Next Challenge: Aspect-Oriented
Programming," in Proceedings of the Sixth IASTED International Conference on
Modelling, Simulation and Optimization, Gaborone, Botswana, 2006, pp. 304-307.
R. Willison, "Understanding the perpetration of employee computer crime in the
organisational context," Information and Organization, vol. 16, pp. 304-324, 2006.
S. Zeadally, Y. Byunggu, H. J. Dong, and L. Liang, "Detecting insider threats:
Solutions and trends," Information Security Journal: A Global Perspective, vol. 21,
pp. 183-192, June 2012.
G. B. Magklaras and S. M. Furnell, "Insider threat prediction tool: Evaluating the
probability of IT misuse," Computers & Security, vol. 21, pp. 62-73, 1st Quarter
2002.
M. Kandias, A. Mylonas, N. Virvilis, M. Theoharidou, and D. Gritzalis, "An insider
threat prediction model," in Trust, Privacy and Security in Digital Business. vol.
6264, S. Katsikas, J. Lopez, and M. Soriano, Eds., ed Berlin Heidelberg: Springer
2010, pp. 26-37.
R. McGrew, B. Rayford, and J. R. Vaughn, "Experiences with honeypot systems:
Development, deployment, and analysis," in 39th Annual Hawaii International
Conference on System Sciences (HICSS’06), Maui, Hawaii, USA, 2006, pp. 220a220a.
J. Yuill, M. Zappe, D. Denning, and F. Feer, "Honeyfiles: Deceptive Files for
Intrusion Detection," in Proceedings of the 2004 IEEE Workshop on Information
Assurance, United States Military Academy, West Point, NY, 2004.
B. M. Bowen, M. B. Salem, S. Hershkop, A. D. Keromytis, and S. J. Stolfo, "Baiting
inside attackers using decoy documents," in Security and Privacy in Communication
Networks: 5th International ICST Conference (SecureComm 2009), Athens, Greece,
2009, pp. 51-70.
B. M. Bowen, M. B. Salem, A. D. Keromytis, and S. J. Stolfo, "Monitoring
Technologies for Mitigating Insider Threats," in Insider Threats in Cyber Security, C.
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
W. Probst, J. Hunker, D. Gollmann, and M. Bishop, Eds., ed US: Springer, 2010, pp.
197-217.
M. B. Salem and S. J. Stolfo, "Combining baiting and user search profiling
techniques for masquerade detection," Journal of Wireless Mobile Networks,
Ubiquitous Computing, and Dependable Applications (JoWUA), vol. 3, pp. 13-29,
March 2012.
A. Čenys, D. Rainys, L. Radvilavičius, and N. Goranin, "Implementation of
Honeytoken Module In DBMS Oracle 9ir2 Enterprise Edition for Internal Malicious
Activity Detection," in IEEE Computer Society's TC on Security and Privacy,
Oakland, California, 2005, pp. 1-13.
S. K. Gupta, R. G. Damor, A. Gupta, and V. Goyal, " Luring: A framework to induce
a suspected user into a context honeypot," in IEEE Second International Workshop
on Digital Forensics and Incident Analysis (WDFIA 2007), Samos, 2007, pp. 55-64.
J. White, "Creating Personally Identifiable Honeytokens," in Innovations and
Advances in Computer Sciences and Engineering, 2010, pp. 227-232.
M. Bercovitch, M. Renford, L. Hasson, A. Shabtai, L. Rokach, and Y. Elovici,
"HoneyGen: An automated honeytokens generator," in IEEE International
Conference on Intelligence and Security Informatics (ISI), Beijing, China, 2011, pp.
131-136.
R. J. Walker, E. L. A. Baniassad, and G. C. Murphy, "An initial assessment of aspectoriented programming," in Proceedings of the 21st international conference on
Software Engineering, Los Angeles, California, 1999, pp. 120-130.
G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold, "An
Overview of AspectJ," in ECOOP '01: Proceedings of the 15th European Conference
on Object-Oriented Programming, Budapest, Hungary, 2001, pp. 327-353.
T. M. Elrad, G. Askit, K. Kiczales, H. Lieberherr, and Ossher., "Discussing Aspects
of AAOP," Communications of the ACM, vol. 44, pp. 33-38, November 2001 2001.
G. Kiczales, E. Hillsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold,
"Getting Started with AspectJ," Communications of the ACM, vol. 44, pp. 59-65,
October 2001 2001.
J. Viega and D. Evans, "Separation of concerns for security," in ICSE 2000 Workshop
on Multi-Dimensional Separation of Concerns in Software Engineering, Limerick,
Ireland, 2000, pp. 125-138.
R. Bodkin, "Enterprise Security Aspects," in AOSD'04 International Conference on
Aspect-Oriented Software Development, Lancaster, UK, 2004, pp. 1-12.
K. Padayachee and N. Wakaba, "A Taxonomy of Aspect-Oriented Security," Review
of Business Information Systems (RBIS), vol. 12, pp. 89-102, 4-7 June 2006 2006.
P. Slowikowski and K. Zielinski, "Comparison Study of Aspect-oriented and
Container Managed Security," in Proceedings of the ECOOP workshop on analysis
of Aspect-Oriented Software, Darmstadt, Germany, 2003.
G. Boström, "A case study on estimating the software engineering properties of
implementing Database Encryption as an aspect," in Proceedings of the 3rd
international conference on Aspect-oriented software development, Lancaster, UK,
2004, pp. 1-6.
H. Masuhara and K. Kawauchi, "Dataflow Pointcut in Aspect-Oriented
Programming," in Proceedings of The First Asian Symposium on Programming
Languages and Systems (APLAS'03). vol. 2895, A. Ohori, Ed., ed Beijing, China:
Springer, 2003, pp. 105-121.
P. Falcarin, M. Baldi, and D. Mazzocchi, "Software Tampering Detection using AOP
and mobile code," in 3rd International Conference on Aspect-Oriented Software
Development (AOSD'04), Lancaster, UK, 2004, pp. 1-6.
M. Engel and B. Freisleben, "Supporting autonomic computing functionality via
dynamic operating system kernel aspects," in Proceedings of the 4th international
conference on Aspect-oriented software development,, Chicago, Illinois,, 2005, pp. 51
– 62.
[44]
J. Grundy and G. Ding, "Automatic Validation of Deployed J2EE Components Using
Aspects," in 17th IEEE International Conference on Automated Software
Engineering (ASE'02), Edinburgh, UK, 2002, pp. 47-57.
[45]
P. T. Devanbu and S. Stubblebine, "Software engineering for security: a roadmap," in
Proceedings of the Conference on The Future of Software Engineering, Limerick,
Ireland, 2000, pp. 227-239.
[46]
B. Chew, J. Wang, A. Ma, and J. Bigham, "Anomalous Usage in Web Applications,"
in Networking and Electronic Commerce Research Conference 2008, Lake Garda,
Italy, 2008.
[47]
G. Kiczales, J. Hugunin, M. Kersten, J. Lamping, C. Lopes, and W. G. Griswold,
"Semantics-Based Crosscutting in AspectJ," in Workshop on Multi-Dimensional
Separation of Concerns inSoftware Engineering (ICSE 2000) Limerick, Ireland,
2000, pp. 1-6.
[48]
S. H. Houmb, G. Georg, R. France, and D. Matheson, "Using aspects to manage
security risks in risk-driven development," in 3rd International Workshop on Critical
Systems Development with UML, Lisbon , Portugal
2004, pp. 71-84.
[49]
G. B. Shelly, T. J. Cashman, J. L. Starks, and M. L. Mick, Java Programming
Comprehensive Concepts and Techniques, 3rd ed. Boston, Massachusetts: Thomson
Course Technology, 2006.
[50]
K. Padayachee, "An aspect-oriented approach towards enhancing optimistic access
control with usage control ", Computer Science University of Pretoria (DoctoralThesis) Pretoria, 2009.
[51]
L. Spitzner. (2010, 12 March 2013). Honeypots: Are They Illegal? Available:
http://www.symantec.com/connect/articles/honeypots-are-they-illegal