Only you can prevent security fires.
Here are a few sayings I like to throw at my co-workers from time to time:
- When you're wrestling alligators and winning, it can be difficult to remember that your job is to drain the swamp - you only got into the alligator wrestling to get them away from the pumps.
- When you're fighting fires ... no, the fire-fighting metaphor is way over-used in IT already.
- When you're busy bailing water out of the boat, sometimes it's difficult to stop doing that long enough to go plug holes in the boat - never mind taking time to hunt down the idiot with the drill.
These all address the basic truth that it's really easy to focus too hard on the things like day-to-day monitoring of process, and miss the opportunity to educate your co-workers, to spend time on a design that prevents an exploit from occurring in the first place, or to assist a team that's designing a new project, so that they can make good decisions.
So, what's my answer to this problem?
It's a little bit ruthless - simply stop doing the reactive stuff after a while, and spend some time on the preventive work.
If you're only doing reactive troubleshooting ("fire-fighting"), you're not progressing. If you're not progressing, you're not preventing the fires. You can reasonably say that you don't have time to do more troubleshooting than you're doing, even though you could potentially take time away from the design work, the learning, the teaching, the planning.
You do at some point have to put down the hose, and teach people to stop using so much wood and sawdust in their buildings.