Fear, Trepidation, and Resistance
In our scoping calls, it is not uncommon to sense fear and trepidation on behalf of the buyer or upper management regarding the exercise. Customers resist pentesting for a variety of reasons but a lack of understanding is the prevailing reason for reluctance. We encounter consumers, with the exception of those with compliance mandates, who are often unsure about pentesting or social engineering because of stigmas attached to the terms. This group typically has not invested time educating themselves regarding pentesting services and tend to waffle on testing regardless of type, whether social, physical, or digital. I asked Cimpress CSO Ian Amit to weigh in on the matter of overcoming resistance. In his experience, he has encountered varying degrees of friction and pushback with internal customers around pentesting. He notes,
“At times, pentesting will be seen as a threat to a team/organization since it is designed to expose security gaps. That means that when presented incorrectly, or when the organization does not understand how security should be embedded into their daily operations, the client will try to minimize exposure to testing and to belittle any finding.”
He adds, “sounds familiar?” I can respond in the affirmative. There have been many situations where the client spends time “negotiating” the severity and truth of findings or belittling the need for pentesting engagements altogether.
I count myself in that category among those who have experienced resistance and reluctance to test from management. At the same time, I have been guilty of fostering fear of pentesting. One particular experience comes to mind. My unbridled enthusiasm to introduce phishing exercises into our security program did not achieve the results I envisioned. Rushing in got the best of me. I had leveraged a relationship with a popular social engineering personality to support us in our efforts. The growing popularity of phishing (*phishing being not so new) and related testing services were coming into vogue. Convinced by all the marketing surrounding phishing internal teams, I was confident we needed it and that we would find something interesting about our maturity.
Resistance ran counter to my aspirations. The business did not see the rationale behind phishing employees and targeting them, despite knowing of malicious email campaigns against us. My convincing, conniving, and cajoling of stakeholders mattered little in efforts to get testing buy-in. Our testing partner bemoaned that nearly a year had passed without signoff and threatened to walk away from the project. I could not blame the provider, but at the same time, I was both disappointed and embarrassed. I could not pull off a simple phishing exercise. Human resources and other stakeholders finally decided to move forth with testing, finally swayed by evidence of increased phishing campaigns targeting the company. Human resources took the lead, notifying employees, and setting the stage and protocols for reporting phish attempts encountered during the exercise. The campaign commenced, which included in-context security awareness training and collection of stats. We allowed the campaign to run for an extended period to round out the collection for analysis. End of test. Unfortunately, the results were not shared widely. This would be the first and last time, phishing exercises would be held. The requisite follow up training included in the contract never happened as the commitment to the phishing exercise fizzled. Resistance towards the assessment doomed our desired outcomes from the start. Ironically, not long after the exercise, our company was phished (successfully) as part of a targeted attack against several companies in our industry. A large-scale incident ensued, traced to an employee who was not a participant in the original phishing exercise. Blame, in this case, was not the sole fault of this employee. Our defense in depth game was weak, and our program maturity even weaker. We wasted ample time and effort to stage the campaign, yet fell prey to the very threat we were testing against.
In another scenario, in a different company, we attempted to leverage an existing engagement to add a phishing component not included in the original statement of work (SoW) at my urging. I twisted the arms of a few managers to allow us to move forward with the phishing exercise. I had already gained currency in my role, establishing the beginnings of an application security program, and standing up a vulnerability management practice. I am sure this is the reason I was given a verbal ok to include social engineering testing. As we expected, we saw measurable click-rates and shells on employee devices with screenshots to validate the assessment’s goals. I was quite smug about the results, and the data we collected and the objectives met. However, that sense of pride was short-lived. My manager was less than happy, to say the least, that testing had started. My superior pressed me hard about the test’s initiation, asking who gave the ‘ok.’ I responded, “you did.” To make matters worse, the manager was on the ‘click’ list. Let’s just say the results of that exercise did not see the light of day. We never debriefed to incorporate the findings into the overall report nor modify our risk profile. We also did not use the results to improve our defense-in-depth gaps exposed by the testing. Sadly and most importantly, we never engaged department stakeholders who were largely unaware that the campaign had occurred.
Exuberance and novelty in the grand scheme should never outweigh a practical planned approach to testing. Twisting arms to compel the business to accept testing was a poor tactic then and remain the same today. In neither of the scenarios mentioned, did we start with business requirements nor educate stakeholders. Equally true in both cases, business leaders did not acknowledge the growing reality of their respective threat landscapes. Coordination and collaboration are critical – I know this is preaching to the choir – for pentest and pentesting of any kind. Customer education remains vital in overcoming resistance and friction in engagement. The latest Verizon Data Breach Investigations Report (DBIR) reports a rise in the reporting of phishing test campaigns to keep pace with the prevalence of phishing attacks. Growing awareness and education of phishing attacks seem to be fueling the adoption of testing and less friction.
Still, the industry has a way to go to change the perception of testing as something foreboding. Chris Nickerson and Ian created the penetration execution standard (PTES) to help close the education gap towards meaningful and measurable testing. We applaud their efforts and others to improve overall industry efforts to help consumers embrace testing and mature organizations in this domain. The level of resistance tends to be a good gauge of one’s maturity posture concerning pentesting. CSO Ian offered the following for consideration,
“If we look at the next maturity level of security in organizations, we’ll see teams asking for a test. This typically comes in the context of a major change, a new feature, or an audit they know they’d like to be prepared for. In these cases, there’s much less friction/pushback, and there’s much more acceptance of the findings as the team is driven to be better based on these feedback loops. The real mature teams/organizations want to be tested, and want to be tested “by surprise.” They expect the security teams to include them in their red team engagements and to monitor their production and development activities.”
In our scenarios, which were both first-time phishing exercises, we clearly needed hand-holding and a feeling-out period. We were clearly lacking in maturity and not ready for that first date. In hindsight, the following pentesting readiness checklist would have level set our expectations and allay fears and concerns.
- Provide rationale and context for testing (i.e., Why prioritize phishing at the time over other assessments? Was enough said about the existing campaigns targeting the business)
- Properly prepare employees about what to expect.
- Identifying the potential impact on the business was missed, which in both scenarios centered around ‘shaming’ incurred as a result of testing.
- Confirm identified findings and recommendations and remediate as necessary based on business needs
- Use the scenarios to teach a “Real World” View of an attacker’s ability to “hack” the environment and, in these instances, people to get into environments.
- Apprise the business and board of assessment activities, before the “go and do.”
- Avoid the ‘sounds neat (to do)’ mentality.
The importance of establishing a clear rationale for testing is critical for success for winning over naysayers. After a decade or more of collective experiences, we continue to see missteps in approaching the business to adopt testing rather than fear these activities and see them aligned to business outcomes.
Don’t Rush In
Our team has enumerated several ways towards overcoming engagement resistance. The list also has value for sellers of pentesting whose goals should include educating consumers of expected outcomes that align with business needs.
- DON’T RUSH IT – Don’t pass go until there is business alignment and clearly defined goals for the pentest. In our previous blog, I Want a Pentest, Pt. 1, we stressed the need to train organizations about what to expect from engagements and how to consume output to achieve intended business outcomes. To meet assessment goals, it is important to level-set expectations, educate teams, and handhold teams and staff (if necessary) through the lifecycle of a pentesting engagement. Teams that take this approach, derive the best outputs from pentests. Empowerment through training and metrics should accompany each assessment. Preparedness starts with planning, optics, and pretexting, so there are no surprises (especially for first-time consumers of testing services). Clearly, I rushed past these measures in both scenarios above.
- PLAN FOR INTERACTION – Both scenarios above lacked engagement on the testing side with those subject to the phishing exercises. Iterative interaction stopped at the point of testing, effectively limiting the value of the assessments. Each test must really be interactive from start to finish to achieve the highest value, including post-assessment conversations and updating of risk profiles based on the results.
- ALWAYS “Ride-Along” – Do the ride along with the pentester to see it live and gain invaluable insight. The ride-along experience improves defense in-time and remediation efforts. This is a continuation of the interaction described above. Teams that are core to various testing, whether tied infrastructure, messaging, physical examination, all should ‘ride-along’ with the testing team to learn, grow, and become empowered in the maturity of an organization. This is an effective way to scale a team’s knowledge of handling threats/incidents rather than waiting for them to happen. Ride along helps develop the memory muscles needed for a robust, active, and ingrained defense.
- Connect to the REAL impact (shells don’t matter) – In the latter scenario, I was geeked/amped/excited to see shells that were the end result of a successful phishing campaign. However, that was my team’s but not one tied to a business outcome. Goal-Oriented assessments are preferred to achieve the highest value, but the end game does not consist of ownage, shaming, and takedown. Instead, the Goal-oriented testing continues o into the post-assessment activities where teaching, education, and equipping teams occurs.
- GO FULL SCOPE – We did not go hold back. Scoped broadly and adjusted in real-time. The only problem was that no one was aware. We champion full-scope, where possible, as long as business needs fuel the breadth and depth of the scope.
- Attack like an Attacker – We achieved this objective in both scenarios. We did not account for the ‘shame factor’ we caused by not preparing the organization adequately to walk through an exercise where you are targeted to test preparedness. We ended up impacting morale rather than empowering teams to withstand the attack method(s) employed.
- Allow defensive blocking PROVE YOUR DEFENSE WORKS – It’s not a test unless your defense is vetted (see I Want a Pentest, Pt. 1). In hindsight, our messaging teams and other stakeholders should have had ownership in the exercise to improve their defense chops. We missed an opportunity to enhance our defense capability. We didn’t plan for their participation in the phishing test and, as such, those groups did not figure prominently in the testing – another missed opportunity to empower internal teams.
- Hold your testing company accountable! – Establish accountability. We have discussed this issue at length. Both scenarios began without establishing accountability. Success was impacted at the onset due to a lack of business input and visibility. A couple of lines of accountability were overlooked – two-way accountability between the consumer and the assessor and similar responsibility between security stakeholders and the business. In the former case, I failed the 3rd party partner by overselling our organization’s readiness to take part in the phishing exercise.
Win Over The Resistance
The adage “fail to plan is planning to fail” holds true in prepping for a pentesting exercise. It remains unclear who the quote should be attributed – Winston Churchill or Benjamin Franklin – the advice remains relevant today. Plan, plan, and plan again to offset resistance at the outset of the engagement and increase the value from a pentest or continuous assessment. Perform the due diligence in the scoping phase to overcome unwarranted opposition to your program objectives. Better yet, take the necessary steps to win over your team and stakeholders to the positive aspects of testing and how valued pentesting matures ability to defend and operate with greater efficiency.
I would love to hear your thoughts on your experiences to win over resistance or challenges you have had or may be having. We would certainly be happy to hear from you. Please feel free to reach me at firstname.lastname@example.org. Cheers.
Mark Arnold has a 15+ cybersecurity career, serving 8 of those years in leadership roles. As a transformational leader, Mark has built security teams and programs, authored maturity model blueprints to optimize risk management processes, and implemented security domain practices at large enterprises and service providers. Mark’s areas of interest include cloud security, threat intelligence, and vulnerability research, nation-state attack methods and related activities (e.g. information operations and disinformation campaigns) and their collective impact on nations and society. Mark recently completed an executive education cohort on the intersection of cybersecurity and technology at Harvard’s Kennedy School.