I constantly see security practitioners talk about and worry about threats that will never affect them. Defensive teams have their threats horribly misprioritized, focusing on events that are unlikely to occur while ignoring likely threats.
Let’s define an insider well: An insider is a malicious employee or contractor that has already been given a foothold due to their employment. Insiders can be foreign or corporate spies, human intelligence sources (read blackmailed or incentivized), or disgruntled employees.
This type of threat is real if you’re Google or one of the largest hedge funds in the world. If you have less than ten thousand employees or are worth less than 10 billion dollars or have less than 1 billion dollars in assets, you can completely forget about this threat. Sorry to burst your bubble, but you’re just not worth it. Especially when cheaper and more effective attacks are going to work against your organization on the first try.
In the case of a disgruntled employee, you can’t lean on cost as a defense, but deterrents like prison time, fines and legal fees, bad press, and negative references are usually enough to stop an employee from committing a crime or behaving unethically.
Vulnerabilities in Custom Software
Most technology organizations start their security program off with product security, which seems to come from a good place, but is often misguided by industry standards and customer requirements. Popular technology organizations brag about their product security teams and customers want to see a penetration test report during vendor review simply to ensure that an organization cares about security.
But this is completely backwards. Most web applications and products don’t have the market share or value to justify offensive vulnerability research. And even if your product did have the market share or value, chances are that it’s easier to pop the organization or the customer via cheaper and more effective methods.
You can skip your product security program or have an engineer run it part time until you’re a bigger target. As a customer, if you want to see if your vendor really cares about security, ask about the size of their security staff relative to the rest of the organization, ask about their continuous monitoring, ask about their data governance policies, and ask about their incident detection program.
0-Day Vulnerabilities in Commercial Software
A 0-day vulnerability is a previously unknown issue. Once the vulnerability is used, made public, or patched, it is no longer a 0-day vulnerability. Often, this means that adversaries get a small window to use these vulnerabilities effectively. And often, discovering a 0-day vulnerability is very expensive.
Everyone loves to worry about 0-days because they are sexy. They are unknown unknowns that could be preventable. Every security team longs for the day where their security program stops the unstoppable.
The fact is that over the last 10 years, using 0-day vulnerabilities have become cost ineffective. Improvements in exploit mitigation in popular targets like Internet Explorer and Adobe Reader and the phasing out of Flash and Java have rendered these targets safe from unknown vulnerabilities. Especially, when there are cheaper and more effective threats available for adversaries.
Remember that attackers care about efficiency. When they can use the cheapest and most scalable attacks, they will. When they can reuse attacks, they will. As long as they can meet their objectives. When it comes down to it you probably aren’t that important, so you should focus on the most likely, most common attacks to prevent your organization from getting swept up in an opportunistic campaign.
Start with the basics. Put controls in place to combat common phishing attacks. Implement a mail gateway and collect DNS analytics and web traffic for incident detection.
Prevent commodity malware and off-the-shelf office macros with an Endpoint Protection Platform.
Focus on password reuse. Enforce use of password managers, do frequent password audits, and monitor other breaches.
Watch your third-party vendors and partners closely. Enforce strict data boundaries, segment networks and access, and constantly review high-risk vendors and partners.
Attacks happen on user endpoints. Collect telemetry from your endpoints, like process trees, Powershell commands, and network traffic. Make sure all your data is easily correlated and searchable.
Build incident response. When something happens, you need a way to prevent it from becoming a breach. Focus on smart ways to detect maliciousness and orchestration to prevent escalation.
Keep systems patched and monitor for new vulnerabilities. Unknown vulnerabilities are expensive but patched vulnerabilities can be cheap, especially if an exploit has been made public.