While I think most information security professionals understand that you can’t fully secure a network, this doesn’t stop many of them from dispensing advice or operating under philosophies that I consider to be ineffective or simply not true. Any good penetration tester or grizzled incident responder can tell you that even the best defenses have gaps and that clever attackers will find ways to get to their target- regardless of how much an organization has spent to protect itself. Being one of the grizzled incident responders myself and having seen numerous things most people haven’t- or have only read about in an article- I thought I’d share some of the favorite statements that make me shake my head when I hear them. Keep in mind there are many more, but I was trying to stick to a “top 10” list.
1. Focusing on prevention adds greater value than spending resources on detection & response.
Ben Franklin once said, “An ounce of prevention is worth a pound of cure.” and unfortunately I hear this a lot in the InfoSec field- but I think most folks miss the point.
First, prevention tools are based on code and designed by humans- so are subject to failure and can actually increase your attack surface (e.g. recent FireEye vulnerabilities: http://bit.ly/1zqnsY7).
Second, prevention tools have been around for countless years and while they haven’t always been, “Next Gen”, they certainly haven’t stopped attacks from continuing and being successful.
Third, no tool stops or identifies 100% of badness if you dig into the details and test yourself- you could argue defense in depth at this point, but generally organizations don’t have redundant tools that provide the same coverage, in the event the first/second/third tool fails to stop it.
Considering that a motivated and savvy attacker will find a way around prevention tools, I’d argue that overweighting on the Detection & Response aspects is the smarter security and prevention strategy. Being able to identify an intrusion within minutes and contain it as quickly as possible is better capability than most prevention tools on the market can ever provide. You wouldn’t expect a military base to just build walls around its perimeter and not have any guards or patrols- and neither should your company. Finally, just because an intruder is on your network does not mean they have won.
2. You need to understand the data and also where it resides to properly secure it.
It’s hard to argue with understanding what the data is at a high level- because that is a good practice that is easier to say than do- but that fact alone does not help you protect it. While you could argue that knowing where your most important information is allows you to design specific controls around that information, we’ve already established that prevention will be bypassed at some point, leaving us with detection and response. This is not to say that designing an enclave is a bad idea- but it is nothing more than additional layers of security that may slow down an attacker- it will never be “hacker proof.” Also, if you design solutions that leave you blind to your less-important information and wait until attackers go after your top IP, you allow them to gain a foothold in your network and miss opportunities to expel them before things escalate. This plays directly into the “where it resides” comment as well- your data is everywhere. On a mobile device, on a laptop, in the cloud, on a vendors network (have you asked them if they were breached lately?)- this problem will only get worse and trying to understand where all your data is, is a lost cause*.
*As a disclaimer, I’ve heard of some interesting start-up/stealth companies right now looking to tackle this issue (not with DRM), so the field may change down the road on this.
3. I just paid $500k+ for a SIEM, so I can now find incidents!
Implementing a SIEM with default rulesets is significantly different than finding true evil on your network- and preventing, finding and responding to evil is what Information Security should be about- not checking compliance boxes. Additionally, if you have ever “turned on a SIEM”, you know that you’ll quickly be inundated with events firing and unless you’re enhancing the SIEM with targeted intel feeds, I would argue that you will very rarely, if ever, identify true evil. While I understand the concept of check-box compliance, Information Security Leadership who continues to make decisions to meet the bare minimum are only perpetuating the trend of compliance which has been proven fruitless time and again. As an ex-Auditor, I’d give higher marks for Leadership bucking the status-quo and implementing a program to find actual evil in the network as opposed to simply turning on an appliance because of poorly written regulatory requirements.
4. Having a breach will have a huge impact on your business viability!
Time and again we’ve seen big name breaches and time and again those companies continue to move forward and in some cases post record profits. I think this line of thinking is fear mongering at best- the better vendors look to solve business problems and challenges, not introduce unneeded FUD. I also wrote about this recently here.
5. Attribution doesn’t matter.
Even I believed this many years ago and thought the power-points with pictures of adversaries and their families was nothing more than an analyst with too much time on their hands. I’ve changed my beliefs dramatically and now believe that attribution and understanding your threat actors is the cornerstone of any successful IT Risk strategy, let alone the cornerstone of any successful intel/detect/respond (IDR) program. An organizational IT Risk strategy should not be based around products or perceived attacks such as “Man In the Middle” or “Watering Holes” or any other buzzwords- but should be based on securing the network from the actors that are actively trying to infiltrate and exfil that which you hold most valuable. The reality is that budgets are finite and spreading yourself too thin by not understanding your attackers TTPs is a losing proposition. Its no different than an NFL football team understanding their opponents over the course of a season. If you know you’ll be playing the majority of your games against high powered passing offenses- you’ll spend your resources and design your defensive schemes to combat that. Knowing that you can’t plan for every single scenario, you’ll just have to do your best the one week you play Adrian Peterson and his rushing attack.
6. I just need to be more secure than the other guy, so they won’t target me.
I actually had a CISO of a Fortune 150 company tell me this while working with him after a targeted attack of their company. He must have gotten done watching “Without a Paddle“, because it reminded me of just having to outrun your friend when a bear is chasing you. Nation state attackers will keep coming after you until they acquire what they have been tasked to retrieve, regardless of your level of security investment; chances are good they will come back later as well looking for updates.
7. I only need to worry about securing my own network.
Have you stopped to consider all of the places where your data is? Chances are high that you may be involved in JV’s, partnerships, etc… and your data is scattered in the networks of countless other companies. While I’m not recommending that your main priority be to protect those other networks- a good information security leader will recognize this challenge and spend the time to work with those partners to practice better holistic security. Consider that if an organization other than yours gets breached and your data is compromised, you may never know about it or have any input into what happens. Take the time to plan upfront.
8. Only the IR team needs to know about incidents.
Unfortunately I’ve seen that more often than not, an incident will occur and instantly OPSEC is front and center with nobody wanting to divulge information to any other internal person, team or organization. This is a flawed way of thinking. There should be a continual feedback loop where incidents are dissected and put in front of the Design/Plan/Architecture teams to not only educate, but to solicit assistance in better protecting the network going forward. Only by understanding your past attacks- and your adversaries- can you better position yourself for success down the road.
9. We haven’t had any incidents!
Unless your org has a non-traditional definition of an incident, odds are good that you currently have at least one infected host within your network. While not all incidents are front-page worthy or targeted nation state attacks, it is important to maintain good network hygiene by removing these infections when they happen. Without running down these “trivial” incidents, your company will run the risk of impacting production, shop floors, user accounts, end-user productivity, etc… depending on the type of malware you run into.
10. Just re-imaging and patching the infected machine is enough.
When incidents are discovered, many are content to quickly contain, re-image and pat themselves on the back for a job well done. However, when an issue (not even an incident yet) is discovered, you should immediately take any indicators you know of (IPs, Domains, etc…) and utilize them to hunt for other activity you may not be aware of; if you find anything during this hunt- rinse and repeat. Additionally, those indicators should immediately be operationalized into new signatures for your detection tools to spot on-going/additional or future intrusions. I’ll also use the term indicator a bit loosely as well- the compromised machine may be an “indicator” in and of itself in that you should look at traffic in and out of the machine as you may discover anomalous traffic indicating lateral movement. While mass malware may not lead to any other discoveries, targeted attacks generally don’t happen just once nor to only one machine. This is also just the tip of the iceberg for what should happen for any incident a security team comes across, but is often the thing most overlooked.
Hopefully I’ve provided some food for thought and would love to hear your thoughts on Twitter @SeanAMason. Thanks for reading.