It is helpful to understand when I am the problem or when my organisation is the problem. By that, I mean that it is important to discern when an approach to a problem is simply ineffective. When I understand that an approach doesn't work, I can try different things until I find the right solution. This is the definition of repetition.
Redundancy, on the other hand, is when I, or my organisation keeps trying the same approach and nothing changes. It makes no sense to expect different results without a different approach. This, of course, is the definition of redundancy. What can the difference between repetition and redundancy teach us about security? A considerable amount.
When run properly, a mature intelligence capability can help an organisation understand the risks and threats it faces, bolster its detection abilities, and improve its response capabilities. On the other hand, a poorly run intelligence capability confuses decision-makers, deluges alert queues with false positives, and slows incident response.
Organisations try to force poor intelligence sources and an underdeveloped capability into security operations in an effort to leverage them. The results aren't pretty. More surprising than the results is the tendency of these organisation to try this same approach again and again with the expectation that something valuable will somehow emerge from it. That's not repetition. It's redundancy.
Vendor risk management
Most medium-to-large businesses have a vendor risk management (VRM) program. The maturity of VRM programs varies widely across the security industry. Nearly all VRM programs have one thing in common: They involve a painfully manual, labour-intensive process. What's amazing to me is not that organisations struggle with a process that needs improvement. That is to be expected and will improve with time as new approaches and solutions become commonplace. What amazes me is that organisations expect different or improved results from the same broken process. That's redundancy.
Also see: Steps To Combat Insider Threats
Staying on top of vulnerabilities is of the utmost importance to a security organisation. Whether it be endpoints, servers, web applications, or otherwise, it's important for an organisation to understand where its potential points of exposure are. But stopping there is only part of the answer. What good is a weekly report of vulnerabilities without correlating it with overall risk, sensitive and/or confidential data, system criticality, and other dimensions? Those additional dimensions give an organisation the ability to leverage vulnerability information to mitigate and reduce risk. That's an approach that can be repeated. Continuing to run weekly reports merely to put them on the shelf? That's redundant.
Alert fatigue is a known problem that organisations struggle with. Blindly implementing default signature sets recommended by vendors and others without considering how they attempt to detect, address, and reduce risks the organisation is concerned about isn't a recipe for success. It's most often a recipe for unmanageable alert volumes and an avalanche of team-drowning false positives. The fact that many organisations struggle with alert fatigue is not in the least surprising. The fact that those same organisations continue to complain about alert fatigue and expect better results without ever adjusting their approach is quite surprising. That's just plain redundant.
Anyone who has worked in the security field for some amount of time understands the necessity and value of a mature incident response capability. What's less widely understood is the long and winding road that leads to just such a capability. I've never met a well ran incident response team that hadn't had time to learn and grow together. It's to be expected that certain processes, procedures, and functions may not work perfectly, or even fairly well, from the off. More important than things working perfectly is learning from when things don't work perfectly. This is easier said than done, of course.
For an organisation to truly improve its incident response capability, it needs to examine its strengths and weaknesses as well as its successes and failings. This requires that the organisation view itself as the problem, in the sense that there are certain functions within incident response that the security team does not perform well. Only then can repetition work its magic to improve the organisation's incident response capability. Otherwise, we're back to redundancy.