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



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.





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


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



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).

Email

the malicious link

UnderstandSSB.com's HTML andcreate malicious script

Cross-site scripting on SSB.com

Click onthe malicious link

Attacker

Victim



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


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



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



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/internet/

Stay on Track

IEEE Internet Computing reports emerging tools, technologies,and applications implemented through the Internet to support aworldwide computing environment.

106-Toward an Automated Attack Model for Red Teams

Documents