Category Archives: Security Management

Giraffes, Ostrich and Six Mental Health Survival Skills for New Cyber Security Managers

Giraffes can’t talk, but if they could they’d tell you they were tired. Really tired. You see, giraffes are so consumed with being on the lookout for predators they have evolved to only sleep for a few seconds at a time. They have to continually wake up and look for predators thus missing out on some of their basic requirements.

Ostriches, I suspect are much happier. They live an abyss of ignorance where at the first sign of a predator they can put their head in the sand and have nothing to worry.

As a Security manager, you don’t really have the luxury of being an ostrich. We are continually bombarded with an unpredictable amount of audit findings, intrusion detection alerts and vulnerabilities that have to be addressed within a set budget and headcount. The challenge is that finding will always happen at a faster rate than fixing giving you a never-ending list of top priorities. This pushing the rock up the hill can lead to job stress and burn-out.

Over the years I have developed some giraffe survival skills that I’d like to pass along to you folks new to security management:

  1. Know your risks. If you don’t have a deep understanding of your organization’s risks you will never be able to properly prioritize your work and everything will become your #1 priority.
  1. Don’t get distracted by low hanging fruit. A quick fix often feels like a quick win. But if you continually focus on low-value activities you’ll never tackle the important stuff and never actually make progress. I know, this runs counter to every self-help book ever written.
  1. Embrace the messenger. As hard as it is some days to have one more issue come across your desk, when people stop coming to you you’ve lost the battle.
  1. Network with other Security people. No matter how well you work with the rest of your non-security colleagues they’ll never understand what it’s like to know what you know and carry the responsibility.
  1. Work where you’re wanted. I don’t care how good you are, you won’t be successful implementing security at an organization that doesn’t want security.
  1. Have realistic expectations. Know up front you can’t fix everything, and what you can fix takes a long time.

(Cross posted to

Pen Testing is Dying- Here are the Six Things that are killing It

Don’t all kill the messenger at once but the sad truth is there are a growing number of organizations that are not seeing the ROI in pen testing and I’m afraid they have good reasons.

There is a concept in organizational behavior about there being two reasons for a culture’s behavior- the reason they give you when asked and the answer that is not verbalized.

When leaders are asked why they are decreasing their spending on pen testing the answers I am hearing sound very reasonable- the attack surface is too broad, the number of attack vectors has grown to an untestable number, etc etc. No argument here.

However, I would argue that there are also some other, probably bigger reasons that have a larger influence that do not get verbalized. In fact, I think there are six of them.

  1. Supply and demand created a shortage of skilled testers

The security boom we’ve all been enjoying has created a huge need for security professionals.  As a security professional I’m loving it. However, like all skills shortages there is a vacuum moving the bar for “senior level” down lower and lower. What was once considered an intermediate level tester is now considered a senior person.

This is a reality that has no good answer. Personally, I prefer to have testers who have their OSCP certification but with supply and demand this has become a luxury, not a baseline.

  1. Confusing automated assessments with pen testing

I find that the actual definition of what a pen test is has been evolving and some of that evolution seems to parallel the supply and demand issue. What we used to refer to as automated assessment tools have now become the pen test. Scanning a target with nmap, Nessus and Burp and pasting the results in to a template is not a pen test. There is certainly value in these activities as one of many parts of a holistic assessment but calling it a pen test has diluted the value of the term.

  1. The Rules of Engagement for pen tests typically protect the weakest link

Pop quiz- name a recent major breach that didn’t involve a targeted email as the point of entry? Yea, me neither.

However, most pen test will have rules of engagement prohibiting spear phishing employees and the use of backdoors. I strongly suspect the perception of a pen test report would jump in value if it contained screenshots from the meterpreter session running on the CFO’s laptop while he transfers funds between banks. There are some really good reasons pen tests can’t mimic real life attacks but because of this their value is reduced.

  1. Length of engagements do not match real life

Another aspect of pen testing that doesn’t match real life threats are the length of engagement. In real life attacks, the bad actors don’t have a time limit. They can spend months or even years on their target. In a pen test, the tester has a week or two to do his assessment and write up the findings. We can’t expect a team of testers to be able to cover all possible vectors in a few weeks.

  1. Lack of incentive.

Billable hours pay your bills but they don’t exactly light a fire under an analyst’s rear end. I’ve often wondered what an assessment would look like if the client set up a pen test like a bug bounty, providing the team incentives for what they found.  When a team of bad actors operating out of Eastern Europe can retire after one big score and you have pen testers working for billable hours there is a motivation mismatch.

  1. Pen Testing to Check a Box for your Auditor

For a pen tester to do a great job they need to be able to follow where their findings and instincts take them. A “pen test by numbers” will appease a requirement but unless it’s done with passion and purpose it’s not going to be great.

 Do I think pen testing is still valuable? Absolutely. But for all of the reasons above I think it is getting a bad rap. Disagree with me? I’d welcome your thoughts. @CyberSecOlogy #pentesting. Contact me via the form below:


Incident Response Plans for our Careers?

At the recent “Security Summer Camp” in Vegas I got to chatting with a guy who was employed as an intermediate-level security analyst. As we discussed our backgrounds he reluctantly disclosed that he had been a former Info Sec executive. Doing my best to not pry I hinted about why an Exec chose to be an analyst fully expecting to hear that he missed having a technical role, something I struggle with frequently.

His story, however, had nothing to do with a need to return to the trenches. He had been responsible for security at a company that had a semi-famous breach. As he explained it, once his name had been tarnished by the breach he could not find anyone to take a chance on him. He referred to himself as “damaged goods.”

As a sad piece of short-sighted irony, after talking to him I can tell you there is no one who has thought more about breach prevention than he had. His perseverating on the incident in the months following gave him a remarkable insight that any organization with digital assets to protect could benefit from.

After we parted and went our separate ways it occurred to me that while we work hard to create incident response plans for our organizations we do little about an IR plan for our career should an incident leave our names tarnished.

While a termination may not necessarily constitute an incident, the weeks following this person’s termination clearly met the criteria. His initial assessment of the damage to his career was dire. He was losing LinkedIn contacts daily and his calls to his peers were not being returned. He had never planned for such an event and the incident and termination left him too beaten down to take much action. In essence, he had failed to have an incident response plan for his career.

Feeling isolated and shunned, he wanted to reach out to key contacts. However, with the intensity of building his career he failed to form friendships within the profession and had certainly never discussed this type of situation with any colleagues. In essence, he had failed to create his incident response team.

The interaction left me wondering- in Info Sec are we too quick to label someone as damaged goods once their organization has been breached? While we put plans in place to respond to reputational damage to our organizations do we also need plans for our own reputations? In this post-Google world should we think of ourselves more as brands than a workforce pool?

The story you have just read is mostly true. Some details were changed to protect the innocent.



Being in Cyber Security is a lot like being a goalie in soccer- no one remembers all of the attacks you blocked but they never forget the one you missed.