# Presentation: 660521

## Penetration Testing

- PCIE/ECIE Conference
- March 25, 2003

## Becoming More Routine

- Per the IT Roundtable Survey:
- 19 of 26 agencies conduct pen tests
- IG’s oversaw 18 of the 19 tests

## What Is Penetration Testing?

- Testing the security of systems and architectures from a hacker’s point of view
- A “simulated attack” with a predetermined goal

## Access Points to Your Network

- Internet gateways
- Modems
- Wireless networks
- Physical entry
- Social engineering

**Notes:**
Pen tests can evaluate any and all of these access points.  Internet gateways are almost always included but it’s the auditor’s call based on risk.

I don’t like to do the physical entry tests in this day and age.  All you need is a guard that gets a little excited and starts firing his weapon.  Dead auditors don’t help much.

## Penetration Testing Is Not...

- An alternative to other IT security measures – it complements other tests
- Expensive game of Capture the Flag
- A guarantee of security

**Notes:**
Vulnerability assessments are great for identifying weaknesses.

But, penetration testing allows you to determine how significant those weaknesses really are.

A good solid security audit program should include:
program reviews to determine if policies and procedures exist, 
vulnerability assessments to determine whether the security procedures have been implemented, and 
penetration tests to determine the impact of the weaknesses.  We’ve found that pen tests can also identify new weaknesses.

It’s important to define the end point (e.g. gaining system administrator privileges or employees’ passwords.
But, the best result is to identify weaknesses and recommend doable corrective actions.

“Guarantee” segue to next slide.

## Limitations

- It’s only valid for the period tested
- Time to perform

**Notes:**
It’s only a snapshot of the security posture at the time of the test.

Techniques are limited...we gave our vendor 6 –8 weeks to conduct the tests.  A determined hacker could take years.

So, attacks during the pen test will be more obvious and concentrated.

## Benefits:  Why Do It?

- According to the 2002 CSI/FBI Survey
- 90% of respondents detected security breaches within the last 12 months
- 80% acknowledged financial losses due to security breaches
-  Average loss = $2 million

**Notes:**
With this amount of attacking going on, it’s critical to understand your weaknesses and to make informed decisions on what risks you want to take with your firewalls.

## Benefits – Why Do It?

- Gets management’s attention
- Illustrates how a combination of factors can lead to a *BIG *security breach
- Great educational opportunity for audit staff

**Notes:**
Our vulnerability assessments identified many of the same weaknesses our contractor did.  But, the closing conference on the pen test was attended by the CIO and his lieutenants.  He took immediate action.

Our vulnerability assessments only show what could happen.  The pen test shows how those vulnerabilities can be exploited.

At least one auditor was with the contractor at all times.

## Two Tests...Same Basic Approach

- Two stages (did not want sensitive information to go across Internet)
- External view (hacker)
- Internal view (disgruntled employee or contractor)

**Notes:**
Statistics are all over the place.  But, the prevailing wisdom is that more attacks come from hackers on the outside.  

However, the most damaging attacks come from employees or contractors who already have access to at least some parts of the system and know where the damage can be done.

## External View

- Stopped if firewalls were penetrated
- Conducted from vendor’s office
- Used only publicly available information

**Notes:**
Ideally, we would have penetrated the firewalls and gone directly into the IRS system to see what a hacker could get before being caught.  However, the IRS insisted and we agreed that it would not be wise to allow sensitive information to transit the Internet.  So, we agreed to stop at the firewalls whether we penetrated them or not.  We would then go inside the firewalls (on the IRS network) to determine what the hacker could have gotten, or what a disgruntled employee could do.
Told contractor to emulate a hacker so we didn’t provide any inf
ormation about the IRS architecture.  They used Internet information (arin.com) and other sites to gain knowledge about the IRS and to identify potential weak points.

During the first pen test, we were very “noisy”.  The attacks we made were very obvious and identifiable by intrusion detection systems.  We also told IRS what we were doing and when.  More on that later.

In the second test, we didn’t tell the IRS and we were more stealthy.  The contractor went slower, used a variety of computers from a variety of locations.  We didn’t expect to be picked up by the intrusion detection systems until we actually started to penetrate.  At that time, it was reasonable to expect to be caught.  This approach allowed us to evaluate the intrusion detection systems.

## Internal view

- Stopped when password file obtained
- Did not crack password files
- Conducted from TIGTA/IRS offices
- IRS participated

**Notes:**
Our end point was gaining access to password files.  The IRS agreed that if we had the password file, we could break passwords with software readily available to hackers.  We agreed so employees would not have to change their password.

We intended to do this stage as well without notifying IRS.  However, we started seeing some vulnerabilities that could not be exploited without getting passwords.  I went back to the CIO to get his permission, and also to ask if he would assign an IRS employee to participate with us.  That accomplished two things:
	1.  The IRS could see first hand what the weaknesses were and agree with us on the spot.
	2.  The IRS could help us steer the vendor away from any sensitive data.

Again, at least one TIGTA employee was with the contractor at all times.

## Two Tests...Differences

- Vendor selection/expertise
- Level of cooperation with the IRS

**Notes:**
We selected our contractors for both tests from government schedules.  We followed up with references and went with a contractor who came highly recommended, primarily because of a Ph.d on the staff who had performed well.  Unfortunately, the Ph.d quit the first day of our test.  Despite what the contractor told us, they didn’t have anyone else on the staff with sufficient expertise.

Specialized skills are needed.  I have several people on my staff that can identify security vulnerabilities, but no one who can exploit those vulnerabilities.  The contractor must have a “hacker’s” mindset.

On the first test, we told the IRS what we wanted to do and when.  They were reluctant to cooperate and in our estimation, put up as many roadblocks as possible.  Some of their concerns, I have to admit, were valid and it took several months of persevering before we actually were able to start.  

We also asked them to participate from the beginning.  At first, they did.  But when we told them we were going to be working on Saturday morning, they didn’t show up.  Interestingly, they said that alarms went off that Saturday morning and they immediately blocked our access.  I called them up and acknowledged that they had caught us, but then to open up our access again so we could complete some tests, but they wouldn’t.  It took several days to work that issue out.

For the second pen test, we told only the CIO and asked him not to tell anyone.  That way we could conduct a more realistic test and include an evaluation of the effectiveness of their intrusion detection systems.

## Lessons Learned

- Research prospective vendors – no guarantees
- Hire hackers?
- Give the vendor time to get their experts’ backgrounds cleared
- Know their tools
- COTS
- Shareware/Freeware

**Notes:**
Make sure (even get a signed statement) that they are knowledgeable of the tools they use and have tested them in a safe environment.

## Lessons Learned

- Check out the vendor’s offices and make sure the physical security is appropriate.
- Use government computers when possible and ensure that the data remains the government’s property.

## Lessons Learned

- Detailed agreements/scope
- Anything off limits?
- Hours of testing?
- Social Engineering allowed?
- War Dialing?
- War Driving?
- Denials of Service?
- Define the end point

## To Tell or Not to Tell?

- Telling too many people may invalidate the test
- However, you don’t want valuable resources chasing a non-existent “intruder” very long
- And, elevation procedures make not telling risky

**Notes:**
Attacks on agencies should be reported to GSA’s FedCIRC (a clearinghouse so that widespread attacks on the government can be detected) and the FBI.  We only told the CIO who may or may not have been advised before our attack was reported.

We had a signed statement from the CIO (a get out of jail free card) authorizing our work just in case special agents came tracking us down.  And, everybody associated with the test had emergency numbers for each other.

So, for us, it worked not telling anybody but the CIO when we conducted our external penetration testing and then getting them involved when we came inside.

## Contact Information

- stephen.mullins@tigta.treas.gov
- (916) 408-5573
- (925) 210-7024

**Notes:**
Interested in hearing what’s worked for others and we’re willing to share what’s worked and what hasn’t for us.