You are a CIO or CISO looking at your next budget cycle. 
You know that there is way more threats operating on innumerable vulnerabilities than you can afford to mitigate. How best to spend the often shrinking budget you have on a future you don’t know? Given that you have some capability currently and without naming a vendor I suggest you could take an operational pause on acquisition and still dramatically increase your risk resilience. Now admittedly suggesting you don’t have to buy yourself to a better security posture is not going to make new friends with the vendor community. This suggestion though even has some nuggets for them.
First, know who you are and what you have. Configuration controls and network maps are a must. There are tools to do this, but the number one requirement is leadership. A physical network map of circuits and boxes tells you about infrastructure. A logical network map tells you about system configurations. A data and entity relationship map of business objects tells you about depe
ndencies and trusts. You need all three to secure a network. Every short cut taken on this will decrease your capability severely. If you don’t have this currently you may be able to pass FISMA but you are not secure.
A compressive set of system and network maps creates an Atlas of your environment. When the first complaints arise about the chaotic nature of the network leadership should hear those criticisms as evidence of non-secure networks. Where non-secure is code words for absent risk management practices. You can’t manage risk on what you have no knowledge of, nor can you secure the invisible.
Where will you get the funds to pay for this activity? You likely have a team that has all of the knowledge just not the processes to accomplish the task. Given your current knowledge that can be demonstrated build from there. With concrete goals, good metrics, and finite expectations reach for better knowing perfection is illusive.
Second, you have a security program likely discussed as defense in depth but realistically it is an amorphous blob of capability. Each vendor product has tiers of capability. Your teams securing the enterprise usually choose products on type 1, or tier 1 capability of a product. You buy vendor product A as a firewall (best in class), vendor product B as a reverse proxy (best in class). The issue is what you discovered while mapping. Multiple best in class products create exponential tool and configuration bloat. A less capable product may be more secure when bounced off the risk of significant increase in attack surface.
Besides the attack surface and configuration bloat, the multiple products problem increases security acquisition issues. Since products often have multiple tiers of capability that overlap significantly it is a strong suspicion that you may have exposed interfaces and attack opportunities within your network right now. When it comes to acquisition you buy all those secondary capabilities but don’t necessarily use them which wastes money and time. You will still be required to secure all of that functionality (STIGs are usually against the total product).
Third, since you are going to do way more with less take part of those savings and engineer/architect your future strategies around a cohesive vendor technical roadmap. Plan your training around vendor derived product suites and make quarterly vendor training a requirement for updates. Make vendor neutral training a core functionality. I tell CIOs and CISOs security training is patching their security team. Each SANs course is like a full revision upgrade to your team, and each webinar a patch.
Finally, there is tool fatigue. Every tool, utility, application, and capability of your security team needs to be controlled. Given X requirement then tool capability Y must be bounced off the entirety of your suite of security applications. Security teams hate this. Tool bloat inherently decreases security team effectiveness and increases hero management versus team capability. This comes down to who is watching the watchers. Where the tool bloat and subsequent tool fatigue decreases the team effectiveness. Regardless of single team members that can be more effective the team becomes a risk to systemic security if there are rogue capabilities.
Your goal is to have as few acquisitions as possible with the most capability and interoperability within an architected secure environment. None of the issues keeping this from happening are technical but an I depth technical understanding of the why is important. Beyond these are the key principles of refresh to secure, build for resilience, train for success, and measure for action.