fisma certification and accreditation handbook phần 5 ppt

Table 11.2 continuedTypes of Security Incidents20 Network Bandwidth Attack An unusual and unauthorized increase in network traffic possibly induced by a user downloading excessive amount

Table 11.2 continuedTypes of Security Incidents

11 Insider Threat— Any type of unauthorized use of an

Unauthorized Access account outside the account’s

autho-rized levels of privilege for normal usage

12 Insider Threat— An unintentional security breach that

Administrator Error occurs due to an administrative error

(e.g., incorrect configuration)

13 Installation of Installation of software that is not

Unlicensed Software approved or licensed by the agency

(includes commercial software, custom code, freeware, and media)

14 IP Address Spoofing An attack where an unauthorized user

gains access to a computer or a work by making it appear that a mes- sage or packet has come from a trusted machine by “spoofing” the IP address of that machine

net-15 Java or ActiveX Exploitation Any circumstance that creates

exploita-tion of Java or ActiveX

16 MAC Address Spoofing An attack where an unauthorized user

gains access to a computer or a work by making it appear that a mes- sage or packet has come from a trusted machine by “spoofing” the MAC address of the trusted machine

net-17 Malicious Code Indication of a computer virus, worm,

or Trojan whether destructive, or harmless

18 Loss or Theft An indication that a computer, system,

or media has been lost or stolen

19 Man-in-the-Middle Attack An attack where a malicious party

intercepts and/or alters a legitimate communication between two friendly parties without the knowledge of the original sender or recipient

Table 11.2 continuedTypes of Security Incidents

20 Network Bandwidth Attack An unusual and unauthorized increase

in network traffic (possibly induced by

a user downloading excessive amounts

of data, or using unauthorized tools that reserve large amounts of band- width)

21 Other Attacks All other circumstances in which a

security incident occurs but cannot be identified by any other predefined category

22 Packet Sniffing / A circumstance where a malicious user

Network Wiretap gathers, monitors, or analyzes data

communications traveling between two or more systems

23 Reconnaissance Scans Indication of a network probe by an

unauthorized user (possibly gathering information such as open ports, run- ning services, operating systems, or configuration information)

24 Security Attack Any circumstance where a system or

network’s security support ture fails, and the data on that system

infrastruc-or netwinfrastruc-ork is left open to security attacks (e.g., failure of a host- or net- work-based intrusion detection system)

25 Sensitive Compromise Any theft of sensitive resources (e.g.,

passwords; protected, classified, or restricted data; licensed applications or software; restricted applications, soft- ware or code)

26 Stolen or Misplaced A circumstance that results in stolen or

Equipment misplaced agency hardware,

equipment, or media

27 Unauthorized Web Surfing Web surfing by employees to

untrusted and potentially dangerous or inappropriate Web sites

Table 11.2 continuedTypes of Security Incidents

28 Unauthorized Access Any type of unauthorized use of a

valid account by someone who is not

an employee of the agency

29 Unauthorized Access and Any circumstance where an

Modification of Access unauthorized user changes the Control Lists configurations of access control lists

located on critical network ture such as routers or firewalls

infrastruc-30 User Data Breach Any type of circumstance that creates

unauthorized loss, theft, alteration, or compromise of user data or private user information

31 Web Site Defacement Any activity that causes, or attempts to

deface, or create unauthorized cation of internal or external agency Web sites

modifi-Incident Response Plan Checklist

Once your Incident Response Plan is finished, use this checklist to make sureyou didn’t forget anything:

■ Does your plan accurately describe the systems it applies to?

■ Does your plan include a contact list of key personnel?

■ Does your plan include information on roles and responsibilities?

■ Does your plan include a diagram of the escalation framework?

■ Does your plan include how to contact the agency CSIRC?

■ Does your plan list the members of the CSIRT team?

■ Does your plan list the members of the CSIRC team?

■ Does your plan include a description of incident types?

■ Does your plan include guidance on severity levels?

■ Does your plan include information on agency security policies?

■ Does your plan include incident handling guidelines?

■ Does your plan include a section on information forensics?

■ Does your plan include a Security Incident Reporting Form?

Security Incident Reporting Form

Every incident response program should have an Incident Reporting Form to

standardize and track the collection of security incident information.The

Incident Reporting Form that applies to the information system undergoing

C&A should be included at the end of your Incident Response Plan.The

information contained on the Incident Reporting Form should be consistent

with the information described in the Incident Response Plan For example,

if you include a section on the form that calls for a severity classification, be

sure that severities are defined in the Incident Response Plan A sample

Incident Reporting Form is shown in Figure 11.2

Figure 11.2Sample Security Incident Reporting Form

SECURITY INCIDENT REPORTING FORM

Incident Report Number:

Date and Time:

Incident Response Manager: _ Alternate

Incident Type, Name(s) and ID:

Incident Type Identification Numbers (from list):

Data: Classified Unclassified

System Information: (Report operating system name, version, and patch level/Service Pack)

Platform: Workstation Server Laptop

Asset Identification Bar Code Number:

Networks and Domains Affected:

Incident Summary: (Be specific List dates and times Include how incident was detected and resolved and describe what forensics tools and programs were used.)

An Incident Response Plan formally documents the agency’s strategy for

responding to security breaches By its very nature, a security incident is a

time of crisis to some degree, and during this time, more so than any other

time, you need to ensure that decisions being made are levelheaded and based

on sound judgments.The best way to do this is to define clear procedures and

protocols for responding to the crisis before the crisis ever hits and then to

train employees about these procedures and protocols.This is why the

Incident Response Plan is such a vital document

The Incident Response Plan should cover all foreseeable security events,and it should lay out the rules and triggers by which agency personnel are to

take action in response to the event Although it may be impossible to predict

when and where a denial-of-service attack will strike, it is somewhat easier to

determine what the appropriate response should be If this response is

docu-mented and agency employees are trained on the response, then cooler heads

will prevail when and if the possibility of the attack ever becomes a reality

Additional Resources

This section provides you with information about organizations involved with

incident response It also includes lists of books and other material related to

incident response and forensics

Incident Response Organizations

The organizations listed in Table 11.3 offer valuable information on computer

security incidents, vulnerabilities, and response activities

Table 11.3Incident Response Organizations

CERT Coordination Center A federally funded research and

http://www.cert.org development center operated by

Carnegie Mellon University

Continued

Table 11.3 continuedIncident Response Organizations

Common Vulnerabilities and Exposures A list of standardized names for http://cve.mitre.org vulnerabilities developed by the

MITRE Corporation Forum of Incident Response and An organization that specializes in Security Teams computer security incident response http://www.first.org/

SANS Top 20 A security vulnerability list maintained http://www.sans.org/top20 by SANS and development with the

FBI X-FORCE Alerts and Advisories Information on Internet threats and http://xforce.iss.net/xforce/alerts vulnerabilities operated by Internet

Security Systems United States Department of A central DoD Web site offering Defense CERT current information on security

http://www.cert.mil vulnerabilities and incidents

United States Computer Emergency Coordinates defense and response Readiness Team against cyber attacks on the U.S http://www.us-cert.gov/ infrastructure

United States Department of Publishes threat information to

Homeland Security the U.S infrastructure

Jones, Keith J Real Digital Forensics: Computer Security and Incident

Response Addison-Wesley, September 2005 ISBN: 0321240693.

Kruse, Warren G and Jay G Heiser Computer Forensics: Incident

Response Essentials Addison-Wesley, September 2001 ISBN:

0201707195

Lucas, Julie and Brian Moeller The Effective Incident Response Team.

Addison-Wesley, 2004 ISBN: 0201761750

Mandia, Kevin and Chris Prosise Incident Response, Investigating

Computer Crime Osborne/McGraw Hill, 2001 ISBN: 0072131829.

Northcutt, Stephen Computer Security Incident Handling SANS

Institute, March 2003 ISBN: 0972427376

Schweitzer, Douglas Incident Response, Computer Forensics Toolkit.

Wiley, 2003 ISBN: 0764526367

Van Wyk, Kenneth R and Richard Forno Incident Response O’Reilly

& Associates, 2001 ISBN: 0596001304

Articles and Papers on Incident Response

Various useful articles and papers on computer security incident response are

listed here:

Computer Security Incident Handling Guide NIST Special Publication

800-61, January 2004 (http://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf )

“Digital Evidence: Standards and Principles (Draft).” Forensic ScienceCommunications, April 2000

(www.fbi.gov/hq/lab/fsc/backissu/april2000/swgde.htm)

FCC Computer Security Incident Response Guide United States Federal

Communications Commission, December 2001(http://csrc.nist.gov/fasp/FASPDocs/incident-response/Incident-Response-Guide.pdf )

Handbook for Computer Security Incident Response Teams (CSIRTS) The

Software Engineering Institute, April 2003 (www.sei.cmu.edu/publications/documents/03.reports/03hb002.html)

“Responding to Intrusions.” CERT Coordination Center(www.sei.cmu.edu/publications/documents/sims/sim006abstract.html).Taylor, Laura “Incident Response Planning and Management.”

Intranet Journal Jupiter Media, January 28, 2002

(http://intranetjournal.com/articles/200201/se_01_28_02a.html).Taylor, Laura “Old-school UNIX tools help track down hackers.”

TechRepublic, June 19, 2002

(http://insight.zdnet.co.uk/hardware/servers/0,39020445,2123102,00.htm)

Taylor, Laura “Read Your Firewall Logs.” ZDNet, July 5, 2001

(http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2782699,00.html)

“U.S Department of Justice Search and Seizure Guidelines.” UnitedStates Department of Justice, November 10, 2005

(www.usdoj.gov/criminal/cybercrime/searching.html)

Wotring, Brian “Host Integrity Monitoring.” SecurityFocus, March

31, 2004 (www.securityfocus.com/infocus/1771)

Notes

1 Kent Kim Grance Computer Security Incident Handling Guide NIST Special

Publication 800-61 National Institute of Standards and Technology, January

2004, p D-2

Performing the Security Tests and Evaluation

“No law or ordinance is mightier than standing.”

under-—Plato

Topics in this chapter:

■ Types of Security Tests

■ Types of Security Controls

■ Testing Methodology and Tools

■ Who Should Perform the Tests?

■ Documenting the Tests

■ Analyzing the Tests and Their Results

Chapter 12

187

A Security Test & Evaluation, known among security experts as an ST&E, is a

document that demonstrates that an agency has performed due diligence intesting security requirements and evaluating the outcome of the tests.TheST&E is a C&A document that tends to give agencies a lot of trouble It’s notclear to many agencies what tests they should be doing, who should be doingthem, and what the analysis of the tests should consist of.The ST&E is sup-posed to convince the C&A package evaluators that the agency understandsthe security requirements, enough so, that they can create tests to ensure thatthe security controls uphold the requirements

It is the responsibility of the information system owner to ensure that thetesting actually takes place However, the information system owner maychoose to designate this responsibility to the ISSO.The federal guidance onwhat to include in your ST&E is somewhat vague, and though this leaves lots

of room for flexibility, it leaves many information system owners, C&A

package preparers, and C&A package evaluators wondering what a goodST&E should include

Types of Security Tests

Keep in mind that you are trying to certify and accredit an information nology implementation, not a product.That being said, any implementationlikely uses many products Figuring out where to draw the line in the sand onwhere a product ends and where an implementation begins is half the battle

tech-If you are using commercial off-the-shelf products, presumably due diligencewas already done in selecting that product.You are not trying to justify theactual purchase of the product.You are trying to justify that the product wascorrectly installed and configured

Refreshing your memory from Chapter 2, C&A is based on certifyingConfidentiality, Integrity, and Availability (CIA).Therefore, your tests should

be designed to determine if Confidentiality, Integrity, and Availability are served by the security controls that are in place Within each CIA category,some of the tests will pertain to management controls, some of the tests willpertain to technical controls, and some will pertain to operational controls

pre-Confidentiality Tests

Confidentiality tests determine if unauthorized disclosure is possible When

you perform confidentiality tests, you are trying to determine if data is

dis-closed to people that it is not intended for.You are also trying to determine

that data is readable and executable by the people it is intended for

Before you can set up tests to ensure confidentiality, you have to stand a bit about confidentiality risks and vulnerabilities Data traveling in

under-plaintext over communications lines is vulnerable to sniffing Weak passwords

can be compromised using password crackers Confidentiality tests look to

ensure that authentication and encryption mechanisms work according to the

security requirements It’s also important to ensure that the authentication and

encryption mechanisms have not just been implemented, but that they have

safeguards built around them to protect them from being sabotaged

If you have reason to believe “shoulder surfing” is a risk, then a securitypolicy should be written that requires all users to be partitioned from other

users If you have reason to believe social engineering (tricking a user into

revealing information to unauthorized individuals) is a risk, you should be

sure to address that in your Security Awareness & Training Plan If you believe

that cryptographic algorithms may not have been implemented correctly, you

should use only products that have passed FIPS 140-2 testing performed using

the Cryptographic Module Validation Program (CMVP).1

If password files exist, you may want to perform a test to ensure that thepasswords are properly encrypted and the encrypted passwords are not easily

discovered using a dictionary password cracker.You’ll also want to ensure that

the permissions on the password files are set correctly and are not writeable

to the world

If you are using biometric devices, you will want to be sure to test theFalse Acceptance Rates (FAR), the False Reject Rates (FRR), and the Cross-

over Error Rates (CER) A biometric device is more accurate and reliable as

the CER goes down and you will want to establish acceptable thresholds in

your test plan Other metrics to take into consideration for biometrics include

the Failure to Enroll (FTE) rate and the Failure to Acquire (FTA) rate FTE

denotes the amount of people who are not able to use the system due to

some sort of incompatibility and FTA denotes the number of users who arenot able to render an acceptable enrollment image to use the device.

ST&E Best Practices…

Securing Biometric Devices

The following list explains the various rates that should be tested ever you use biometric devices.

when-■ FAR = the percent of unauthorized users incorrectly matched

to a valid user’s biometric

■ FRR = the percent of incorrectly rejected valid users

■ CER = the error rate at which FAR equals FRR

■ FTA = the failure to acquire rate

■ FTE = the failure to enroll rate

If VPNs are a part of the infrastructure that you are certifying, you’ll need

to devise some tests to ensure that the VPN has been properly configured andcannot be penetrated by unauthorized users.You’ll also need to clearly

describe whether the VPNs being tested are secure remote access VPNs (used

by remote users) or end-to-end VPNs that encrypt all traffic that goes

between designated sites VPNs can be configured to pass packets in tunnel

mode, transport mode, or both Which modes does your security policy require?

You’ll need to ensure that VPNs are configured in accordance with yoursecurity policy

Confidentiality problems that you’ll want to check for include:

■ Passwords that do not comply with the security policy

■ Authentication systems that are not properly configured

■ Use of algorithms that do not comply with the security policy

■ Secure implementations of encryption products (VPNs, PKI, etc.)

■ Implementations that do not produce logging capabilities

To help you understand how to test for confidentiality, construct questionsregarding confidentiality security controls For example:

1 What security controls ensure that passwords comply with the rity policy?

secu-2 What security controls ensure that authentication systems are erly configured?

prop-3 What security controls ensure that algorithms comply with the rity policy?

secu-4 What security controls check for proper configuration of encryptionproducts?

5 What security controls ensure that authentication and encryption systems produce log files that comply with the security policy?

By answering these questions, you can put together a list of security controls that address confidentiality mechanisms.Your confidentiality security

controls can be managerial, operational, or technical in nature Once you have

developed your list of security controls, you can devise tests for them

Integrity Tests

Integrity tests answer the question, “Is the data adequately protected to

pre-vent unauthorized modification?” A goal of any information technology

implementation is to preserve the integrity of the data.You need good data

and you need to determine if it is possible for someone to inadvertently, or

purposefully, generate bad data For example, buffer overflow attacks are

designed to breach the integrity of the system.Testing the integrity of the

implementation allows you to determine if secure coding principles were

adhered to and if all the right patches are in place

Coding gaffes that you’ll want to check for are:

■ Buffer overflow vulnerabilities

■ Extraneous lines of code

con-1 What security controls protect against buffer overflow attacks?

2 What security controls protect against extraneous lines of code?

3 What security controls protect against race conditions?

4 What security controls protect against temporary files writeable bythe world?

5 What security controls protect against hard-coded passwords?

From your list of questions, you should be able to put together a list ofsecurity controls that address each question.Your security controls can bemanagerial, operational, or technical in nature Once you have developed yourlist of security controls, you can devise tests for them

Availability Tests

Availability tests ensure that availability is preserved.The tests should verifythat availability exists as required by the initial design requirements On ahigh-level, the kinds of tests that apply to availability are:

■ Testing of the configuration management system

■ Testing of the Contingency Plan

Similar to how you test for integrity tests, you should be able to construct

a question related to security controls that checks for and prevents

vulnerabil-ities related to availability For example:

1 What security controls protect the configuration managementsystem?

2 What security controls protect the Contingency Plan?

3 What security controls protect the backups?

4 What security controls protect high-availability and mission criticalsystems?

5 What security controls protect fault-tolerance?

6 What security controls protect load-balancers?

Again, from your list of questions, you should be able to put together a list

of security controls that address each type of availability concern.Your

secu-rity controls can be managerial, operational, or technical in nature Once you

have developed your list of security controls, you can devise tests for them

Types of Security Controls

NIST provides an excellent listing of various security controls in Special

Publication 800-53, Recommended Security Controls for Federal

Information Systems (SP 800-53) available at the following URL: http://

csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf

If you need ideas for security controls that you may want to test, a longlist of different security controls begins on p 40 of this SP 800-53.The secu-

rity controls you choose to test should also be consistent with the security

controls that you include in your Self-Assessment (discussed in Chapter 8)

Management Controls

The testing of management controls looks at whether or not the current

information technology environment of the information system being

certi-fied holds management accountable and has built-in escalation thresholds

Planning controls ensure that the management team has ascertained the risks

involved and have either accepted them, or mitigated them before authorizing

operation For example, ensuring that systems get properly certified andaccredited every three years is a management control.

A test that checks to see if a risk is mitigated through existence of awritten security policy in place is a management test.Typically the manage-ment team is responsible for ensuring that appropriate security policies exist

Operational Controls

Operational tests are those that test if the actual operations of the systemundergoing C&A works as expected—according to the intended design Forexample, when you press a Submit button to submit a form, is the form actu-ally submitted as planned? If you a schedule a file to be sent to another com-puter at 2 A.M., does the file get sent on schedule? Operational tests answerthe question, “Does it work as intended according to the design require-ments?” For example, ensuring that the backups work as documented is anoperational control

Technical Controls

Configuration tests determine if the configuration of all the components ofthe installation are correctly configured If the products you have imple-mented are not configured correctly you could be setting yourself up forincredible security risks For example, ensuring that firewalls and intrusiondetection systems monitor and log all significant security events is a technicalcontrol

Testing Methodology and Tools

Your tests can be manual or automated, or a combination of both, as long asthey get the job done Either way, you’ll still have to document how the testswere conducted If you use a software test management package, you shoulddescribe it, and how it works, in the ST&E An example of testing proceduresand results are listed in Table 12.1.You’ll want to be sure to include the dateand version number for every test you perform For each test performed,

you’ll need to describe the expected results and the actual results If the actual

results do not match the expected results, the test has failed

There are different testing tools you may want to employ depending onwhat you’re going to test Since every implementation is different, not every

type of test may apply to all situations.You need to describe what was tested,

and how—and how you came to the conclusion that the test passed or failed

If you use tools to perform your tests, you’ll want to document your tests in a

similar fashion to how you document manual tests

Table 12.1Sample Description of Testing Procedures

Date and Version Number

Verify that security Confirm that Event Viewer is P

events are generated turned on

Set security properties to filter all

5 even types Generate a security event in each category and verify that Event Viewer creates a record for it Verify that passwords Logon as initial user P

use at least 8 Try to change password to new

characters with both password that has less than

letters and numbers 8 characters

Try to change password to new password that has 8 characters but does not use numbers Try to change password to new password that has 8 characters but does not use letters

Ensure that password field will accept an 8-character password with letters and numbers

Verify that the system Logon as initial user P

requires user to Check to see if system instructs

change the initial user to change their password

password before Don’t change the initial password

accepting initial and see if logon is possible

password Change the initial password and

ensure that user can logon

Continued

Table 12.1 continuedSample Description of Testing Procedures

Date and Version Number

Verify that Rules of Logon as initial user P

Behavior are displayed Look for Rules of Behavior

before initial logon Ensure that you can view them

and before being before you are prompted for your

prompted for password password

Ensure that there is an acceptance box that can be checked and that

it is working properly Ensure that initial Logon as initial user F

password is not Look for Rules of Behavior and Can logon accepted if user does check acceptance box even if user not check box to Don’t check the acceptance box and does not agree to Rules of see if you can still logon accept Rules Behavior Check the acceptance box and of Behavior

ensure you can logon Verify that you can Obtain backup media from one week F

restore a file from the ago, one month ago, three months Could not

Attempt to restore the admin (or password file root) password file from each of

the three archives Verify that the password file accepts the known admin (or root) password Verify that the only Scan the messaging server with a P

port open on the port scanner

messaging server is Verify that the only port found

TCP port 25 open is TCP port 25

Verify that no Scan network 49 with a modem F

connected to Verify that no modems are found

John Doe’s PC

Algorithm Testing

The biggest problem with encryption algorithms is that about 25 percent of

the time encryption algorithms are not implemented correctly in security

products As a result of this problem, there are now laws and standards that

specify how encryption algorithms need to be implemented

If an information system implementation includes encryption products, it

is a federal law that the encryption products be FIPS 140-22 compliant (unless

they have been approved and validated for classified use) Originally passed as

FIPS 140-1 in 1995, FIPS 140-2 is a Federal Information Processing Standard

(FIPS) that was instituted as a result of the Information Technology Reform

Act of 1996 (Public Law 104-106) and the Computer Security Act of 1987

(Public Law 100-235) FIPS 140-2 was published in May of 2001 and now

supersedes FIPS 140-1 Encryption products are not supposed to be procured

and implemented unless they have been officially certified and validated

through the Cryptographic Module Validation Program (CMVP)

Through the CMVP program, Cryptographic Module Testing (CMT) labsuse a tool called the Cryptographic Algorithm Validation System (CAVS) that

can only be obtained from NIST and is used exclusively for testing

encryp-tion products CAVS generates correct algorithm vectors that CMT labs use

to ensure that encryption algorithms are correctly implemented If an

encryp-tion product has compliant algorithms, the CMT validates the findings and

submits the results to the CMVP program for accreditation

Since all encryption products are supposed to be FIPS 140-2 compliantbefore they ever get implemented, a test to check for that is simply to ensure

that each and every encryption product in the implementation under C&A

has a valid FIPS 140-2 certificate FIPS 140-2 certificates are considered

public information and you can see all of them for every product ever

vali-dated under this program at http://csrc.nist.gov/cryptval/

The only way to get around not using FIPS 140-2 products is for thehead of the agency, or a senior agency designated officially, to apply for a

waiver.There are only two reasons considered acceptable for applying for a

waiver:

1 Compliance with FIPS 140-2 adversely affects the business mission

2 Compliance with FIPS 140-2 will create a major adverse financialimpact

To apply for a waiver, a letter justifying the request for waiver should besent to:

FIPS Waiver DecisionInformation Technology Lab

100 Bureau Drive, Stop 8900Gaithersburg, MD 20899-8900Because FIPS 140-2 exists, there should never be any need to test if cryp-tographic algorithms were implemented correctly in a product Products thatare not FIPS 140-2 compliant should never be implemented on the systemsthat are being certified.Therefore, as far as algorithm testing goes, you havetwo options: find out if there is a FIPS 140-2 certificate for any encryptionproducts used and if there is, document that in the ST&E If you find encryp-tion products without a FIPS 140-2 certificate, check to see if a waiver is onfile A waiver should have been applied for before the product was actuallyprocured However, if a waiver is not on file, the ISSO should advise the CIO

to apply for a waiver expeditiously

Keep in mind that FIPS 140-2 only requires that algorithms be correctlyimplemented in the product It will not tell you if the encryption producthas been correctly installed and correctly configured within the agencyinfrastructure

Code and Memory Analyzers

If your information system undergoing C&A uses code that is custom writtenand is not associated with any commercial off-the-shelf product, it is a goodidea to scan your source code for coding gaffes and vulnerabilities Code andmemory analyzers can help you uncover source code vulnerabilities andmemory leaks.The following code and memory analyzers have helped shore

up many applications:

■ CodeAssure Workbench by Secure Software(www.securesoftware.com)

■ Rational Purify by IBM (www306.ibm.com/software/

awdtools/purify/)

■ TotalView by Etnus (www.etnus.com)

■ Dynamic Leak Check by DMS (www.dynamic-memory.com)Some code analyzers are geared just for Web applications and specialize inchecking for Java and ActiveX problems, SQL injection vulnerabilities, CGI

problems, and cross-site scripting vulnerabilities Products that check for Web

application problems include:

■ Jtest by Parasoft (www.parasoft.com)

■ Shadow Web Analyzer by Safety-Lab (www.safety-lab.com)

■ WebKing by Parasoft (www.parasoft.com)

■ Nikto by Cirt.net (www.cirt.net/code/nikto.shtml)Many network scanners also scan for Web site vulnerabilities as well asnetwork and operating system vulnerabilities

Network and Application Scanners

Once configured and set up, network scanners run automated scans of your

systems and networks looking for well-known security vulnerabilities

Nonintrusive network scanners do not try to exploit the vulnerabilities they

find Intrusive network scanners find vulnerabilities and then try to exploit

them, and therefore are a bit more risky to use since they could potentially

cause damage to your systems Most scanners can be configured to scan an IP

address, a range of IP addresses, a domain, or a Web site High-end scanners

have the ability to generate a network map

Some scanners specialize in scanning applications where instead of lookingfor operating system vulnerabilities, their goal is to uncover vulnerabilities in

Web sites, cgi scripts, databases, and database applications

Popular network and application scanners include the following:

■ Internet Scanner by Internet Security Systems (www.iss.net)

■ IP360 by nCircle (www.ncircle.com)

■ Foundstone Enterprise by McAfee (www.foundstone.com/)

■ Nessus open source network scanner (www.nessus.org)

■ QualysGuard by Qualys (www.qualys.com/)

■ Retina Network Security Scanner by eEye Digital Security(www.eeye.com)

■ Security Auditor by Cisco (www.cisco.com)

■ STAT Guardian by Harris (www.harris.com)

■ AppScan by Watchfire (www.watchfire.com)After scanning systems or networks, penetration testing is the processwhereby one tries to exploit the discovered vulnerabilities When performingpenetration testing, a security engineer may use additional tools to try to pen-etrate the application, network, or system

Before performing scanning or penetration testing, it is very important toobtain permission in writing from the agency, bureau, or department thatowns the systems being scanned An agreement should be established onspecifically what will be scanned, and when the scanning will occur Whetherthe person performing the scanning or penetration test is an agency employee

or a consultant, it is important to obtain a signature on the agreement to tect yourself from liabilities so that you are not accused of being an unautho-rized intruder or a malicious insider

pro-Port Scanners

Port scanners simply scan for open ports.The reason to use a port scanner is

to find out if the open ports comply with your security requirements andyour security policy It is a security risk to have more ports open than neces-sary Often hackers scan for open ports to see which open ports they maywant to exploit Once a hacker finds an open port, they often use particularhacker programs that are uniquely coded to exploit a particular port Whendoing a port scan, you’ll want to scan both the TCP and UDP ports Manynetwork scanners also scan for open ports

By a long shot, the most popular port scanner is an open source tool

called nmap However there are some commercial port scanners available as

well Various port scanners that you may find useful include:

■ Atelier Web Security Port Scanner (www.atelierweb.com/)

Probably the most popular port listener available is netcat, and since it is

open source, it is free to use.You can obtain netcat from the PacketStorm

Web site, http://packetstorm.linuxsecurity.com/

A good test of your firewall is to run netcat on one of your mission ical servers that is protected by the firewall Have netcat listen on a port that is

crit-supposedly being blocked by the firewall and see if an attacking machine can

connect to this port—if it can, the firewall is being circumvented.You can

also use netcat to see if the port banner can be grabbed for the purpose of

finding out the version number of the operating system that is running

Websnarf is a port listener written in perl that is made just for Web sites

You can use this tool to find out local and remote IP addresses that are trying

to connect through port 80 If your firewall is blocking port 80, then no one

should ever be able to connect through port 80 If websnarf logs any

connec-tions to port 80, then someone is getting around the firewall.You can obtain

websnarf from the following URL: www.unixwiz.net/tools/websnarf-1.04

Modem Scanners

Modem scanners often are referred to as “war dialing” tools.The purpose of

modem scanners is to find out if there are any modems (or FAX machines)

that are connected to systems in violation of your security policy.The

fol-lowing products offer the ability to find unauthorized modems that couldcreate security vulnerabilities:

■ ModemScan by Michael McCobb (www.wardial.net/default.html)

■ Phonesweep by Sandstorm (www.sandstorm.com)

■ THC-SCAN by van Hauser (www.thc.org/releases.php)

Wireless Network Scanner

Wireless network scanners are sometimes referred to as “war-driving” tools orwireless protocol analyzers.These tools are good for detecting open wirelessnetworks in your facility If you have a policy that prohibits wireless networks,you may want to walk around the facility with a wireless network scanner tosee if you detect any unauthorized Wi-Fi networks Popular wireless networkscanners are available at the following URLs:

■ Netstumbler, an open source tool (www.netstumbler.com)

■ WiFiScanner, an open source tool(http://wifiscanner.sourceforge.net)

■ CommView for WiFi by Tamosoft (www.tamos.com)

■ iStumbler for Max OSX wireless network discovery (www.istumbler.net/)

■ Sniffer® Wireless Intelligence by Network General (www.networkgeneral.com)

■ Wireless Recon by Helium Networks (www.heliumnetworks.com)

■ AiroPeek SE by WildPackets (www.wildpackets.com) StumbVerter is an open source tool for mapping the results of a wirelessnetwork scan and is available at www.sonar-security.com/sv.html

Wireless Intrusion Detection Systems

Wireless intruders can be detected through various host-based intrusiondetection systems available at the following URLs:

■ Wi-Fi Defense by OTO Software (www.otosoftware.com/)

■ AirSnare by Digital Matrix (http://home.comcast.net/

~jay.deboer/airsnare/index.html)

■ Surveyor by AIRMAGNET (www.airmagnet.com)

■ Kismet by the open source community (www.kismetwireless.net/)

Wireless Key Recovery

Wireless key recovery tools are basically wireless key crackers Although they

can be used to recover lost keys, they are more often used to find out if the

wireless keys that are being used are easy to crack Wireless networks often are

secured by the Wireless Equivalent Privacy (WEP), which isn’t that secure;

however, it’s certainly better than no security at all Using these popular open

source tools, you can find out how easy your wireless network’s WEP keys

and keystreams are to crack:

■ WEPCrack (http://sourceforge.net/projects/wepcrack)

■ WEPWedgie (http://sourceforge.net/projects/wepwedgie/)

■ AirSnort (http://airsnort.shmoo.com/)

Password Auditing Tools

Password auditing tools, sometimes referred to as password crackers, can be used

to help you find out if your users are complying with the password security

policy.You can run the password file through leading password crackers to

find out if users are choosing easy-to-guess passwords that use words that are

commonly found in dictionaries Password auditing tools that can help you

determine weak passwords include:

■ Proactive Password Auditor by Elcomsoft (www.elcomsoft.com)

■ John the Ripper by the Openwall Project(www.openwall.com/john/)