In my small introduction to methods (methodologies) for penetration testing I have now come to the second and closing part. Today I am going to lift the veil on the method I have implemented at the company I work for.
I took basis in the method described in the first post in this series. Since it didn’t quite fit our needs I set out to change it. You see, the company I work at mainly delivers web portals only. This means we don’t do anything server related. That’s a job for our hosting partners. I don’t necessarily agree on this – but that’s life. So we’ll just stick with the portals world and focus on what we do to cut known risks. Our goal isn’t a full-fledged penetration test. Our goal is to cut amount of vulnerabilities once the project gets shipped over for penetration testing by external companies.
Step 1: Project Scope and getting permissions
When a project leader or tech leads deems the project ripe for testing they send me an e-mail. Once I get this I will book a meeting with the requester.
During this meet we try to uncover matters such as
- What kind of project it is. Basically we separate between to types: “Internet” and “Intranet”.
- If it heavily relies on external services
- Which user segment the project addresses.
- What kind of tests they need. We try to uncover if they need just an automatic scan, manual test or a hybrid.
- If there are any particular areas that must be heavily tested
- The type of report the requester wants. Basically we try to uncover the technological level we’ll be at in the report. Surprisingly there are many project managers that does not understand technology at all.
This meeting lasts for two hours. At the end of this meeting the requester delegated to collect permissions from all involved parties. Without permissions we can not do any tests. Our hosting partners has must be informed about the testing because it will trigger their intrusion detection systems.
When the permissions are obtained the requester is also put in charge of setting up a proper test environment. Usually they delegate this further down the line to a team member. When done this team member notifies me and I make a recheck with the requester if all is good to continue.
Step 2: Scanning for vulnerabilities
Hopefully everything is in order for me now to start testing. The very first thing I do is to get acquainted with the target site. Then I setup one of the web vulnerability scanners directed at this target and launches the scan.
The vulnerability scanner will loop through the site based on the rule set I have made for it. This scanner will apply known attacks wherever it can. Basically it is just an automated hacking attack.
When the scanner finishes it generates a report of what it found along with information how to remedy the issues. Then I move on to the manual validation.
Step 3: Manual validation
The very first thing I do is to actually read the report generated. For each finding I will make sure to try to confirm it on the targeted site. I usually use Firefox and BurpSuite (in Proxy mode) for this. The reason for manual validation is that the scanner sometimes finds fake vulnerabilities.
I use the report also as a tool to see which areas of the site that is troublesome. Call it a heat map. On these areas I will apply manual ways such as fuzzing, SQL injections and XSS. Almost forgot, I also apply some well-known vulnerabilities for the CMS’s in question.
I document every approach with which method I tried and what the outcome was. This serves a base to the finalized report later on.
Step 4: Report
This process is when we merge the auto generated report with what we found manually. Each vulnerability gets graded on its severity – and the sum of this makes out a grade of security for the overall site.
It’s crucial that this report matches the technology competency level of the requester. If we aim to high the requester will not understand what the report says. Based on the first meeting we try to level the report.
When done, the auto generated report and the report we just wrote sent back to the requester along with a follow-up meeting invitation.
Step 5. Follow up
Follow-ups are carried out in three steps. First is the first follow-up meeting where we discuss the reports with the requester. We expect that the requester will take actions right after this meeting.
After two weeks we contact the requester to get an overview of the fixing process. If the fixing process hasn’t started yet we wait for another two weeks before we contact them again. If this third attempt of getting an overview fails we close this case.
It is important to note that the requester are in charge of managing the fixing process. The requester is also free to consult with us during this process. When the requested deems the vulnerabilities mended the requester can order a new test to confirm the fixes.
This is our method for penetration testing. At the end of the project we hire an external penetration team to find the more severe vulnerabilities. Personally I would rent them throughout the development cycle but that is not possible.
Notice that we do not do port scanning or reconnaissance. We already know what kind of server the site runs on, we already know the CMS it runs on. We have no control of the servers since we only deliver portals. Sad, I know – but that’s life.
So with this I close my series on methods.