Insider Threat Security Reference Architecture

Joji Montelibano CERT

jmm137@cert.org

Andrew Moore

CERT apm@cert.org

Abstract The Insider Threat Security Reference

Architecture, ITSRA, provides an enterprise wide solution to insider threat. The architecture consists of four security layers – Business, Information, Data, and Application. Organizations should deploy and enforce controls at each layer in order to address insider attacks. Each layer does not function in isolation or independently of other layers. Rather, the correlation of indicators and application of controls across all four layers forms the crux of this approach. Based on empirical data consisting of over 600 cases of insider crimes, insider attacks proved successful in inflicting damage when an organization failed to implement adequate controls in any of three security principles – authorized access, acceptable use, and continuous monitoring. The ITSRA draws from existing best practices and standards as well as from analysis of these cases to provide actionable guidance for organizations to improve their posture against the insider threat .

1. Introduction

From the time an insider decides to attack to the

point at which damage is done, there exist opportunities for the prevention, detection, and response to the attack. Ideally, the organization will be able to prevent the attack altogether. Failing this, the organization should have adequate controls in place to detect the malicious activity. Finally, the organization should have a proper incident response plan to mitigate the damages resulting from the insider’s actions. The areas above and below the timeline in Figure 1 denote the data the organization should collect. The top portion represents non-technical data, such as human resources (HR) records and physical security logs, while the bottom portion represents technical data, such as database logs and remote access logs

Figure 1: Opportunities for prevention, detection, and response for an insider attack

2012 45th Hawaii International Conference on System Sciences

978-0-7695-4525-7/12 $26.00 © 2012 IEEE

DOI 10.1109/HICSS.2012.327

2412

Correlation of data is the key. Such

come from disparate sources across theand the challenge is the correlation of sinform security staff without overwhelmThe Insider Threat Security Reference A(ITSRA) is designed to address this cha

2. The Components of the ITS Figure 2 shows the four layers of th

The Business Security layer contains hibusiness requirements, such as an organmission. This layer involves the creatioprocedures, and other guidance that detlevel of security to be implemented in oThe Information Security layer describeorganization’s underlying information iThis includes the information network acomponents necessary to operate the orinformation services, such as routers, swservers. This layer also contains the opesystems and software required to managinfrastructure. The Data Security layer information assets considered to be pro

Figure 2. Inside

3. Empirical Foundations and Our research on insider threat is em

based, drawn from rigorous analysis of

h data will enterprise, uch data to

ming them. Architecture allenge.

SRA

he ITSRA. igh-level nization’s

on of policies, termines the other layers. es the infrastructure. and the rganization’s witches, and erating ge the involves prietary to the

organization. Such data can take tdocuments, spreadsheets, or databApplication Security layer addresdevelopment of software, as well of non-operating-system applicatiparticular business mission. A CoSystem (CMS) and a Customer RManagement (CRM) system are eapplications. The Application Sethat these programs adhere to the requirements defined at the Busin

Security is the common threaall levels of a sound enterprise arcarrows on each side of the four lacross-cutting role of security. Thebody of research and products to implement security measures at einstance, secure business processebusiness architecture layer, data pmechanisms secure the data archion. What is missing is a cohesive integrates disparate security contrcomprehensive strategy. The ITSRthis gap, by offering a structured organizations improve their leveladdress the insider threat.

er threat Security Reference Architecture

d Standards

mpirically f over 700

actual cases of malicious insider asuch case illustrates how the ITSRuse. In this case, a foreign currenccover up nearly $700 million in loyear period. He accomplished thissource code for his organization’s

the form of bases. Finally, the sses both internal as the deployment

ions used to fulfill a ontent Management Relationship examples of such curity layer ensures security

ness Security layer. ad running through chitecture. The two

ayers indicate this ere exists a wide help organizations ach layer. For es secure the protection itecture layer, and so instrument that

rols into a single, RA seeks to cover approach to help l of preparedness to

activity [2][6]. One RA can be put to cy trader was able to osses over a five-s by modifying the s trading system.

2413

The trader violated a number of HR polincluding improper treatment of colleagHowever, because of his status as a “stawithin the firm, he did not incur the orgstandard disciplinary actions. In this casconventional standalone detection mechas intrusion detection systems and confmanagement (CM) systems, did not proto detect, let alone prevent, the crime. Rprinciples of the ITSRA been applied, cHR data would have triggered increasedmonitoring of this individual’s online awhen combined with an alert raised by application revealing his changes to souwould have uncovered the insider’s illicand, we believe, would have led to his eand conviction. Needless to say, this ma

Figure 3. The Insider Threat Enterprise Architecture Mo

licies, gues. ar performer” ganization’s se, hanisms, such figuration ove adequate Rather, had correlation of d scrutiny and

activities. This, the CM

urce code, cit activities earlier arrest ay have even

saved the organization itself fromand damaging publicity that follo

The NIST Enterprise Architec[5][9] and the Federal Enterprise [3][5] form the foundations of theITSRA uses these enterprise-levebecause insider threat cannot be fsingle department within an organinsider threat is an enterprise-widbe confronted with an enterprise-wITSRA is such a solution.

Figure 3 captures the approaccreate the ITSRA. The arrows inddissemination of security data gatsources in the enterprise. This infbest informs and prepares the orgdetect, and respond to insider thre

Security Reference Architecture is derived from odel [5][9] and the Federal Enterprise Architecture

m the financial loss wed.

cture Model (EAM) Architecture (FEA)

e ITSRA. The l models as a basis

fully addressed by a nization. That is,

de problem and must wide solution. The

ch that is used to dicate the cross-thered from different formation sharing anization to prevent,

eats.

the NIST e [3][5].

2414

4. Application of the ITSRA

The process of applying the ITSRA

involve refinement and customization amake the corresponding controls applicorganization in question. To this end, wanalyzed an insider threat database to dof insider attack. Analysis of the 700+ cthat each case can be categorized into ofollowing:

• IT Sabotage • Theft of Intellectual Prope• Fraud [2]

IT Sabotage describes an insider’s Information Technology (IT) infrastrucspecific harm at an organization or indiof IP involves the use of IT to steal inteproperty from an organization. This incindustrial espionage involving insiders.includes all cases involving insiders whthe unauthorized modification, additionof data for personal gain or theft.

Figure 4: ITSRA combines with atpattern library to form a customizEnterprise Security Architecture

Based on these three categories, wedifferent models or patterns that represesequence of events in a given attack vecAn organization wishing to apply the ITchoose the relevant crime patterns that pmost visible threat to its operations. Thoffers granular recommendations at eaclayer to address that particular attack ve

A should at each layer to cable to the we created and develop models cases reveals

one of the

erty (IP)

use of cture to direct ividual. Theft ellectual cludes Finally, fraud

ho used IT for n, or deletion

ttack zed

e have created ent the ctor [6][10]. TSRA can present the e ITSRA then

ch security ector. Figure 4

below describes how the ITSRA thigh-level reference architecture tenterprise architecture customizedorganization’s requirements.

The customized Enterprise Sshown above in Figure 4 takes thematrix, which we will describe be

The ITSRA offers granular recombining both operational- and pguidance from the insider threat rbest practices to provide recommeas

• business process guidelin• policy formulation • legal controls • switch configuration, • security information and

management rules • intrusion prevention syst• HR procedures, and • physical security practicMost importantly, it combine

measures into a comprehensive anframework that will better prepareprevent, detect, and respond to maactivity. Table 1 below gives a sapractices available to security praThe ITSRA describes how these bintegrated to comprise a truly enteframework.

ITSRA Layer

Security

Business SABSA [12] NIST SP 800-37Zachman FrameSix Sigma

Information Open Security ACisco SAFE [4] NIST SP 800-53

Data Common Data SOracle Database

Application OWASP CERT Secure CoMicrosoft Appli

Table 1: Sample Security Ar

4.1. The ITSRA Matrix To develop the ITSRA, the a

superimposed the analysis of the idatabase onto the best practices gsecurity architectures listed in TabSpecifically, in reviewing each ar

transitions from a to an instantiated d to fit a specific

ecurity Architecture e form of an ITSRA elow in section 4.1. ecommendations by policy-based

research and existing ended controls such

nes

d event (SIEM)

tem signatures

es es all of these nd holistic e an organization to alicious insider ample listing of best actitioners today. best practices can be erprise-oriented

Architecture

7 work [12]

Architecture

3 [9] Security (CDSA) [1] e Security [11]

oding Standards cation Security [8]

rchitectures

uthors insider threat leaned from the ble 1 above. rchitecture, we

2415

derived commonalities between different approaches and determined how these practices could have been applied to prevent or detect a specific attack. This approach revealed that security architectures are crafted to enforce the following most fundamental principles:

1. Authorized access 2. Acceptable use 3. Continuous monitoring

Applying these three principles to the cases of insider crimes does indeed affirm that each criminal act can be attributed to an organization’s failure to implement one or more of the three security principles above. Consider the case of the currency trader described in section 3 above. Although his access to source code was authorized by the organization, his use of this privilege constituted unacceptable use. Although policies were in place restricting what was deemed acceptable, clearly in this case, there were insufficient means of enforcing such policies. The organization had separation of duties controls such

that the back office verified every trade entered into the system. However, this particular insider social engineered the back office into skipping verification of his trades since he was "the star". In addition, when back office personnel questioned some of his illegal trades, he bullied them into overlooking their suspicions. So the business process controls were there, but not enforced. And because there was no correlation of issues between layers, management did not put the pieces of the puzzle together. In other words, although the organization may have instituted appropriate controls in the Business Security layer, it failed to extend such controls into the information and application layers, which allowed the trader to commit his crime. This reinforces the need to have a cross-cutting architecture that spans the breadth of all security layers. From another perspective, the organization granted authorized access to the trader, defined acceptable use, but failed to apply continuous monitoring strategies to ensure that the trader adhered to these restrictions.

Authorized Access Acceptable Use Continuous

Monitoring Business • Legal Guidance

• Physical Security • Separation of Duties • Need-to-know

• Legal Guidance • Acceptable Use Policy • Change Management

• Legal Guidance • Audits • Assessments • Asset

Prioritization Information • Account

Management • Host authentication

(e.g. MAC address authentication)

• Authentication, Authorization, and Accounting (AAA)

• Multi-factor authentication

• Firewalls • Proxies • IDS/IPS • File read/write restrictions

• SIEM rules • Log correlation • Intrusion

detection • Automated alerts • Incident Response • Antivirus

Data • Account Management

• Role Based Access

• Data Classification • Data Tagging • Least Privilege

• Data Loss Prevention (DLP)

• Intrusion detection

• Database alerts Application • Account

Management • Separation of Duties

• Code Review • Quality Assurance • Email filters • HTTP/HTTPS Proxies

• Audits • Peer review • Configuration and

Change Management

Table 2: The ITSRA Matrix – sample subset of controls per ITSRA layer

2416

Table 2 above shows the ITSRA Mgives a high-level summary of controls by various security architectures, categoand which security principle (authorizeacceptable use, or continuous monitorinaddresses.

5. Correlation Insider cases in our database involv

exploitation of any one or more vulnerain the ITSRA matrix. Current security agenerally emphasize the need for controplace to address the vulnerability in thalayer [1][7]. What is needed is a formato ensure that any countermeasures, whpreventive, detection, or response contrcross vertically across all security layerthe best protection possible.

Figure 5 below shows a snapshot o“Authorized Access” column of the ITSfocusing on select controls per security

Figure 5: Authorized access conspan all layers of the IT

Any controls meant to enforce phy

a closed area should also be extended inrealms of information, data, and applicaInformation controls may involve the exdedicated account for that particular indthe closed area, along with multi-factorauthentication to confirm that individuaMoving down to the data layer, file accfor read-write privileges must be in placthe individual’s need-to-know access. Fan employee dedicated to biological resnot have any read access to internal salaFinally, if the closed area contains any

atrix, which recommended

orized by layer d access, ng) it best

ved the abilities shown architectures ols to be in

at particular alized process hether they be rols, should rs to provide

of the SRA matrix, layer.

ntrols TSRA

ysical access to nto the logical ation controls. xistence of a dividual inside r al’s identity. cess controls ce to restrict

For instance, search should ary records. sensitive

applications, those applications mappropriate safeguards in place toaccess. Using the investment tradonce again, if portions of the codebeen accessible to him, a code masuch as CVS should have been in access.

Just as in Figure 2, the arrowboth directions across the ITSRA true that high-level security requirdefined at the Business layer, anycontrols in any of the bottom layeinform the top layers. This has maespecially with regards to targetedwill be discussed in section 5.1 beonce controls have been implemeto the ITSRA model, that in and odesired end state. Rather, the contcomponent is still in place. So if aviolate a control in the InformatioApplication layers, this informatiocommunicated up to senior leadercan take action and implement higdecisions, such as sanctioning theterminating employment.

5.1. Incident Response and TMonitoring

The preceding discussion despreventive and detective elementsThat is, defining requirements at timplementing relevant controls thITSRA layers will position an orgcountering any insider threats. Thadditional dimension to the ITSRincident response. Specifically, wdoes the ITSRA have in place to ato an insider who has violated anyFor any clear violations or even corganization should define clear, repercussions at the Business levepolicies. These policies should incactions to be taken in the event ofactivity, most common of which asanctions or termination.

There may be cases, howeverorganization may have due cause particular employee’s activities afviolation takes place and even if senforced. For example, many of tdatabase did indeed receive sanctleadership, but these did not detercommitting their crimes. Rather, i

must have o ensure authorized der as an example e should not have anagement system place to restrict his

ws in Figure 5 go stack. While it is

rements should be y data collected from ers should likewise ajor implications d monitoring, which elow. For instance,

ented in a way suited of itself is not the tinuous monitoring an insider were to on, Data, or on should be rship, so that they gh-level business e employee or even

Targeted

scribes the s of the ITSRA. the highest level and

hrough the other ganization well in here is, however, an A, and that is

what mechanisms adequately respond y security controls? criminal acts, the unequivocal el in the form of clude specific f malicious insider are employee

r, where the to monitor a

fter a policy sanctions are the insiders in our ions from r them from in some cases,

2417

insiders were further provoked and angered by these sanctions and were emboldened to carry out their attacks. In these cases, the organization should have a “Targeted Monitoring” policy in place that allows it to selectively monitor both online and at-work activities of any individual if warranted. Of course, such a policy will have to be crafted and approved by legal counsel to ensure that it conforms to local laws, and that it does not violate privacy rights of individuals.

Performing targeted monitoring does not require any additional investment in infrastructure. Rather, with the tools in place that already conform to the ITSRA, the organization will have the ability to fine tune its security devices to observe any person’s activities. Empirical data shows that employing such targeted monitoring may have been able to prevent many insiders from causing damage to their respective companies [2][6][10]. In one case, an insider was the subject of many complaints from fellow workers, who reported inappropriate behavior including workplace intoxication and sexual harassment. Although the human resources department did issue a formal reprimand to the employee, they did not inform the Information Security (IS) department of this individual’s actions. Since the IS department had no cause to monitor this user’s online activities, they failed to detect his planting a logic bomb in the company’s infrastructure which threatened to destroy several years’ worth of critical data. The insider also had access to backup media, which would have prevented the organization from restoring its normal operations in a timely manner.

In several other cases, insiders had previous criminal records for the very crimes which they went on to commit again [2]. In these cases, background checks failed to reveal the insiders’ criminal histories, and even when they did, personnel management did not inform the appropriate security departments to keep “a closer eye” on each person’s activities. What we discovered in such cases was the existence of a figurative barrier of communication between respective departments, and an inordinate reluctance especially on the part of human resources or personnel management to share any negative information about employees with any other party. The ITSRA seeks to break down these barriers where appropriate and necessary, and to enable a free-flow

of communication across all departments within an organization.

6. Sample Instantiation of ITSRA: Theft of Intellectual Property As we mention in Section 3, the insider threat

database contains over 700 cases of insider crimes [2][6]. Of that 700, roughly 90 of these cases deal with the theft of intellectual property (IP). To illustrate the utility of the ITSRA in addressing theft of IP, we consider the problem of an organization attempting to mitigate the risk of loss of its proprietary data. [10]

Our data on theft of IP shows that well over 50% of the insiders who stole information did so within 30 days of resignation [2][10]. Current case trends suggest that organizations regularly fail to detect theft of IP by insiders, and even when theft is detected, organizations find it difficult to attribute the crime to any specific individual. Monitoring employee behavior for suspicious actions worthy of further investigation can be expensive. These costs must be balanced against the risk of losing the organization’s IP. Organizations need to ensure they do not violate employees’ privacy rights and have a valid ownership claim to the IP they wish to protect. Given these challenges facing an organization, we propose a solution described in Section 6.1 below.

6.1. Solution The solution is described in the context of Figure

6 below. Relationships are indicated as labeled arrows between distinct groups (e.g., human resources) or bodies of information (e.g., critical IP). Relationships that exist as part of a sequential ordering are numbered accordingly. The relevant layer of the ITSRA is superimposed upon this diagram in Figure 7 to illustrate how the ITSRA addresses each component of the solution. As this figure illustrates, the principle of acceptable use is the most appropriate for application to theft of IP situations. This is because insiders who committed theft of IP most often had authorized access to the data they removed from the organization.

2418

F

Figure 7: Theft

At the Business Security layer, an oneeds to make sure its employees agreecondition of employment, that the organthe critical IP (see Relationship 1 in Figemployee’s clear and formal acceptanceorganization’s IP ownership helps ensuorganization’s right to ownership will scourt. Consulting with the organizationcounsel will help ensure the organizatiolegal ground. The organization can convto employees through devices such as nagreements, IP ownership policies, and IP ownership in a network-acceptable-u

At the Data Security layer, data owidentify and properly label their IP. The

igure 6: Theft of IP Pattern

of IP Pattern with ITSRA superimposed

organization e, as a nization owns gure 6). The e of the

ure that the stand up in n’s legal on is on firm vey ownership

nondisclosure references to use policy.

wners need to ey need to

communicate the existence and seto IT Management (Relationship to communicate to Human Resouinsiders with access to critical IP Our data shows that scientists, enprogrammers, and salespeople aresteal IP.

At this point, the principles omonitoring described in section 5play. HR needs to track insiders wthe IP so that, when the insider renotify IT Management to monitoronline behavior for signs of suspiIP (Relationship 4).

ensitivity of the IP 2). They also need

urces (HR) the key (Relationship 3). gineers, e especially likely to

of targeted .1 above come into

who have access to esigns, HR can r that insider’s cious exfiltration of

2419

IT Management needs to take actioto the controls implemented in the InforSecurity (monitoring mechanisms, suchand Application Security layers of the Ithis case, email is the application to be particular, Information Security staff shmonitor the insider’s access to critical I30-day window around termination (Rebecause many IP thieves stole informatwindow [6]. Although the organization monitor beyond the 30-day window, resmonitoring to this period may allow theto balance the monitoring costs with thelosing the IP. No matter what level of mused, organizations must ensure that instreated consistently and fairly. Typicallneed to consent to monitoring of their oas a condition of using the organizationconsistent with business and legal requipreviously defined at the Business Secu

Investigation and response activitienecessary if IT Management discovers activity by the insider. During the 30-daseveral items may warrant a detailed inv

• Download of a large volume to removable media/laptop ofile access: Large-volume dowto insider termination may indinsider is preparing to exfiltratinformation suggests that usertrate a large amount of informaor other means first move that network to their workstation. Mdata within enclaves or across exceeds normal traffic patternsthis type of event.

• Email to the organization’s cor the insider’s personal accosiders who steal information thworked systems do so by eitheformation off the network throcorporate account or through wCorporate email accounts can to alert the organization to susfrom mail transaction logs. Foan organization enumerates (bblacklist) suspicious transactiodata transfers to competitors, talerted to any mail traffic genethe outgoing employee, particumessages appear to have attachhave relatively large byte counmany insiders email IP to theirwebmail accounts and then foroutside collaborator. For examsimply open a browser, log int

on concordant rmation h as a SIEM) ITSRA – in monitored. In

hould closely IP during the elationship 5) tion within this may decide to

stricting e organization e risks of monitoring is siders are ly, insiders online actions n’s systems, irements urity layer. es may be suspicious ay window, vestigation: of critical IP

or via remote wnloads close dicate that the te data. Case s who exfil-ation via email data over the

Movement of enclaves that

s may signal

competitors ount: Most in-hrough net-er emailing in-ough a webmail. be configured picious events r example, if ut does not

ons, such as then it can be erated to/from ularly if these hments or nts. Further, r personal rward it to an

mple, a user can to a personal

Gmail account, attach dothem off the network. Oconsider monitoring for webmail domains to mitiviors. [6]

Data owners need to be inforsuspicious access to critical IP anresponse decision-making (Relatiorganization needs to be able to eexfiltration or detect it and confrothe suspicious activity occurs prioHR and the data owners need to fappropriate response as part of thactions (Relationship 7). The orgaconfront the employee with that rexit (termination) interview. If theviolated an agreement regarding Imay wish to pursue legal remediafrom its legal counsel.

Figure 8 below isolates the “Acolumn of the ITSRA matrix. As “Authorized Access” column shosecurity controls for acceptable uslayers of the ITSRA. High-level prequirements should begin at the Blayer, and subsequent controls shoimplemented at all other layers be

Figure 8: ITSRA Acceptablfor Theft

Expanding on these forces, mbehavior to identify suspicious acfurther investigation can be an exThese costs must be balanced agathe loss of the organization’s intelOrganizations need to ensure theyemployee’s rights of privacy and ownership claim to the IP that the

ocuments, and send Organizations need to

uploads to known igate these beha-

rmed of any nd be included in the ionship 6). The either block ont the employee. If or to termination, formulate an e termination anization can then response during the e insider has IP, the organization ation, with advice

Acceptable Use” with the wn in Figure 5, se should span all policies and Business Security ould be elow.

e Use Controls t of IP

monitoring employee ctions worthy of xpensive proposition. ainst the risk due to llectual property. y do not violate have a valid

ey wish to protect

2420

7. Conclusion

The immediate goal of the ITSRA is to provide an end-to-end architecture that provides actionable guidance to minimize the threat of malicious insider actions. It is intended to support

• senior leadership • system implementers • network architects • SOC operators • HR managers • security guards • enterprise architects

The ITSRA is a dynamic model that will adapt to

the continuously changing climate of business processes, information technologies, and security practices.

Insider threat is a serious problem, and our research has demonstrated the urgent need for a documented, comprehensive, standard Insider Threat Security Reference Architecture. Therefore, we have designed a reference architecture based on current state of hardware, operating systems, and networking infrastructures. However, the ITSRA is intended to serve another key function as well: though the ITSRA will be designed to solve a current problem using current technologies, it will also form the foundation for the next generation of operating systems, applications, and information infrastructure. It is critical that developers of next-generation technologies consider insider threat mitigation requirements at the initial design stages. Next generation hardware, operating systems, and networking infrastructures should have the ITSRA designed into the individual components. Otherwise, we will find ourselves in the same position down the road as we are in now: attempting to solve the insider threat problem with a collection of policies, processes, and applications bolted onto available components rather than built into the infrastructure. The ITSRA will provide a common foundation for those next generation engineers to provide a more effective solution in the future.

.

10. References

[1] Blackwell, C., “A Security Architecture to Protect against the Insider Threat from Damage, Fraud, and Theft,” CSIIRW ’09, Proceedings of the 5th Annual Workshop on Cyber Security and Information Research, ACM, New York, NY, USA 2009.

[2] Cappelli, D., Moore, A., Trzeciak, R., and Shimeall, T., Common Sense Guide to Prevention and Detection of Insider Threats, 3rd Edition – Version 3.1, Software Engineering Institute, Carnegie Mellon University, 2009.

[3] Chief Information Officer Council, “A Practical Guide to Federal Enterprise Architecture,” Federal Architecture Working Group (FAWG), February 2001.

[4] Chung, J., Pueblas, M., Nadimi, A., Hamilton, D., Farrington, S., “Cisco SAFE Reference Guide: Cisco Validated Design”, Cisco Systems, Inc., San Jose, CA, USA 2010.

[5] Executive Office of the President of the United States, “FEA Consolidated Reference Model Document Version 2.3,” October 2007.

[6] Hanley, M. “Deriving Technical Controls and Indicators of Insider Attack from Socio-Technical Models and Data (CMU/SEI-2011-TN-003), Software Engineering Institute, Carnegie Mellon University, 2011.

[7] Jabbour, G., and Menascé, D., “The Insider Threat Security Architecture: A framework for an integrated, inseparable, and uninterrupted self-protection mechanism,” 2009 International Conference on Computational Science and Engineering, Vancouver, Canada 2009.

[8] Microsoft Corporation, “Planning and architecture for SharePoint Server 2010”, http://technet.microsoft.com/en-us/library/cc261834.aspx, May 12, 2010.

[9] National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Recommended Security Controls for Federal Information Systems and Organizations, Revision 3, August 2009.

[10] Moore, A., Cappelli, D., Caron, T., Shaw, E., and Trzeciak, R., “Insider Theft of Intellectual Property for Business Advantage: A Preliminary Model” 1-1. Proceedings of the 1st International Workshop on Managing Insider Security Threats (MIST 2009), Purdue University, West Lafayette, IN, June 2009.

[11] Oracle Corporation, “Oracle Database Security Overview,” http://www.oracle.com/technetwork/database/maximum-security-architecture-094265.html, 2011.

[12] The SABSA Institute, “Sherwood Applied Business Security Architecture”, http://www.sabsa-institute.org, 2011.

2421