There’s been a huge jump in the buzz over Information Security lately, with all of the high-profile disclosures and hacks going on. Anyone working in the field will tell you that this is not all that new, and actually it’s expected to some degree. Some organizations just do not learn until they become affected, and they end up paying much more than the cost savings they figured in by not having their environment pen tested. However, that means fun work ahead for those who have a passion for Information Security and love to play with all the latest tools to help break into various networks with the goal of making them more secure.
Those that are looking to get started may become overwhelmed by all of the tools and technologies pen testers must carry in their arsenal, but it’s also important to note the project management side of testing. It may not be very effective to just go full “black hat” on a client’s network. One must consider other variables, such as client needs, project cost, deadlines, and effective communication of findings so that they may be remediated. That is why I believe the five steps below are a good start to becoming an effective pen tester while not allowing yourself to get overwhelmed by pen test requests from the latest victimized retailer or health insurer.
- Be consistent with your testing methodology.
There are many excellent penetration testing methodologies that you should be reading before conducting any actual projects. These include the OWASP Testing Guide and the Penetration Testing Execution Standard. These include a wealth of information that can help get you on your way. However, for new folks, I would start at an even higher level and make sure you’re doing at least the following for *every* single pen testing effort you’re involved with:
- Identify testing boundaries. This means identifying any rabbit holes you *shouldn’t* go down with your client’ system(s).
- Perform host, service, and protocol identification. Utilize well-known tools such as Nmap and Metasploit. Vulnerability scanners are nice too. I personally like to use Nessus. Identify any technology-specific vulnerabilities from this data (easy mode).
- Attempt to bypass implemented network, system, or application access controls, including verifying implemented network segmentation controls to ensure that network scope is reduced to its absolute minimum.
- Enumerate and then inventory all of your points of entry in a test plan. This will help you track what you’ve done, as well as your findings.
- There’s so much more that could be added here.
- Create a test plan.
Performing the steps above can give you an overwhelming amount of data to track. Unlike hackers, we are not just looking for the first successful exploit and forgetting the rest. We must track all that was completed in order to relay that information effectively to the client. It may be awesome that you got that authentication bypass exploit to work with Metasploit, but what does that mean for the client? Why was the client running an outdated version of VNC? What other services that *weren’t* exploited are also out of date and may be exploited in the future? WHY WAS IT RUNNING ON A DOMAIN CONTROLLER?! These are all important questions that should be asked and backed up with our test plan.
A test plan can then be reviewed with an experienced pen tester to help identify any gaps. This can be incorporated into your organization’s peer review process (which should exist if it does not). Shoot me a message if you’d like to discuss creating effective test plans.
- Save all of your data.
Please do not complete a test and save *none* of your data. Again, this isn’t a race to just find the first exploit in a client’s network. It’s critical that information be saved so that it can be properly referenced if needed in the future. Nobody should want to memorize all their findings from a test completed months ago. I recommend making sure you have a *secure* place to store the following information:
- Your test plan!
- Screenshots of data or findings identified during the test. The more the merrier.
- Exported session data from key tools such as OWASP’s ZAP.
- Saved scan data that may come from tools such as Nmap or Nessus.
- Scripts or exploits you may have written for testing.
- Communicate with your client.
After all, your testing effort is because of your client’s desire to secure its network. Your methodologies and findings should not be a “closed book,” and it is wise to be as open as possible. There are a few things that should be regularly communicated before and during testing:
- Scope, boundaries, and timeline expectations. Set the scope of the testing effort, establish testing boundaries, and set timeline expectations. Do not just wing it and end up missing a block of IP address space that should have been included.
- Any findings you deem to be a critical or high risk to the client. Do not wait to provide this type of information until a month down the road when testing is completed and a report is delivered.
- Any shifts in the testing deadline. Issues arise for all projects. It may even be caused by the client! If there is something that will cause the project to not be delivered on time, then communicate this with the client and adjust as necessary. This is a an easy way to avoid ticking anyone off.
- Acquire historical data.
This will not always be possible, as it depends on the type of testing you’ll be conducting (white box, gray box, black box, etc). However, if possible, collect as much historical data on the environment as you can from the client before starting any testing. Data such as the items listed below can help gain an edge over a network. Yes, you may discover the same information while following your testing methodology, but you never know what you may find!
- Historical vulnerability scans, pen tests, security assessments, or even a PCI Report on Compliance
- Change orders (if the client has a working change management program)
- Asset inventory
- Network diagrams
- Service configuration files
Remember to read up on all the latest blogs, vulnerabilities, and exploits. Don’t worry, you won’t catch everything. Learn something new every day. Keep all this in mind while you’re starting out and it will give you a head start in becoming an effective tester.
Already an expert pen tester, or interested in making it part of your career? Check out our open Infrastructure InfoSec Engineer position!
Follow me on Twitter at @neiltylerbell.