Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives //

Carbon Black

8/31/2016
08:02 AM
Ben Johnson
Ben Johnson
Partner Perspectives
Connect Directly
Twitter
RSS
50%
50%

Cybersecurity Self-Esteem: 4 Things Confident Teams Are Doing

By increasing our cybersecurity self-esteem, we can truly make a difference in raising our collective cybersecurity resiliency.

Security teams need to hear a public service announcement. "Believe in yourself. Have confidence. You can do it!"

It may sound corny, but it's true. I've spoken to more than 600 organizations -- from mature businesses to entry-level startups. What I’m noticing is that many of these cybersecurity teams -- from Singapore to Silicon Valley - do not have good self-esteem right now.

Believing

Progressive security teams are advancing largely because they “believe.” They believe they can improve their postures; believe they can achieve some form of resiliency; and look at their battlefield with an engineering mindset. Other security teams aren't faring so well. Too many practitioners give others too much credit and not enough to themselves.

I see and hear low self-esteem all the time:

"Oh, but our team isn't advanced."
 "Yes, but we're not software engineers."
"Our budget isn't as big as theirs."
 "We're already overwhelmed with AV alerts."
 

While I understand why these teams think they cannot change their own status-quo, they are wrong. They simply don't realize what they're capable of. They give up at being transformative or at moving to a higher maturity level -- often without much of a fight.

Wasting Time

A lack of cybersecurity self-esteem leads to wasted "security time." We've already said we don't have enough people, so why do we fail to optimize how our teams spend their time?

We should be looking at getting the greatest return-on-investment from security time. Does your team do any of these things:

  • Repeatedly respond to false alerts? 
  • Manually conduct lookups to see when a domain was registered? 
  • Fight with committees to get ports opened for your security tools? 
  • Sit in meetings that really don't require them to be there?

I see all of these way too often. Security teams are often not able to use their time most effectively. And so we fail. The adversary goes undetected. Tools aren't configured properly. Valid alerts get lost in the noise, or the hunt to find that evasive intrusion never happens. Then the annual security reports come out reflecting detection and response times in months rather than minutes. This has to change.

Building Up Our Confidence

The silver lining here is that we can build up our confidence. There are success stories. There are teams with 100,000 computers and only two FTEs that are finding and eradicating evil, and doing it in more and more automated ways.

There are companies that send their employees with little more than a laptop into countries where cyber hygiene hasn't yet become a trend, and these teams are able to find threat signals. There are teams of one or two people at banks that are continuously improving their posture so much that the red-teams are frustrated.

None of these teams are perfect, but they are progressing and raising the bar for their adversaries. Here are four things I’ve seen confident teams do successfully to help build their cybersecurity self-esteem:

  1. Extend an olive branch to IT: While you might not be enemies with IT, you probably don't have the best relationship. IT is the ultimate provider of security, so the more you can leverage IT to have gold images, setup proxies, use whitelisting of domains, URLs, and applications, and restrict user accounts, the easier your life will become.
  2. Make security a team sport: Can you get employees excited? Can you leverage that excitement so that each user is more vigilant, more cautious when doing things, and more willing to give up some freedoms such as installing random software or visiting certain websites? This vigilance goes a long way in reducing the number of threats and noisy events that clog your analysis systems.
  3. Pick a tool or technology and leverage the hell out of it: Teams have too many tools, too much information, and are overloaded with defensive "weapons" and information. Pick one type of log or technology and become experts in it. Use every feature. Leverage every alert or log and tune it to make sure the ones you don't need to see are no longer sent. Push it to its limits. Then move on to the next. You'll find that you really only need a handful of tools or logs for most of your security.
  4. Empower your team: Make hunting a perk. Empower your team to go find stuff and reward them for their time spent “outside the box” of responding to alerts. Get the team to take pride in their security posture. Be sure to keep meetings and other non-essential items to a minimum so your team feels like the Special Forces they are. Unless a meeting or task is vital, keep them in the game while they're on the clock. Then let them disconnect and rejuvenate. This will pay dividends for your organization and will also help with retaining employees.

There's a huge "can't do" attitude that’s plaguing security teams. This attitude arises because security leaders and practitioners have hit too many walls, often made of human flesh. It's time to stand up and say: “No. This is our environment. We are going to protect it.”

We may never be perfect, but we can do better. By increasing our cybersecurity self-esteem, we can truly make a difference in raising our collective cybersecurity resiliency.

Ben Johnson is CTO and co-founder of Obsidian Security. Prior to founding Obsidian, he co-founded Carbon Black and most recently served as the company's chief security strategist. As the company's original CTO, he led efforts to create the powerful capabilities that helped ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
The Problem with Proprietary Testing: NSS Labs vs. CrowdStrike
Brian Monkman, Executive Director at NetSecOPEN,  7/19/2019
RDP Bug Takes New Approach to Host Compromise
Kelly Sheridan, Staff Editor, Dark Reading,  7/18/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-14248
PUBLISHED: 2019-07-24
In libnasm.a in Netwide Assembler (NASM) 2.14.xx, asm/pragma.c allows a NULL pointer dereference in process_pragma, search_pragma_list, and nasm_set_limit when "%pragma limit" is mishandled.
CVE-2019-14249
PUBLISHED: 2019-07-24
dwarf_elf_load_headers.c in libdwarf before 2019-07-05 allows attackers to cause a denial of service (division by zero) via an ELF file with a zero-size section group (SHT_GROUP), as demonstrated by dwarfdump.
CVE-2019-14250
PUBLISHED: 2019-07-24
An issue was discovered in GNU libiberty, as distributed in GNU Binutils 2.32. simple_object_elf_match in simple-object-elf.c does not check for a zero shstrndx value, leading to an integer overflow and resultant heap-based buffer overflow.
CVE-2019-14247
PUBLISHED: 2019-07-24
The scan() function in mad.c in mpg321 0.3.2 allows remote attackers to trigger an out-of-bounds write via a zero bitrate in an MP3 file.
CVE-2019-2873
PUBLISHED: 2019-07-23
Vulnerability in the Oracle VM VirtualBox component of Oracle Virtualization (subcomponent: Core). Supported versions that are affected are Prior to 5.2.32 and prior to 6.0.10. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox...