The following five security problems are things I’ve seen frequently in the industry. These problems are also frequently reported in the news, and they’re things that my colleagues are complaining about as well.
But more importantly, these problems show up commonly in metrics. When experts study the tactics that threat actors are using to breach organizations, these are items that make the top five list over and over again.
While these are common failures, they don’t necessarily have to be expensive to fix. In most cases, you don’t need to buy more tooling to solve these issues. Rather, these problems are process-oriented. And if you address the flaws in your organizational processes, you’ll move the needle on your overall security posture.
Here are five big security problems — plus a bonus one — to watch out for in your organization.
1) Failure to Patch Tools
One of the most common causes of breaches is a failure to patch. This could be a complete and utter lack of patching, or it could just be a lack of timely patching. Either way, this is by far and above the most common issue that I see.
In large companies, patching failures can be due to complexity. There may just be too many things in too many places to effectively manage patching. But it actually tends to be worse in smaller companies, because their patching process lacks the needed attention, resources, and prioritization.
To be clear, although some companies choose what and when to patch and make a conscious decision to not patch certain things, many others simply lack effective patching policies and processes.
Why Is Patching Something to Be Concerned About?
Every defect on the patching front increases a client’s attack surface. That means more ways for attackers to get in, more things for them to exploit, and more potential holes into the organization.
With internal machines, this generally means greater opportunity for lateral movement, even if you have good isolation or good network segmentation. It also means that when an attack happens, you’ll have greater difficulty finding and removing remnants in the aftermath of the attack.
If you have externally facing machines with unpatched vulnerabilities, you’re directly putting your business at risk. I highly recommend patching everything as quickly as possible, but patching any systems directly connected to the internet should be the number one priority.
Ransomware in particular likes to prey on unpatched systems, so organizations that are not patching are certainly putting themselves at an increased risk for picking up ransomware.
How Should Issues With Patching Be Addressed?
First and foremost, addressing this problem starts with policies and processes. Make sure you actually have a patching policy that defines what you’re going to patch and when you’re going to patch it.
Are you going to deploy all available patches, or just critical security patches? What will be your patching cycles for user workstations and servers?
You can’t measure what isn’t defined in your policies, and you won’t be effective if you can’t measure it. So start with defining what your patching policy is, then put in a system to measure your success.
Once you have the policy and the visibility, then you can focus on the automation and tooling. But to be frank, most organizations already have the tools that they need to do their patching — they just don’t realize how poor of a job the tools are doing.
2) Deficient Backup System
Another big security problem I often encounter is companies lacking a backup and recovery process. This is more of an issue in small and mid-sized companies, but I do still see this in large companies as well, just to a lesser extent.
Companies that struggle with this might lack backups entirely — but more commonly, companies do have a backup process, but it’s untested.
The key to the backup process is making sure you know your recovery time objective and recovery point objective. If you haven’t tested your backups, then you won’t know what these are.
However, even if you have backups and test them frequently, your process may still be deficient. There must also be a plan for how to implement the backups in a timely manner if there is a security incident.
Why Are Poor Backups Something to Be Concerned About?
Backups are a critical part of security, because in a lot of cases they’re the only recourse for restoration following a security incident. If you don’t have backups, you’re not going to be able to restore — and you’ll have to rebuild whatever hasn’t been properly backed up.
If you do have backups, but you don’t have a plan or you don’t know how long it takes, then you’re going to leave your customers hanging by not knowing when you can return to normal operations.
If you can restore two terabytes an hour and have 40 terabytes worth of data to restore, then you can tell your customers with confidence that your business will be back up in 20 hours. But if you don’t have a plan, or if your plan is untested, then you can’t guarantee anything.
There are constantly headlines in the news about organizations that are down for days and their PR statement is, “We don’t know when we’ll return to normal operations.” That doesn’t instill confidence in your customers — and it doesn’t help your reputation, either.
How Should Issues With Backups Be Addressed?
My recommendation is at minimum to follow the basic 3-2-1 backup methodology. That’s three copies of data, across two different media, with one copy off-site. Also, make sure you’re testing and documenting your RPO and your RTO numbers.
Who is going to do the restore? What is the process to recover all or even just a part of your data? Which systems are going to be restored and in what order? What is the plan if you have an incident? These are questions that companies of all shapes and sizes need to consider and should be addressed in business continuity and disaster recovery plans. They may also be referenced in a security incident response plan.
3) Poor Tool Health
This is one that doesn’t always make the list for other people, but I have seen this pretty much everywhere I have ever worked or been called in to help, and that’s poor tool health. Organizations have their InfoSec tools deployed, but the tools are not working because they’re misconfigured or impeded in some way. This can include network or firewall blocks, or missing exclusions from other security tools.
Poor tool health is often a consequence of having too many tools. When there’s excess, there’s often little engagement with the tools, so organizations aren’t able to use them effectively. They don’t know how to manage those tools and in general overall tool health can suffer.
Why Is Tool Health Important?
When your cybersecurity tools are broken or impaired, it means you’re missing visibility. And if you’re not measuring the health and effectiveness of the tools, then you don’t know that you’re missing visibility or that you don’t have coverage.
And most importantly, it means that you’re not going to detect an incident as early as you might if the tools were all working in optimal health. Oftentimes these tools are used for response containment and remediation as well.
So if your tools are broken or not working, you may not be able to contain an incident before it spreads, or during a crisis, you may not be able to respond to an incident at all.
How Should Issues With Tool Health Be Addressed?
In order to avoid this issue, start by tracking the health of your tools. It’d be great to build a single pane of glass where everything is in a single console, but that might mean you have to spend some money and do some integrations. Start by using the consoles for the individual tools.
Just about every security tool on the planet has some sort of a health console — use it. Make it somebody’s job. Look at that console every day, and go fix things that are reported as missing and broken or unhealthy.
In order to measure your security tool health, oftentimes it requires that you have a baseline. If you’re a large organization with lots of security tools, a very simple solution for baselining is to take an inventory from each of those tools and compare tool A to tool B to tool C. That doesn’t cost you anything.
Most importantly, measure your tool health. Make this a visible metric that gets reviewed by leadership. In many large organizations, these types of metrics get reported to the board.
4) InfoSec Tool Conflicts
I see conflicts between InfoSec tools pretty frequently, but it tends to fly under the radar. This tends to be a bigger issue in large businesses. Larger businesses tend to have more security tools, and thus, those InfoSec tools often impact each other. Compounding the issue, larger organizations tend to operate in silos, even within a single function. This makes it even harder to find and fix a tool conflict.
Why Are Tool Conflicts Significant?
Those impacts could be security tools in conflict — if your antivirus tool doesn’t have exclusions for the DLP tool, it blocks and quarantines DLP, making DLP ineffective. Things like that are unfortunately pretty common.
I also see performance issues, where the tools are competing with each other, trying to scan the same things or perform the same functions. There’s a direct impact from this as well. If the InfoSec tools are competing or conflicting, you may lose visibility into your incidents, and you may also have business issues.
Chewing up all the CPU and disk cycles with security tools could leave a business user’s machine unusable, or it could leave a server without the resources to perform critical business processing. If business users can’t complete their work, that will lead to a poor working relationship with the InfoSec org, which can have even bigger and longer term consequences.
When the important things come down the pike, beyond just agents and tools, you’re a lot less likely to get your security budgets approved, you’re much less likely to be viewed as a partner at the table, making security a push versus pull strategy and creating an adversarial atmosphere.
How Should Tools Conflicts Be Addressed?
In many cases, this comes down to optimizing your security tool portfolio. When you have too many tools in the portfolio, you need to rationalize, use the tools you have more effectively, and eliminate redundancies.
With fewer tools, there’s less likely to be conflicts. Once you’ve rationalized, you need to take a look at the bigger picture and build a process for tool exclusions and configuration. Self-service would be great, but if automation is too expensive, even a manual request process will lead to significant improvements.
For every InfoSec tool you have, there needs to be at least a partial resource dedicated to managing tuning and configuration. You should be looking at alerts that are generated, and which ones are getting ignored. Follow up on those alerts, tuning those that are causing false positives or that may be blocking other tools or negatively impacting business processes.
Also create a process for the business to easily engage and collectively ask for exceptions or exclusions. If the business can request an exclusion, that gives you a chance to proactively avoid having incidents and it gets a dialogue going with the business to discuss security. That dialogue is golden.
5) Lack of Security Awareness
Countless organizations struggle with a general lack of security awareness. It’s a very avoidable problem, but it’s still unfortunately common. They view security as something that’s bolted on after the fact, rather than baked into daily work processes and products.
In these organizations, neither leadership nor end users consider security implications as part of day-to-day business decisions or ongoing work activities.
Why Is Security Awareness Important?
This problem can be incredibly impactful because if we’re not thinking about security on a regular basis, users are much more likely to do something that inadvertently lets attackers into the organization.
Unaware users are more likely to click links, or they’re more likely to set a weak or reused password that can be easily compromised. Exposure and reputational damage is created for companies through these incidents.
How Can a Lack of Awareness Be Addressed?
You don’t need to buy tools to increase your organization’s security awareness, and you don’t necessarily need to throw large amounts of cash at the problem. Security awareness starts at the top, with a leadership team leading by example.
It’s up to the leaders to demonstrate a security mindset and build a culture of security. The leadership team can do simple things to identify and acknowledge security wins, focusing on non-InfoSec organizations. And they can be visible and vocal about following security policies, especially by avoiding flaunting executive privilege by constantly asking for exceptions.
When the business does something that is good for security, make a big deal of it — offer a reward and recognition. Make sure that everybody knows you appreciate and acknowledge that your business users are taking security seriously.
When things are measured or scorecarded, put security at the top of the list. Make sure that we’re talking about security in all contexts, because in this day and age, there aren’t many conversations where security isn’t going to have at least some role to play.
Bonus: Believing Your Organization Is Not a Target
I’ve included a bonus, because for some organizations, this is the biggest threat to their security: believing that the organization is not going to be a target, and that security is unimportant.
This tends to be an issue more with smaller and mid-sized organizations, but surprisingly I do have to address this attitude in larger companies as well. And for organizations of every size, it’s simply not true.
In this case, they have this misperception that there’s a person on the other end of the Internet on the keyboard, thinking, “Who am I going to hack today?” and the company is just too unimportant to make that radar.
And unfortunately, most of us know now that that’s just not true. In 99% of attacks, on the other end there’s a bot or some other type of automation looking for holes. And if you have a hole, you’re equally as susceptible as organizations of any other size.
Your entire organization can be owned by a bot, and the originating attacker may not even care that they’ve taken over your organization — but you still have a compromise, and it still impacts your business.
How Do You Address This False Belief?
Out of all the things I’ve talked about, this is the easiest one to fix: face the facts. Everyone, both individuals and companies, is a target.
Plan for an incident, because it’s not a matter of if you get hacked, but when. Hopefully you’ll never have to use that plan, but having a plan and not needing it is a much better scenario than needing a plan and not having it.
Final Thoughts
You might have noticed that none of the solutions I outlined for each of these problems required you to spend more money on products. However, evaluating your organization’s processes came up frequently.
More tools are not going to solve these problems. You can spend all you want, but it’s not going to solve anything unless you address the flaws in your policies and processes first.
If you’re having trouble finding a starting place, consider reaching out for a consultation with Black Kilt. Our experts have years of experience on engagements that help solve these exact problems. Whether it’s optimizing your portfolio or helping you create processes from scratch, we can implement the solutions that are right for your organization.
