106-Toward an Automated Attack Model for Red Teams
-
Upload
chandra-bdr -
Category
Documents
-
view
223 -
download
0
Transcript of 106-Toward an Automated Attack Model for Red Teams
8/2/2019 106-Toward an Automated Attack Model for Red Teams
http://slidepdf.com/reader/full/106-toward-an-automated-attack-model-for-red-teams 1/8
Attack Models
The world’s economic and political environment
depends on the Internet to operate effectively
and safely. This situation demands that we take a
proactive and offensive approach to understand-
ing how adversaries can use computers to inflict damage.
Because our adversaries have sophisticated skills and ac-
cess to advanced technologies, we can’t afford the luxuryof playing defense when we consider the extent of the
damage they can inflict via the Internet. We must under-
stand how attackers can exploit our vulnerabilities and
how we can use defensive methods to minimize our r isks.
We believe that red teaming , which is the practice of
attacking systems to better understand how to defend
them, is a necessary process. It helps us find software vul-
nerabilities to effectively defend against attacks originat-
ing from both script kiddies and well-motivated,
for-hire hackers.
Red teaming is necessary to understand how our ad-
versaries can exploit insecurities in our systems and
cause grave harm. We can contribute to red teams’ suc-
cess by understanding the challenges they face and de-
veloping new or improved models to address these
issues. We believe an automated attack method that’s
simple, flexible, reusable, and scalable is best suited to
aiding red-team efforts.
We’re concerned not only about the impact on tar-
geted computers but also the impact on our economic
and social systems. (See Sarah Gordon’s study on cybert-
errorism for more specifics.1) We live in an era in which
terrorism is becoming a daily event; it’s only a matter of
time before the acts of violence we’ve already seen
progress toward more complex and globally interwoven
cyberattacks.2
Attackers—
Have tools,
will use By relying so heavily on the Internet, we expose our
weaknesses to attack by remote adversaries. Re-
searchers have found that “wide-spread vulnerabilitiesin Internet hosts can be exploited quickly and dramat-
ically” by Internet worms.2 Because they exploit secu-
rity flaws in widely used services across the Internet, “it
is reasonable for an attacker to gain control of a million
Internet hosts, or perhaps even ten million.”3 For in-
stance, in January 2003, the Slammer worm penetrated
an Ohio nuclear plant network and disabled the safety
monitoring system for nearly five hours (www.security
focus.com/news/6767).
According to the Cooperative Association for Internet
Data Analysis (CAIDA),4 the first widely propagated In-
ternet worm with a malicious payload, has already at-
tacked a security product. On 19 March 2004, the Witty
Worm took advantage of a buffer overflow vulnerability
found in Internet Security System’s RealSecure/Black Ice
security firewall application and infected as many as
30,000 computers. The worm deleted a randomly chosen
section of a hard drive to render its machine unusable.
Some theorize that between 100 and 160 computers were
simultaneously activated, indicating either the use of a
preprogrammed hit list or a timed release of the worm on
previously hacked machines.4 Based on this attack’s so-
phistication, we can reasonably expect to see increasing
stealth and flexibility in Internet worms.
In addition to remote adversaries and cyberattacks,
we should also be mindful of wireless technology’s in-
Toward an AutomatedAttack Model for Red Teams
18 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/05/$20.00 © 2005 IEEE ■ IEEE SECURITY & PRIVACY
To better understand system vulnerabilities, proactive
security services use red teams that simulate malicious
attacks. The authors contend that an attack model with UML-
based use cases, sequence and state chart diagrams, and
XML would best help red teams achieve attack automation.
HELAYNE T.
RAY
SI Government Solutions
RAGHUNATHVEMURI
Motorola
HARIPRASAD R.
K ANTUBHUKTA
Progressive Insurance
8/2/2019 106-Toward an Automated Attack Model for Red Teams
http://slidepdf.com/reader/full/106-toward-an-automated-attack-model-for-red-teams 2/8
Attack Models
herent insecurity. One common example of this is war
driving , in which would-be hackers equipped withwireless gear drive around looking for unsecured wire-
less networks in order to gain illicit access. Hackers can
easily bypass the security features in the IEEE 802.11b
wireless network protocol, which has documented se-
curity flaws. Published hacking tools, such as NetStum-
bler (www.netStumbler.com), AirSnort (http://
airsnort.shnoo.com), and Ethereal (www.ethereal.
com), which can all be downloaded from the Internet,
let hackers crack wireless encryption protocols within
minutes to spy on networks.
Because tools such as these are readily available to
hackers, we must use them to attack our own systems in
order to not only find the exploitable areas but secure
them before the adversaries strike. One argument is that
attacking our own systems isn’t a good idea because it
could let hackers imitate the results, but this type of mate-
rial is already published on various Web sites. For exam-
ple, a manual on how to access the UK’s traffic light
system is available on the Phrack Web site (www.phrack.
org/phrack/60/p60-0x0e.txt). With this information,
hackers could compromise the traffic system to stage a
major transportation gridlock, prohibiting emergency
vehicles from traveling to the scene of a terrorist attack.
As long as the hackers gain information on how our sys-
tems work, they’ll be able to create cyberattacks and pub-
lish them on the Web.
Approach to secure systems
As early as 1993, system security was taking a strategicturn. Rather than merely saying that a problem existed,
companies began looking through the eyes of potential
intruders to show why the problem was a vulnerability.
Dan Farmer and Wietse Venema, authors of the Secu-
rity Analysis Tool for Auditing Networks (SATAN),5
have stated that, “By showing what intruders can do to
gain access to a remote site, we are trying to help system
administrators to make informed decisions on how to
secure their site…or not.” Making informed decisions
is more important than ever before. We need to help red
teams find vulnerabilities by giving them the right tools,
models, and authority.
Many security companies are now offering red-team
services. (See the “Red teams in action” sidebar for spe-
cific examples of red-team success stories.) As expected,
there are various methodologies, but to date, the industry
hasn’t accepted any one method as the de facto standard.
Arguably, an effort’s scope or specific purpose determines
its best-suited methodology, so we must understand the
current issues facing red-team efforts and develop a
model to mitigate them.
We’ve identified the current models that red teams
use to identify attack opportunities and coupled that in-
formation with issues facing red teams. With that, we de-
signed a new model to take them one step closer to
achieving their goals.
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 19
Red teams in action
The US government has used red-team strategies to determine
the level of security in several areas. The following eventsdemonstrate the effectiveness of red-team work:
• In 2002, US investigators found evidence in Internet browser path
logs that al Qaeda operators had visited sites that offer software and
programming instructions for the digital switches that run power,
water, transportation, and communications grids. The technical in-
formation required to penetrate these systems is readily discussed in
the affected industries’ public forums. However, most of these de-
vices are now being connected to the Internet—some of them, ac-
cording to classified red-team intrusion exercises, in ways that their
owners don’t suspect.1
• Red teams from the General Accounting Office, Congress’ inves-tigative arm, focused on penetrating the computer networks of nu-
merous federal agencies. “Every single one demonstrated pervasive
weaknesses,” said House Commerce Committee Chairman Billy
Tauzin, R-La.2
• In October 2003, the US Homeland Security Department deployed
the first simulation of physical and computer terrorist attacks, on
computer, banking, and utility systems. Dubbed Livewire, the simu-
lation exposed problems, which experts inside the government and
the Institute for Security Technology Studies at Dartmouth College
are formally evaluating.3
The Department of Homeland Security continues to fund re-
search and development activities regarding homeland security
threats, vulnerabilities, and risks (www.dhs.gov/dhspublic/). Se-
curity companies, both in the commercial and government arenas,
now offer red-team services and training (www.sandia.gov, www.
sigovs.com). Red-teaming activities will continue to evolve
and become standard practice in defense of attacks on our infor-
mation systems.
References
1. B. Gellman, “Cyber-Attacks by Al Qaeda Feared,” Washington Post , 27 Jun.2002, p. A01; www.washingtonpost.com/ac2/wp-dyn/A50765-2002Jun
26?language=printer.
2. T. Eckert, “They Probe Targets, Potential Methods,”Union-Tribune , 20 Aug.
2002; www.signonsandiego.com/news/nation/terror/20020820-9999
_1n20redteam.html.
3. T. Bridis, “Government Simulates National Cyber Attack,” CRN, 25 Nov.
2003; www.crn.com/sections/BreakingNews/dailyarchives.asp?Article
ID=463.
8/2/2019 106-Toward an Automated Attack Model for Red Teams
http://slidepdf.com/reader/full/106-toward-an-automated-attack-model-for-red-teams 3/8
8/2/2019 106-Toward an Automated Attack Model for Red Teams
http://slidepdf.com/reader/full/106-toward-an-automated-attack-model-for-red-teams 4/8
Attack Models
commonly use these documentation methods in design-
ing and writing software. We’ve designed our model to
bring the red-team effort one step closer to automation by
supplying the information in a format that’s more suitable
to writing software. For example, we can parse XML and
generate code with tools like XMLSPY (see Figure 1).
Our red-team attack model presents attack and de-
fense information in such a way that complex material
becomes understandable, which helps the red team
achieve its goals. The red-team attack model is designed
to provide a framework for a red-team member to re-
search a specific attack and gain information on
• the attack’s functionality,
• the attacker’s profile, and
• the best way to defend the system from this attack.
The red-team attack model doesn’t start with the applica-
tion and dissect it for threats, as previous work has done;6
it is designed to model an individual attack. Once the red
team identifies potential attack threats to model (or un-
derstand more fully), it can use the red-team attack model
we designed to model each attack separately.
To help illustrate our approach, let’s look at a cross-site
scripting (XSS) attack on the Super Secure Bank (a ficti-
tious financial institution). In this example attack, the
attacker emails a victim (Bob) a graphic link that dis-
plays, “Free credit report from SSB!” When Bob clicks
on the graphic, which contains malicious code, he’s di-
rected to SSB’s server, which returns both the credit ap-
plication page and the malicious script to his browser.
When Bob completes and submits the application in-
formation, the malicious script collects the confidential
user information and sends it to the attacker. Mean-
while, the information is also sent to SSB, so neither
Bob nor the bank realizes that the attack has compro-
mised confidential information. We will refer back to
this example attack throughout our article to demon-
strate our model in action.
Our attack model, when fully documented, is too
large to include in its entirety in this article, so we note
within the red-team attack model the incomplete areas.
The full model is available for review at http://my.
fit.edu/~hkantubh/AttackModeling/.
Attack objective and strategy Our model begins with an attack assessment—what is
the objective and strategy? Clearly stating the objective
focuses the red team’s efforts to achieve a specific goal.
Documenting the strategy lets them determine an at-
tack’s intent—short or long term, manual or automated,
or variations therein—and also clearly explains how the
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 21
Figure 1. The XMLSPY tool parses XML and generates code.
WebDeveloper
Defense
Type: webDevType
FilterCode
Type: FilterCodeType
WebUser
Type: webUserType
InputValidation
webDevType
webUserType
Type: InputValidationType
Disable
Type: String
Validate
InputValidationType
Type: StringPublic class defense
...... Validate validate;Reject reject;Replace replace;Disable disable;......Public void
ValidateInputTag(Validate n){......}RejectScriptTag(Reject n){......}
......
Encode
Type: EncodeType
Reject
FilterCodeType
Type: String
Replace
EncodeType
Type: String
XML Class file
8/2/2019 106-Toward an Automated Attack Model for Red Teams
http://slidepdf.com/reader/full/106-toward-an-automated-attack-model-for-red-teams 5/8
Attack Models
22 IEEE SECURITY & PRIVACY ■ JULY/AUGUST 2005
attack proceeds through its execution. This step in the
model includes a text description and a UML use case
for analysis.
Hence, we can begin by identifying the example XSS
attack’s objective: to run a malicious script in Bob’s
browser using his privileges. The script is designed to re-
turn Bob’s confidential credit information to the attacker,
who then has various options on how to proceed. For ex-
ample, the attacker can use his credit card number to pur-
chase goods online.The attacker’s strategy for obtaining this information
is to send a specially crafted email message to Bob that
contains a hyperlink along with malicious script. The at-
tacker uses social-engineering techniques—playing on
Bob’s desire to receive a free credit report—to make the
victim click on a link containing malicious code. Here’s
the format of the malicious link:
<A HREF=http://SSB.com/creditreport/
registration.cgi?clientprofile=
<SCRIPT>malicious code
</SCRIPT>>Click here</A>
When an unsuspecting user clicks on this link, the URL
is sent to “SSB.com/creditreport/registration.cgi”, in-
cluding the malicious code. If the server hosting
SSB.com sends a credit application page back to the user,
the malicious code will also be returned and executed on
the victim’s Web browser. Figure 2 shows a use case dia-
gram that depicts the overall strategy.
Required attacker resources and knowledge The model continues with information about the at-
tacker. What resources are required in order to execute
this attack? We must identify the specific software pro-
grams, tools, hardware, and financial resources that the at-
tacker will need. What knowledge and skills must the at-
tacker possess to succeed? This information satisfies
multiple goals. First, it lets the red team conduct the attack
through the attacker’s eyes to gain additional insights.These insights will help the red team later in advising the
company on how to better secure the vulnerable areas.
Second, the red team can assign values to this information,
store them in a database, and use them later to compare at-
tacks using specific criteria. For example, the values as-
signed to the attacker’s resources can help us determine
how easy it is to execute one attack compared to another.
This step in the model includes text description for clarity
and restates the information in an XML format.
For the example XSS attack, the attacker needs access
to the Internet and the software necessary to edit and cre-
ate the malicious code. Many code snippets are publiclyavailable, which eases the attacker’s job.
To execute such an attack, the attacker needs knowl-
edge of Web browsers and HTML. Specifically, the at-
tacker must know how to use HTML tags such as
script, applet, object, and embed. In addition,
the attacker must be familiar with client–server commu-
nication. Specifically, HTTP gives the conventions that
guide communication between a client system and a
server over the Internet. Attackers must also know how
to code in scripting languages such as Perl or interface
code such as common gateway interface (CGI) to embed
malicious script in a URL. Lastly, the attacker should un-derstand the authentication schemes and concepts un-
derlying Web applications, apart from having knowledge
about implementing cookies and session IDs.
This sample XML file contains some of the required
attacker knowledge:
<?XML VERSION=”1.0” STANDALONE=”YES”?>
<!DOCTYPE KNOWLEDGE [
<!ELEMENT KNOWLEDGE (PROGRAMMING+) >
<!ELEMENT PROGRAMMING (LANGUAGE) >
<!ATTLIST LANGUAGE
NAME ID #REQUIRED >
<!ELEMENT LANGUAGE (CONCEPT+) >
<!ELEMENT CONCEPT (#PCDATA) >
]>
<KNOWLEDGE>
<PROGRAMMING>
<LANGUAGE NAME=”HTML”>
<CONCEPT> TAGS
</CONCEPT>
</LANGUAGE>
</PROGRAMMING>
<PROGRAMMING>
<LANGUAGE NAME=” ANY CLIENT-
SERVER PROGRAMMING
Figure 2. A use case diagram for the example cross-site scripting
(XSS) attack on the Super Secure Bank (SSB).
the malicious link
UnderstandSSB.com's HTML andcreate malicious script
Cross-site scripting on SSB.com
Click onthe malicious link
Attacker
Victim
8/2/2019 106-Toward an Automated Attack Model for Red Teams
http://slidepdf.com/reader/full/106-toward-an-automated-attack-model-for-red-teams 6/8
Attack Models
LANGUAGE “ >
.
.
.
.
</LANGUAGE>
</PROGRAMMING>
</KNOWLEDGE>
Once entered into a database, the required attacker knowl-
edge can be queried for specific “what if” scenario analysis.
Required attacker functionality Next, we model the attacker’s functionality. How does
the attack progress, and what events along the way influ-ence its course? What decisions must be made by the at-
tacker and at which points in the process? For example, as
the attack proceeds, will the attacker decide to abandon
the attack, and if so, what influenced that decision? This
information will let the red team provide a better defense
at the right time.
We use four common software engineering methods
to describe the attacker’s functionality. Pseudocode de-
scribes the attacker’s steps and decision points. State-chart
diagrams clearly portray the attack’s different cases and de-
cision paths. Sequence diagrams portray the progression
and timing between the attacker, victims, and other perti-nent resources. Finally, we restate the information in XML
format to facilitate automation by system developers.
Figure 3 displays some sample pseudocode that de-
scribes the steps and decisions the attacker must make
during the example XSS attack.
TheIfparts of the pseudocode in Figure 3 are some of
the key points at which an attacker might make a decision.
For instance, if the second If in the pseudocode were to
evaluate to false, the attacker would know that XSS attacks
weren’t possible for that Web site and that it would be best
to look for another, more vulnerable Web site.
Figures 4 and 5 show a UML-based state-chart and se-
quence diagrams, respectively, for attacker functionality.
Red teams can use such diagrams as design input for au-
tomated systems.
We could use custom-defined tags to describe the at-
tacker’s functionality in an XML file. Here’s a partial sam-
ple of such a file:
<?xml version=”1.0” standalone=”yes”?>
<!DOCTYPE FUNCTIONALITY [
<!ELEMENT FUNCTIONALITY (ATTACKER+) >
<!ELEMENT ATTACKER (#PCDATA) >
]>
<FUNCTIONALITY.
<ATTACKER>
SEARCH FOR A WEBSITE THAT IS VUL-
NERABLE TO CROSS-SITE SCRIPTING
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 23
Search for financial institution Web site with pages that
return client supplied data
AND
IF found (like in our XSS attack example)
Input a URL into the browser that is a combination of
the URL for SSB and some script (for example, like
one that pops up an alert dialog)
AND
IF the script gets executed in the browser
Understand the HTML source code of SSB’s Web site
and look for parameter(s) that get transmitted as
part of the URL
AND
Create malicious script
AND
Construct a URL containing the malicious script
at the appropriate place (typically the maliciousscript replaces the value provided to a parameter
in the URL)
AND
Get the victim to use the crafted URL by emailing
the victim the URL
Else
Search for another Web site with pages that
return client supplied data
Else
Attack cannot proceed
Figure 3. Pseudocode describing the attacker’s steps and decisions in
a XSS attack.
Figure 4. UML-based state-chart diagram for attacker functionality.
Test if site accepts
scripts as input
Search for
vulnerable site
Start
Stop
Understand
site’s HTML
Create URL with
malicious script
Collectsensitive information
Site found
Done
Victim clicks andscript executesEmail the
link and wait
Done
Successful
8/2/2019 106-Toward an Automated Attack Model for Red Teams
http://slidepdf.com/reader/full/106-toward-an-automated-attack-model-for-red-teams 7/8
Attack Models
ATTACK
<AND>
CONSTRUCT A URL CONTAINING
MALICIOUS CODE
<AND>
POST A MESSAGE EMBEDDING
THE CRAFTED URL IN A DIS-
CUSSION FORUM TO MAKE THE
VICTIM READ
THE MESSAGE AND FOLLOW THE
URL
<OR>
E-MAIL THE CRAFTED URL PER-
SUADING THE VICTIM TO FOL-
LOW THE MALICIOUS LINK
</OR>
</AND>
</AND>
</ATTACKER>
The red team has now collected enough information
to view an attack from the attacker’s perspective. Now it’s
time to qualify the attack’s results.
Evaluating attack success The next step in our model is to describe the attack-
success evaluation criteria. What criteria determine
whether the attack as a whole was successful? For multi-
stage attacks, this includes the rules or tests used to make
the decision that each element within the attack was
successful. Again, we provide this information in both
text and XML format. Defining the success-evaluation
criteria using rules and tests brings us one step closer to
automation.
The criteria for the XSS example attack are twofold:
• At the end of the attack, the attacker has access to Bob’s
credit information.
• The attacker can use Bob’s credit information—for ex-
ample, to make online purchases with his credit card.
(For sake of brevity, we have not included the XML repre-
sentation in this article. The full representation is available
at http://my.fit.edu/~hkantubh/AttackModeling/.)
Defense strategy The final step is to define the defense strategy. No attack
modeling technique is complete without addressing the
defenses to use once the red team identifies the system
vulnerabilities. At this point, we understand the attack’s
purpose and how it’s performed. We also can implement
the attack from the attacker’s perspective using the docu-
mented knowledge and information. As in other steps, weemploy both a text and XML format to define the defense
strategy. Due to space limitations, we can include only a
sample set of strategies here.
Because the base of the XSS attack is a script, as far as
Web users are concerned, a good defense would be to
disable the scripting languages in their browsers. The
bank’s Web developers, on the other hand, might use
input validation (validating user input for malicious char-
acters), filtering (validating script tags before processing),
and encoding (replacing script tags with special codes) to
anticipate and prevent such attacks.
The following is a sample XML-based description of defense strategies.
<?XML VERSION=”1.0” STANDALONE=”YES”?>
<!DOCTYPE DEFENSE [
<!ELEMENT DEFENSE (WEBDEVELOPERS |
WEBUSERS) +>
<!ELEMENT WEBDEVELOPERS (INPUTVALIDA-
TION | FILTERCODE | ENCODE) >
<!ELEMENT INPUTVALIDATION (VALIDATE)+>
<!ELEMENT VALIDATE (#PCDATA) >
<!ELEMENT FILTERCODE (REJECT)+ >
<!ELEMENT REJECT (#PCDATA) >
<!ELEMENT ENCODE (REPLACE)+ >
<!ELEMENT REPLACE (#PCDATA)>
<!ELEMENT WEBUSERS (DISABLE)>
<!ELEMENT DISABLE (#PCDATA) >
]>
<DEFENSE>
<WEBDEVELOPERS>
<INPUTVALIDATION>
<VALIDATE> MALICIOUS
CHARACTERS </VALIDATE>
</INPUTVALIDATION>
<FILTERCODE>
24 IEEE SECURITY & PRIVACY ■ JULY/AUGUST 2005
Figure 5. A UML-based sequence diagram for attacker functionality.
Attacker
Email to user with link
Script execution(sends sensitive
information to attacker)
Click by victimtakes to Web site
Malicious script returns
Victim
SSB.com's apply for credit report page
8/2/2019 106-Toward an Automated Attack Model for Red Teams
http://slidepdf.com/reader/full/106-toward-an-automated-attack-model-for-red-teams 8/8
Attack Models
<REJECT> SCRIPT TAGS </REJECT>
<REJECT> FORM TAGS </REJECT>
<REJECT> OBJECT TAGS </REJECT>
<REJECT> APPLET TAGS </REJECT>
</FILTERCODE>
<ENCODE>
<REPLACE> SCRIPT TAGS
</REPLACE>
<REPLACE> FORM TAGS </REPLACE>
<REPLACE> OBJECT TAGS
</REPLACE>
<REPLACE> APPLET TAGS
</REPLACE>
</ENCODE>
</WEBDEVELOPERS>
<WEBUSERS>
<DISABLE> SCRIPTING </DISABLE>
</WEBUSERS>
</DEFENSE>
Our objective has been to introduce an attack model that
guides red teams in documenting security attacks in a
reusable format, and lets system developers more easily au-
tomate the attack. Modeling methods include XML,
UML, pseudocode, state-chart and sequence diagrams, and
text. We have used this attack model on several vulnerabili-ties; the results documentation is available at http://
my.fit.edu/~hkantubh/AttackModeling/.
Future work will entail taking the attack documenta-
tion developed from using this model and writing auto-
mated attacks. We will conduct an experiment to
compare the efforts of system developers automating
similar attacks using other models and then compare
those results. This process should help us further auto-
mate our model.
References
1. S. Gordon and R. Ford, “Cyberterrorism?,” Computers
and Society, vol. 21, no 7, 2002, pp. 636–647.
2. D. Moore, C. Shannon, and J. Brown, “Code-Red: A
Case Study on the Spread and Victims of an Internet
Worm,” Proc. 2nd ACM Internet Measurement Workshop,
ACM Press, 2002, pp. 273–284.
3. S. Staniford, V. Paxson, and N. Weaver, “How to Own
the Internet in Your Spare Time,” Proc. 11th Usenix Secu-
rity Symp., Usenix Assoc., 2002, pp. 149–167.
4. C. Shannon and D. Moore, “The Spread of the Witty
Worm,” Cooperative Assoc. for Internet Data Analysis,
19 Mar. 2004; www.caida.org/analysis/security/witty/.
5. D. Farmer and W. Venema, “Improving the Security of
Your Site by Breaking Into It,” Proc. 6th Usenix Security
Symp., Usenix Assoc., 1996, pp. 63–76.
6. M. Howard and D. LeBlanc, Writing Secure Code , 2nd
ed., Microsoft Press, 2002.
7. B. Schneier, “Attack Trees,” Dr. Dobb’s J ., vol. 24, no. 12,
1999, pp. 21–29.
8. J. Steffan and M. Schumacher, “Collaborative AttackModeling,” Proc. 17th ACM Symp. Applied Computing
(SAC 2002), ACM Press, 2002, pp. 253–259.
9. J. McDermott, “Attack Net Penetration Testing,” Proc.
2000 New Security Paradigms Workshop, ACM Press, 2000,
pp. 15–22.
10. B. Wood, “An Insider Threat Model for Adversary Sim-
ulation,” Proc. 2nd Workshop Research with Security Vul-
nerability Databases, SRI Int’l, 1999.
Helayne T. Ray is the chief operating officer at SI Government Solutions and a PhD candidate in the computer science depart-ment at Florida Institute of Technology. Her research interests
include reverse engineering, software security, and metrics. Ray has an MBA from the Florida Institute of Technology. She is a member of the IEEE, IEEE Women in Engineering, IEEE Computer Society, ACM, and Association for Women in Computing (AWC).Contact her at [email protected].
Raghu Vemuri is a software engineer at Motorola. He has anMS in computer science from the Florida Institute of Technol-ogy. His interests are in software testing and database systems.Contact him [email protected].
Hariprasad Kantubhukta is a software engineer for Progres-sive Insurance. His research interests include software quality,software security, human interface design, and computer vision. Kantubhukta has an MS in software engineering from
the Florida Institute of Technology, and an MS in computer science from Andhra University, India. Contact him at [email protected].
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 25
www.computer.org/internet/
Stay on Track
IEEE Internet Computing reports emerging tools, technologies,and applications implemented through the Internet to support aworldwide computing environment.