Rapid7 Blog

Insiders and Outsiders in Security

POST STATS:

SHARE

“Those fools. They didn't even bother to do X. And everyone knows you have to do X.”

If you've been in Infosec for even a short time, you've seen this sort of statement, whether explicit or implicit, about something in the news. It comes up often after a company has suffered a breach. And it's often true. The company should have done X. Everyone knows you need to do X. Even my dad knows that. But then again, the security people making these comments often work at companies that really should be doing Y and Z, but may not be. What is it that makes people feel they can criticize others while not having their own house in order?

I've also noticed a few examples of executives being grilled by government officials. The line of questioning is harsh and with no wiggle room. The questioners only want to know about the state of security, and are not interesting in hearing comments about the level of difficulty to make things secure, or how programs are now in place to address the issues.

This gap between the viewpoints of insiders and outsiders is hugely important, and will be more so in the future.

Outsiders might be members of the press, commentators, Twitter accounts, regulators, or opposing counsel during a shareholder lawsuit. They may be schooled in security matters, and may even be security experts. Or they may be non-technical people who reuse passwords, but will point fingers at you when you failed to implement a robust PKI key management scheme on your complex multi-national WAN.

But it doesn't matter. Their position is what it is. And it's hard for the defenders on the inside to see eye to eye with the outsiders. Here are a few of the differences I've noted.

Insiders measure effort. Outsiders measure outcomes.

Insiders understand that they must find a way to do more with less. Outsiders look at how the attacker succeeded.

Insiders prioritize against many possible outcomes, breach scenarios, and black swan events. The actual crisis may not look like the ones theorized. Outsiders have 20/20 hindsight and ask incredulously how it could have happened.

Insiders focus on the many things that went well. Outsides focus on the one thing that went wrong.

Insiders know it's hard to hire security talent, and hard to change an organization's business practices to be more secure. Outsiders look at a failure of management to make security a priority. Period.

Insiders know it's hard to get management attention without sounding alarmist and like fear mongers. Outsiders wonder why the security team didn't escalate on a daily basis.

Insiders know that security budgets are not limitless, and the security team has limited influence whenever people feel they are slowing the business down. Outsiders know that without trust of your customers, you have no business.

Insiders know you can't log everything. Not every packet, netflow record, OS log, and app log. That would be too expensive. Outsiders point out that disk is cheap, even at scale. They point out that your lack of forensics data increased the time to respond and recover after the breach was detected. And that there are still lingering questions about how the attack happened. And that it would have been cheaper to buy the disks to support the logs than to deal with uncertainty.

Insiders know it's nearly impossible to keep tabs on all the machines at the company. Outsiders point to the one orphaned machine that was attacked and think you should have known.

Outsiders will ask what went wrong. Then they will ask what you are doing to prevent this from happening again. When you tell them, they will respond by saying “Well, then that's what you should have been doing all along”. This is a key element of the insider/outside friction.

Insiders look for a root cause analysis. Outsiders will look at superficial symptoms. When they give guidance to the insiders, it can generate more friction if the insiders think they are being tasked with fixing symptoms rather than causes.

Insiders know that you have to allow employees the right to bring their own devices onto the corporate network to be productive. Outsiders know that the cause of your breach was caused by an unmanaged employee device, and that it was completely foreseeable and preventable.

As in many of the examples above, the divide between insiders and outsiders is shown after a breach. This “before and after” analysis offers the most striking examples of this divide.

If you are caught in a line of questioning from an outsider, how will you answer their pointed and loaded questions? Some questions can be all rhetoric, and even attempting to answer can cause more issues. Questions might include variations on the following.

Why was this group of users exempt from 2FA policy for so long?

Was it a policy to ignore warnings from your SIEM?

Why did you allow source code on laptops, knowing that's a common exfiltration path for criminals?

Why did you prioritize the convenience of your employees over safeguarding the trust given to you by your customers?

If the data had no immediate value to the company, and only had value to criminals, why did you retain it rather than deleting it?

Given that the excessive access rights for this one user were abused by the attackers, what process had you gone through to prevent this exact attack path? How exactly did you fail?

As a security professional, you know that most attacks involve the exploitation of known vulnerabilities. Please explain again why you failed to guarantee software updates on so many systems? After all, that's job #1 for reducing risk. Do you disagree?

You said you prioritized the desire of the sales/business development team over the concerns of the security team. How are your sales/growth numbers looking since the breach?

Knowing that executives are prime targets for cyber criminals, why did you allow them to opt out of software updates and phishing training?

Explain why you allowed a network design to include unsecured connections to remote offices that failed to meet your own written security standards?

Given what we know about how valuable customer and employee data, and reading about all the other similar attacks in the news, can you explain why you failed to encrypt the customer and employee data?

You admitted that the machines in the attack path were no longer used for much; that they were orphaned, not managed, and unpatched. And yet you failed to remove this obvious risk from your network. Why?

Why was this not raised to the CEO? (or if you're the CEO: Why did you not take appropriate action?)

Why was this decision made at the Manager level rather than the VP level or by the CEO?

You claim you spend millions of dollars on your information security program. Do you think you got your money's worth?

Some questions are much more pointed or slanted than others. But if you were asked these questions, perhaps in public or under oath, would you feel good about your answers? Would you feel confident in not just your efforts, but in the results? Would outsiders feel you did the best you could, or would they feel that you hadn't taken security seriously?

Have a story for me about being judged by outsiders? Drop me a line on Twitter at @boblord. If you want to remain anonymous, send me a DM. My settings allow you to DM me even if I don't follow you.

SHARING IS CARING

AUTHOR

Want more? Don’t miss these posts

There’s been a lot of industry buzz around Docker recently, with particular focus on its ability to streamline how companies manage their platforms. With all this talk, you might be wondering how easy it is to set up Docker and evaluate it for yourself.…

Investigating incidents is a tough challenge. It's like solving a 100 piece jigsaw puzzle with a million unarranged pieces on the table. We must first identify what's relevant, and only then start to piece the disparate information together into a coherent picture. This requires a…

Featured Research

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Toolkit

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Featured Research

Rapid7’s Quarterly Threat Report leverages intelligence from our extensive network—including the Insight platform, managed detection and response engagements, Project Sonar, Heisenberg Cloud, and the Metasploit community—to put today’s shifting threat landscape into perspective. It gives you a clear picture of the threats that you face within your unique industry, and how those threats change throughout the year.