Category Archives: Information Security Training

August Touchdown Task: Change Management Audit

Posted on by
2

This month’s touchdown task is to take a quick audit of your organization’s change management process. Give it a quick walkthrough.

  • Make sure that you are tracking when admins make changes to machine configurations or network device configs
  • Are proper peer review and approval processes being followed?
  • Check to make sure that the proper folks are in the loop for various kinds of communication, error handling and reporting
  • Review risk acceptance for changes and make sure it meets your expected processes
  • Examine a couple of changes and walk them through the entire process to see if things are falling through the cracks
  • Update any change management documentation to reflect new processes or technologies that may be in place now

Give this a quick review this month and you can rest assured for a while that change management is working strongly. With the coming fall and holiday rush ahead, you’ll know you have this base covered and can depend on it as a good foundation for the rest of your security initiatives. 

Until next time, as always, thanks for reading and stay safe out there! 

Always Remember the Business, InfoSec Folks

Posted on by
8

I just got out of yet another meeting with a big company partner for whom we act as an information security and threat advisor. In that meeting, I listened to a keyed-up,  hypercaffinated group of good guy security geeks tell their senior executives about the latest set of DLP controls they were putting in place. They spent 45 minutes describing packet-level checking, data flows, architecture diagrams and the technology of their solution set in painful (even for me) detail. Many of the executives were dosing lightly, while the geeks spun their techno-web. That’s when things took a turn for the worse…

The COO asked them one single question, interrupting a slide about email data flows ~ “How will this impact the business of ‘Dan’s’ group and the ‘Singularity’ project we have been working on since 2011? Doesn’t it depend on some of that data?” (**Names changed to protect the innocent and the guilty…)

Then, NOTHING HAPPENED. You could have heard a pin drop. Dead silence for close to two minutes. Finally, the COO repeated the question. Still nothing. He asked the lead geek if he knew who Dan was, and the geek said yes. He asked if Dan had been interviewed by the geeks prior to this. They said, no. The COO erupted in a rage, railing about how Singularity was the largest new line of business launch in the history of the company and how the projected income from the business would change the landscape of the firm. There were a LOT of apologies and some amount of notes taken to immediately consult with Dan. Much geek cred was lost. It will be a while before they get to present to the executives again like that. 

I tell you this story simply to remind all infosec folks about something I see all too often. It’s about the business. We are about the business. We are there to secure the business, nurture it, protect it, empower it to succeed. If that’s not where you or your team are, then you are doing it wrong. Get it right. Talk to the business. Speak their language. Give up on the “beauty of the baud” approach. Your packets and technology stack may be gorgeous to you, but if they don’t align with the business, then they won’t do anyone, including you, any good at all. Keep that in mind at all times. Also, remember to always talk to Dan ~ he’s a nice guy and he appreciates it. He can give you the answers you need and usually, he desperately wants to understand what you can do to make his project a success. Get to know all the Dan’s in your organization. They drive the world, you support them, together you build business and all of you will succeed!

Three Tough Questions with Aaron Bedra

Posted on by
4

This time I interviewed Aaron Bedra about his newest creation ~ RepSheet. Check it out here:


Aaron’s Bio:

Aaron is the Application Security Lead at Braintree Payments. He is the co-author of Programming Clojure, 2nd Edition as well as a frequent contributor to the Clojure language. He is also the creator of Repsheet, a reputation based intelligence and security tool for web applications.


Question #1:  You created a tool called Repsheet that takes a reputational approach to web application security. How does it work and why is it important to approach the problem differently than traditional web application firewalling?

I built Repsheet after finding lots of gaps in traditional web application security. Simply put, it is a web server module that records data about requests, and either blocks traffic or notifies downstream applications of what is going on. It also has a backend to process information over time and outside the request cycle, and a visualization component that lets you see the current state of the world. If you break down the different critical pieces that are involved in protecting a web application, you will find several parts:

* Solid and secure programming practices

* Identity and access management

* Visibility (what’s happening right now)

* Response (make the bad actors go away)

* HELP!!!! (DDoS and other upstream based ideas)

* A way to manage all of the information in a usable way

This is a pretty big list. There are certainly some things on this list that I haven’t mentioned as well (crypto management, etc), but this covers the high level. Coordinating all of this can be difficult. There are a lot of tools out there that help with pieces of this, but don’t really help solve the problem at large.

The other problem I have is that although I think having a WAF is important, I don’t necessarily believe in using it to block traffic. There are just too many false positives and things that can go wrong. I want to be certain about a situation before I act aggressively towards it. This being the case, I decided to start by simply making a system that records activity and listens to ModSecurity. It stores what has happened and provides an interface that lets the user manually act based on the information. You can think of it as a half baked SIEM.

That alone actually proved to be useful, but there are many more things I wanted to do with it. The issue was doing so in a manner that didn’t add overhead to the request. This is when I created the Repsheet backend. It takes in the recorded information and acts on it based on additional observation. This can be done in any form and it is completely pluggable. If you have other systems that detect bad behavior, you can plug them into Repsheet to help manage bad actors.  

The visualization component gives you the detailed and granular view of offenses in progress, and gives you the power to blacklist with the click of a button. There is also a global view that lets you see patterns of data based on GeoIP information. This has proven to be extremely useful in detecting localized botnet behavior.

So, with all of this, I am now able to manage the bottom part of my list. One of the pieces that was recently added was upstream integration with Cloudflare, where the backend will automatically blacklist via the Cloudflare API, so any actors that trigger blacklisting will be dealt with by upstream resources. This helps shed attack traffic in a meaningful way.

The piece that was left unanswered is the top part of my list. I don’t want to automate good programming practices. That is a culture thing. You can, of course, use automated tools to help make it better, but you need to buy in. The identity and access management piece was still interesting to me, though. Once I realized that I already had data on bad actors, I saw a way to start to integrate this data that I was using in a defensive manner all the way down to the application layer itself. It became obvious that with a little more effort, I could start to create situations where security controls were dynamic based on what I know or don’t know about an actor. This is where the idea of increased security and decreased friction really set it and I saw Repsheet become more than just a tool for defending web applications.

All of Repsheet is open sourced with a friendly license. You can find it on Github at:

https://github.com/repsheet

There are multiple projects that represent the different layers that Repsheet offers. There is also a brochureware site at http://getrepsheet.com that will soon include tutorial information and additional implementation examples.

Question #2: What is the future of reputational interactions with users? How far do you see reputational interaction going in an enterprise environment?

For me, the future of reputation based tooling is not strictly bound to defending against attacks. I think once the tooling matures and we start to understand how to derive intent from behavior, we can start to create much more dynamic security for our applications. If we compare web security maturity to the state of web application techniques, we would be sitting right around the late 90s. I’m not strictly talking about our approach to preventing breaches (although we haven’t progressed much there either), I’m talking about the static nature of security and the impact it has on the users of our systems. For me the holy grail is an increase in security and a decrease in friction.

A very common example is the captcha. Why do we always show it? Shouldn’t we be able to conditionally show it based on what we know or don’t know about an actor? Going deeper, why do we force users to log in? Why can’t we provide a more seamless experience if we have enough information about devices, IP address history, behavior, etc? There has to be a way to have our security be as dynamic as our applications have become. I don’t think this is an easy problem to solve, but I do think that the companies that do this will be the ones that succeed in the future.

Tools like Repsheet aim to provide this information so that we can help defend against attacks, but also build up the knowledge needed to move toward this kind of dynamic security. Repsheet is by no means there yet, but I am focusing a lot of attention on trying to derive intent through behavior and make these types of ideas easier to accomplish.

Question #3: What are the challenges of using something like Repsheet? Do you think it’s a fit for all web sites or only specific content?

I would like to say yes, but realistically I would say no. The first group that this doesn’t make sense for are sites without a lot of exposure or potential loss. If you have nothing to protect, then there is no reason to go through the trouble of setting up these kinds of systems. They basically become a part of your application infrastructure and it takes dedicated time to make them work properly. Along those lines, static sites with no users and no real security restrictions don’t necessarily see the full benefit. That being said, there is still a benefit from visibility into what is going on from a security standpoint and can help spot events in progress or even pending attacks. I have seen lots of interesting things since I started deploying Repsheet, even botnets sizing up a site before launching an attack. Now that I have seen that, I have started to turn it into an early warning system of sorts to help prepare.

The target audience for Repsheet are companies that have already done the web security basics and want to take the next step forward. A full Repsheet deployment involves WAF and GeoIP based tools as well as changes to the application under the hood. All of this requires time and people to make it work properly, so it is a significant investment. That being said, the benefits of visibility, response to attacks, and dynamic security are a huge advantage. Like every good investment into infrastructure, it can set a company apart from others if done properly.

Thanks to Aaron for his work and for spending time with us! Check him out on Twitter, @abedra, for more great insights!

Quick PHP Malware vs AV Update

Posted on by
Reply

It’s been a while since I checked on the status of PHP malware versus anti-virus. So, here is a quick catch up post. (I’ve been talking about this for a while now. Here is an old example.)

I took a randomly selected piece of PHP malware from the HITME and checked it out this afternoon. Much to my surprise, the malware detection via AV has gotten better.

The malware I grabbed for the test turned out to be a multi-stage PHP backdoor. The scanner thought it was exploiting a vulnerable WordPress installation. 

I unpacked the malware parts into plain text and presented both the original packed version from the log and the unpacked version to VirusTotal for detection testing. As you know, in the past, detection of malware PHP was sub single digits in many cases. That, at least to some extent has changed. For those interested, here are the links to see what was tripped.

Decoded to plain text vs Encoded, as received

As you can see, decoded to plain text scored a detection of 44% (19/43), which is significantly improved from a year or so ago. Additionally, excitingly, undecoded, the attack in raw form triggered a detection rate of 30% (13/44)! The undecoded result is HUGE, given that the same test a year or so ago often yielded 0-2% detection rates. So, it’s getting better, just SLOWLY.

Sadly though, even with the improvements, we are still well below half (50%) detection rates and many of the AV solutions that fail to catch the PHP malware are big name vendors with commercial products that organizations running PHP in commercial environments would likely be depending on. Is your AV in the missing zone? If so, you might want to consider other forms of more nuanced detection. 

Now, obviously, organizations aren’t just depending on AV alone for detection of web malware. But, many may be. In fact, a quick search for the dropped backdoor file on Google showed 58,800 systems with the dropped page name (a semi-unique indicator of compromise). With that many targets already victim to this single variant of PHP backdoors, it might be worth checking into if you are a corporate PHP user.

Until next time, take a look around for PHP in your organization. It is a commonly missed item in the patch and update cycles. It also has a pretty wide security posture with a long list of known attack tools and common vulnerabilities in the coding patterns used by many popular products. Give any PHP servers you have a deeper inspection and consider adding more detection capability around them. As always, thanks for reading and stay safe out there! 

Ask The Experts: Too Much Data

Posted on by
2

Q: “I have massive amounts of log files I have to dig through every day. I have tried a full blown SEIM, but can’t get it to work right or my management to support it with budget. Right now I have Windows logs, firewall logs and AV logs going to a syslog server. That gives me a huge set of text files every day. How can I make sense of all that text? What tools and processes do you suggest? What should I be looking for? HELP!!!!”

 

Adam Hostetler answered with:

 

I would say give OSSEC a try. It’s a free log analyzer/SEIM. It doesn’t

have a GUI with100 different dashboards and graphs, it’s all cli and

e-mail based (though there is a simple web interface for it also). It is

easy to write rules for, and it has default rules for many things,

except for your AV. You can write simple rules for that, especially if

you are just looking for items AV caught. It does take some tuning, as

with all analysis tools, but isn’t difficult after learning how OSSEC

works. If you want to step it up a bit, you can feed OSSEC alerts into

Splunk where you can trend alerts, or create other rules and reports in it.

 

Bill Hagestad added:

 

First things first – don’t be or feel overwhelmed – log files are what they are much disparate data from a variety of resources that need reviewing sooner rather than later.

 

Rather than looking at another new set to tools or the latest software gizmo the trade rags might suggest based on the flair of the month, try a much different and more effective approach to the potential threat surface to your network and enterprise information network.

 

First take a look at what resources need to be protected in order of importance to your business. Once you have prioritized these assets then begin to  determine what is the minimum level of acceptable risk you can assign to each resource you have just prioritized.

 

Next, make two columns on a either a piece of paper or a white board. In one column list your resources in order of protection requirements, i.e.; servers with customer data, servers with intellectual property, so and so forth. In a column to the right of the first assets list plug in your varying assigned levels of risk. Soon you will see what areas/assets within your organization/enterprise you should pay the most attention to in terms of threat mitigation.

 

After you have taken the steps to determine your own self- assessment of risk contact MicroSolved for both a vulnerability assessment and penetration test to provide additional objective perspective on threats to your IT infrastructure and commercial enterprise. 

 

Finally, Jim Klun weighed in with: 

 

You are way ahead of the game by just having a central log repository.  You can go to one server and look back in time to the point where you expect a security incident.

 

And what you have – Windows logs, firewall logs, and AV – is fantastic.  Make sure all your apps are logging as well ( logon success, logon failure).

Too often I have seen apps attacked and all I had in syslog was OS events that showed nothing.

 

Adam’s suggestion, OSSEC, is the way to go to keep cost down… but don’t just install and hope for the best.

You will have to tweak the OSSEC rules and come up with what works.

 

Here’s the rub: there is no substitute for knowing your logs – in their raw format, not pre-digested by a commercial SIEM or OSSEC.

 

That can seem overwhelming. And to that, some Unix commands and regular expressions are your friend.

 

So:

 

zcat auth.log | grep ssh | egrep -i ‘failed|accepted’

 

produces:

 

Jul  4 16:32:16 dmz-server01 sshd[8786]: Failed password for user02 from 192.168.105.51 port 38143 ssh2

Jul  4 16:33:53 dmz-server01 sshd[8786]: Accepted password for user01 from 192.168.105.38 port 38143 ssh2

Jul  4 16:36:05 dmz-server01 sshd[9010]: Accepted password for user01 from 192.168.105.38 port 38315 ssh2

Jul  5 01:04:00 dmz-server01 sshd[9308]: Accepted password for user01 from 192.168.105.38 port 60351 ssh2

Jul  5 08:21:58 dmz-server01 sshd[9802]: Accepted password for user01 from 192.168.105.38 port 51436 ssh2

Jul  6 10:21:52 dmz-server01 sshd[21912]: Accepted password for user01 from 192.168.105.38 port 36486 ssh2

Jul  6 13:43:10 dmz-server01 sshd[31701]: Accepted password for user01 from 192.168.105.30 port 34703 ssh2

Jun 26 11:21:02 dmz-server01 sshd[31950]: Accepted password for user01 from 192.168.105.70 port 37209 ssh2

 

 

Instead of miles of gibberish the log gets reduced to passed/fail authentication attempts.

 

You can spend an hour with each log source ( firewall, AV, etc) and quickly pare them down to whats interesting.

 

Then make SURE your OSSEC  rules cover what you want to see.

If that does not work – cron a script to parse the logs of interest using your regular expression expertise and have an email sent to you when something goes awry.

 

Revisist the logs manually periodically – they will change. New stuff will happen.  Only a human can catch that.

 

Take a look at:

http://www.securitywarriorconsulting.com/logtools/

 

The site lists a number of tools that may be useful

 

John Davis added:

 

You voice one of the biggest problems we see in information security programs: monitoring! People tell us that they don’t have the proper tools and, especially, they don’t have the manpower to perform effective logging and monitoring. And what they are saying is true, but unfortunately doesn’t let them out from having to do it. If you have peoples financial data, health data (HIPAA) or credit card information (PCI) you are bound by regulation or mandate to properly monitor your environment – and that means management processes, equipment, vulnerabilities and software as well as logs and tool outputs. The basic problem here is that most organizations don’t have any dedicated information security personnel at all, or the team they have isn’t adequate for the work load. Money is tight and employees are expensive so it is very difficult for senior management to justify the expenditure – paying a third party to monitor firewall logs is cheaper. But for real security there is no substitute for actual humans in the security loop – they simply cannot be replaced by technology. Unfortunately, I feel the only answer to your problem is for government and industry to realize this truth and mandate dedicated security personnel in organizations that process protected data.

 

As always, thanks for reading and if you have a question for the experts, either leave it in the comments, email us or drop us a line on Twitter at (@lbhuston). 

YAPT: Yet Another Phishing Template

Posted on by
4

Earlier this week, we gave you the touchdown task for July, which was to go phishing. In that post, we described a common scam email. I wanted to post an example, since some folks reached out on Twitter and asked about it. Here is a sample of the email I was discussing.

<paste>

Hi My name is Mrs. Hilda Abdul , widow to late Dr. Abdul A. Osman, former owner of Petroleum & Gas Company, here in Kuwait. I am 67 years old, suffering from long time Cancer of the breast.

From all indications my condition is really deteriorating and it’s quite obvious that I won’t live more than 3 months according to my doctors. This is because the cancer stage has gotten to a very bad stage.

I don’t want your pity but I need your trust. My late husband died early last year from Heart attack, and during the period of our marriage we couldn’t produce any child. My late husband was very wealthy and after his death, I inherited all his businesses and wealth .The doctor has advised me that I will not live for more than 3 months ,so I have now decided to spread all my wealth, to contribute mainly to the development of charity in Africa, America,

Asia and Europe .Am sorry if you are embarrassed by my mail. I found your e-mail address in the web directory, and I have decided to contact you, but if for any reason  you find this mail offensive, you can ignore it and please accept my apology. Before my late husband died he was major oil tycoon in Kuwait and (Eighteen Million Dollars)was deposited  in a Bank in cote d ivoire some years ago, that’s  all I have left now,

I need you to collect this funds and distribute it yourself to charity .so that when I die my soul can rest in peace. The funds will be entirely in hands and management. I hope God gives you the wisdom to touch very many lives that is my main concern. 20% of this money will be for your time and effort includin any expensese,while 80% goes to charity. You can get back to me via my private e-mail: (hilda.abdul@yahoo.com) God bless you.
1. Full name :
2. Current Address :
3. Telephone N° :
4. Occupation :
5. Age :
6. Country :

MRS. Hilda Abdul

<end paste>

As you can see, this is a common format of a phishing scam. In this case, you might want to edit the targeting mechanism a bit, so that they have to click through to a web page to answer or maybe even include a URL as supposed proof of the claim. That way you would have two ways to catch them, one by email reply and two by click through to the simple phish application.

As always your milage and paranoia may vary, but it is still pretty easy to get people to click or reply ~ even with age old spam phish attacks like this. What kind of return percentages did you get? What lessons did you learn? Drop us a line on Twitter (@lbhuston) and let us know. 

July’s Touchdown Task: Go Phish Yourself!

Posted on by
5

This month’s touchdown task is to spend about an hour doing some phishing. Phish your user base, executives and other likely targets. Use the process as a basis for ongoing awareness and security training.

Phishing is a LOT easier and more effective than you might think. We’ve made it easy for you to do, with a free tool called MSI SimplePhish. You can learn exactly how to do it by clicking here.

Pay special attention to this step:

PreCursor: Obtain permission from your security management to perform these activities and to do phishing testing. Make sure your management team supports this testing BEFORE you engage in it.

You might need a couple more ideas for some phishing templates, so here are a couple of the most simple examples from real phishing going on right now:

1. Simply send a non-sensical subject line and the entire body of the message is the phishing url. You might encode this to make it more fun using something like a URL shortener.

2. Copy one of those spam messages that go around where the target inherits 40 million dollars from an oil company exec in the Congo or somewhere. Check your spam folder for examples. Replace the URLs with your phish site URL and click send.

3.  Send a simple music trivia question, which is common knowledge, and tell them to click on the target URL to answer. Make it appear to be from a local radio station and if they answer correctly, they win a prize (movie tickets, concert tickets, etc.)

As a bonus, simply do what many testing vendors do ~ open your gmail spam folder and pick and choose any of the spam templates collected there. Lots to pick from. 

The exercise should be fun, easy and likely effective. If you need any help, drop us a line or give us a call. Until next month, stay safe out there! 

Ask The Experts: Daily Tasks

Posted on by
3

This time around, we get a great question from a reader:

Q: “I’m a one man infosec team at a small financial company, and as such, I stay overtasked. Can you give me a few examples of some key tasks I should make sure I am doing daily/weekly/monthly to make sure I am hitting them all and to help me better structure my schedule?”

Bill Hagestad answered with:

Daily Tasks: 

– Keep self and staff educated about latest cyber threats to your business – read the MSI Blog @ State of Securityhttps://stateofsecurity.com/;
– Review what Federal Law Enforcement considers top cyber threats are base on current cases:
– Compromise of account holder credentials leading to legitimate account compromise;
-Via  phasing attack vectors; unauthorized ACH transfers; 
– Compromise of Third Party Payment Processors;
 
Source: FBI Threat To Financial Sector
 
-Insider attacks – perhaps the largest threat to any commercial enterprise – especially given the recent NSA dilemma via a US contractor
 
– Have staff follow all account verification standing operating procedures – covering all types of customer interaction, including but not limited to; phone, Internet, and in-person account interactions;
– Information Security/Assurance infrastructure configuration changes should be reviewed daily and approved/counter-approved internally to eliminate potential administrative abuses;
– Hold weekly Information Security/Assurance infrastructure team meetings – invite MicroSolved to participate as a credible resource for staff to ask questions of and make sound recommendations.
 
Weekly Tasks:
 
– Stay ahead of international financial sector threat intelligence – read the MSI Blog @ State of Securityhttps://stateofsecurity.com/;
– Ensure account access lists are secure and validated both for external customers (most importantly) and also internal employee need to access/right to access customer account information;
  
Monthly Tasks:
 
– Participate in professional cyber/information assurance mailing lists – if not sure who or what these are contact MSI Cyber Threat Intelligence;
– Be certain to review the US Government Hearing Notes: Cybersecurity: Threats to the Financial Sector downloadable @ http://www.gpo.gov/fdsys/pkg/CHRG-112hhrg72601/pdf/CHRG-112hhrg72601.pdf
– Review or create a cyber threat identification strategy involving key staff and MicroSolved – install HoneyPoint Security Server to capture knowledge about who truly is probing your network, eliminate the proverbial network noise and focus on specific threat actors – e.g.; Russian Cyber Crimianls, Chinese entities using government cyber espionage tools for crime purposes
 
Adam Hostetler added:
It’s hard to answer exactly what you should be doing on a timely basis
without reviewing your current requirements, tools, processes, and
infrastructure. However, If you go to www.microsolved.com and look at
our 80/20 white paper, you can use that as a guideline to give you some
ideas to help build out your security program.

Examples of some things you could/should be doing.

Daily:
Log reviews. Not necessary for all logs, but if you have
IDS/IPS/Honeypots etc, they should be reviewed and investigated if needed
Spend a bit of time following up on the latest security news/threats.
That includes things like new vulnerabilities or exploits, and then
following up if it would affect you.

Weekly:
Check and verify backups and processes

Monthly:
Update software/OS patches.

 
Finally, Jim Klun weighed in with: 
1. Make sure your subscribed to security news-feeds/alerting services that apply to your environment. Review those daily.

2. Make sure you are reviewing your logs daily.  You should know every day about successful and unsuccessful logins. You should also be paying attention to your firewall logs for inbound activity and outbound activity.

3 If you have a local help desk, talk to them at least monthly. They are often in a position to see things that are in fact security problems.

4. Automate your patching program if that is not true already, then review patch reports monthly.

5. If you have Internet exposures, check them monthly. Make absolutely sure at the end of each month you are absolutely sure of what services your organization offers to the Internet – and why.

As always, thanks for reading and if you have a question for the experts, either leave it in the comments, email us or drop us a line on Twitter at (@lbhuston). 

June’s Touchdown Task: EVA Coverage Check

Posted on by
3

The touchdown task for June is to perform a quick and dirty check of your ongoing external vulnerability assessment. By now, you should have your Internet facing systems assessed each month, with weekly or daily checks applied to critical systems. If you aren’t having your systems assessed for vulnerabilities in an ongoing manner, get that process started. MSI can assist you with this, of course. 

But, the task for June is to check and make sure that ALL of your public Internet facing systems, interfaces and devices are being assessed. Sometimes new systems might get added to the public IP space without making it into your assessment plan. Take an hour and check to make sure all the devices you know of are covered by the assessment. Do some quick ping/port scanning to make sure you are getting coverage and nothing has snuck in that is being missed. Give your assessment process a quick review and make sure that it is running on the proper IP spaces or lists and that the reports are as you expect.

Until next month, stay safe out there! 

Guest Blog Post: Less Pwn, More Help!

Posted on by
5

By: Mick Douglas (@bettersafetynet)

The client looked at us from across the table, grimacing as they gulped the foul coffee (sure it’s awful, but hey it’s a free perk!).  They leaned in and said conspiratorially “So can you… umm… sort of… help us get the inside scoop on how we can pass this pentest?” 

I pause and close my eyes for a second.  I’ve heard pleas like this throughout my career.  If you’re a veteran pentester, no doubt you have too.  And what I always think… no matter how large or small the client…  Nobody passes pentests!   It’s their turn to suffer under our boot as we hijack the network and have shells fall down on us like rain.  Nobody… nobody passes a pentest.  There’s always a way in.  Once we’re in, we make their worst nightmares come alive right under their own nose!  No, pentests aren’t for passing.  They’re to be endured.
 
Strong though the predatory instinct is, I must push it aside.  The “pop ’em all” approach — while immensely fun — is not the way of the true pentester.  All too often InfoSec practitioners focus on the technical aspect of the pentest.  If you’re reading this site, chances are good you’re a techie… not a suit.  So unless fate has given you a tour of duty on the other side of the table, you have no idea what hell you’re about to bring to someone who’d rather be doing anything else than deal with you — the pentester.  Things are about to get ugly, and your shell count has nothing to do with it.  You are about to turn their world upside down in ways you cannot begin to fathom.
 
It doesn’t matter if you’re internal, external, a consultant… whatever… you are the enemy.. and not in the way you think.  Sure, you’re the “enemy” as The Almighty Red Team here to cause mayhem and pop boxes.  However, what you might not realize is that the havoc is just getting started once you leave the engagement.  Next to nobody will remember the pivots, the recon, or the OSINT you did.  None of that really matters… What they will remember is that “Jake the InfoSec Guy” failed at his job — miserably. But wait there’s more!  Not only did he fail, but someone — who doesn’t know our systems — was able to use freely available tools from the internet to compromise our entire network!! To make matters worse, it was done in under a week!! It’s a safe bet that soon the client will look at the budget spent on firewalls, AV, IDS, even the salaries — everything — and think “All this spending… for what? They brushed aside our best efforts as if they were nothing more than cobwebs!”
 
If all your client gets out of your pentest is that they’ve got a crappy infosec program, then know what? You’re a crappy pentester.  

You may hate to hear this, but you *owe* your client.  
 
You need to give them a complete assessment which checks for multiple paths to the victory conditions.
 
You need to give them reports which are understandable, actionable, and brief.
 
You need to teach them what you did so they can re-test for themselves.
 
You have to show what’s wrong, but also give them multiple options on how to fix, remediate, or compensate for the findings.
 
You need to offer “quick win” fixes so the infosec program can start rebuilding their credibility after you clipped their wings.
 
You need to give them suggestions on how to alter business operations to better avoid risks altogether.
 
You need to give them a road map on how to get better tomorrow… and the next day after.
 
You need to give and give.
 
Most of all, you need to give them hope.
 

About the Author:

Mick Douglas (twitter.com/bettersafetynet) does R&D, PenTesting, and profesional services for Diebold Inc.  When he’s not doing tech stuff, he’s off in the woods somewhere hiking or trying — mostly in vain — to improve his photography chops.

Thanks to Mick for contributing. I think he’s right on with what we need to do as penetration testers. — Brent Huston