Security Experts:

How Self-Doubt Can Keep Your Security Team Sharp

 A Healthy Sense of Self-Doubt Can Go a Long Way Towards Avoiding False Negatives

We’ve all worked with people who are overconfident and cocky. I used to work with one particularly egregious example of this personality type. He would routinely take indefensible positions, make grandiose statements, and even threaten consequences if others did not do what he demanded.  When I was first exposed to this behavior, I too was convinced by his certainness. I got wise to the behavior over time, as I saw him retreat with his tail between his legs time after time when someone called his bluff.

Why am I sharing this with you?  As you may have guessed, there is an information security lesson we can learn from this.  In security, we need to be sure we know how to successfully mitigate risk continually amidst a changing threat landscape.  We also need to gain the confidence of our customers, partners, peers, executives, and other stakeholders.  That being said, being overconfident in these areas can be quite dangerous. In other words, a healthy dose of self-doubt can go a long way towards keeping us on our toes and continually improving the security posture of our respective organizations.

How so? I offer five ways in which a healthy does of self-doubt can keep your security team sharp.

1. Investigating alerts: Many security operations teams have a well-defined work queue that they work out of.  Alerts fire, tickets are opened and assigned to analysts, analysis is performed and documented, and the event is either closed or marked for escalation or further investigation. A healthy sense of self-doubt can go a long way here towards avoiding false negatives. How so? Here are a few ways:

a. Before I rejoice in the fact that the alert queue is empty, am I sure that I have the proper alerting?  If not, I may pay later for what I don’t see now. In other words, I can’t handle an incident that I haven’t seen and that doesn’t appear in my work queue.

b. Before I close the alert as a false positive, am I absolutely certain that I am looking at the alert objectively with as little bias as possible?  If not, that may influence or sway my initial analysis.

c. When I perform analysis on a given alert, am I doing so objectively? Am I ensuring that any conclusions I draw are supported by the facts and evidence?  It sounds obvious and straightforward, but in practice, this is actually quite difficult.

2. Assessing threats:  In an ideal world, a security team would have a solid handle on the top threats that its organization faces. That security team would then go about instituting protective and detective controls to monitor for those threats. Unfortunately, the threat landscape changes so quickly, that it is nearly impossible to stay out in front of it. A near constant game of catch up is required, the result of which is that some threats are invariably missed. Further, even when an organization has a good handle on the threat landscape, it may struggle to implement the proper protective and detective controls.  There may be many reasons why this is the case, though technology and resource limitations are often two of them.  A security organization that is humble and self-aware here can take steps to work around these challenges. If a security team is too cocky, however, they won’t be able to.

3. Assessing risk: Security is, essentially, a risk management profession. Any good security program maintains a risk register and seeks to manage, mitigate, minimize, and monitor those risks on an ongoing basis. But how can an organization ensure that it has not missed any critical or key risks? There are a number of different frameworks and methodologies that an organization can apply to help with this. But guess what?  None of them work as well on an over-confident security organization. The security team that is constantly worried that it has made an oversight is the team that will most successfully mitigate risk.

4. Institutional knowledge: Do you know where all of your ingress/egress points to the internet are? Do you have a good handle on the assets within your organization? Do you trust your vulnerability, patching, and compliance numbers? Are you comfortable with the risk that your third parties introduce and the way in which they connect to and access your enterprise? Do you have a good handle on application security and penetration testing? How about Identity and Access Management? These are just a few items in the realm of institutional knowledge, but I’m sure you see my point by now. Perhaps it is naive to be over-confident when answering the above questions and others like them. A healthy dose of insecurity can go a long way towards helping an enterprise ask the right questions, answer them accurately, and ultimately, understand itself far better.

5. Policies, processes, and procedures: Do you have the right policies, processes, and procedures across your security program? That includes, at a minimum, the formal steps required to handle the above points well. As you’re likely aware, I’ve only scratched the surface in this column. Taking a step back and having the humility to objectively assess and evaluate the strengths and weaknesses of your security program with as little bias as possible pays huge dividends. This requires the desire to improve and the self-doubt to facilitate that improvement.

view counter
Joshua Goldfarb (Twitter: @ananalytical) is currently Director of Product Management at F5. Previously, Josh served as VP, CTO - Emerging Technologies at FireEye and as Chief Security Officer for nPulse Technologies until its acquisition by FireEye. Prior to joining nPulse, Josh worked as an independent consultant, applying his analytical methodology to help enterprises build and enhance their network traffic analysis, security operations, and incident response capabilities to improve their information security postures. He has consulted and advised numerous clients in both the public and private sectors at strategic and tactical levels. Earlier in his career, Josh served as the Chief of Analysis for the United States Computer Emergency Readiness Team (US-CERT) where he built from the ground up and subsequently ran the network, endpoint, and malware analysis/forensics capabilities for US-CERT.