Six signs your security program is obsolete

Ray Pompon
In the technology world, things get out-of-date fast, and a cyber-security program is no
exception. The lifecycle for an average piece of technology is about three to five years. Like
everything else in technology, cyber security programs become out-of-date as new techniques
and technologies are constantly introduced. What do "best practices" even mean in a field that
is just a few decades old and where technology turns over every few years?
If unacceptable downtime due to malware, failed audits, and data leakage aren't clear enough
indicators, then here are six more clues that your security program is edging towards its
inevitable retirement.
1) Patching is a painful one-off exercise
For some organizations, dealing with huge security flaws like Heartbleed, Shellshock, and
Poodle meant IT dropping everything and staying late at night to get things patched quickly. In a
healthy organization, patching should become a routine process. This is where a clear, robust
change control policy comes into place. IT should also have a good idea what needs to be
patched.
2) You dont know where all your stuff is located
Good security means keeping your eye on the ball - and the ball is your critical assets. An upto-date inventory should be available at any given time. A good inventory system should also
outline what software and data are on each system. A clear information classification regime,
along with an asset management program, should also be in place. Inventories should also
extend beyond the "pc" and include removable media, mobile devices and cloud deployments.
Asset awareness is a foundational component of risk management.
3) Risk analysis is just a gap analysis against best practices or audit requirements
Assuming that you know where everything is, you then need to figure out what bad things can
happen. Risk analysis should be a lot more than just reviewing a checklist of controls. It should
be a collaborative, dynamic and, as realistic as possible process.
Another indicator of a risk analysis deficiency is when business initiatives are being blocked
unilaterally because "they aren't safe" without rational and quantifiable justifications. There are a
lot of good risk analysis methodologies -- my favorites include FAIR and NIST Special
Publication 800-30.
When doing a risk analysis, remember to document all of your assumptions, look for
dependencies, and then keep in mind that there is no such thing as a closed system. Risk
analysis should be the basis for your organization's security policies.
4) Security policies are inches thick and no one reads them
Security policies are high-level objectives about how an organization manages risks. The goal
of a security policy is that anyone in the company can read it and easily understand at a highlevel what they are expected to do. Technical detail and procedures are not policy - they are

process documentation and should be left out of the main policy document, as to not bog down
actual implementation.
Ideally, security policies should only change when risk or risk tolerances within your
organization changes. The policy objectives should be tied into solving business problems and
also match organizational activity. Technical jargon belongs in IT and Security Operations.
5) The IT department manages the IT and the Security Department adds the security as
an afterthought
Security is not an add-on. It should be baked into the actual technology based on clear
guidance from the security policy.
The primary job of IT is supporting the business units, which means satisfying user demands,
fire-fighting major problems, and implementing projects. Security is one of many priorities, but
should actually be the most important one. IT teams need to understand the importance of a
solid security policy, and not just address it on a case-by-case basis.
There needs to be a Security Team in place that not only manages security issues, but guides
the actual IT Operations. Ideally, they should be two distinct groups with different management
structures.
6) Over-focus on operational controls and under-focus on day-to-day security work
Security personnel can often get distracted by tinkering with firewalls, anti-virus solutions,
password settings, and vulnerability scanners. The reality is that security demands difficult,
tedious and repetitive tasks like inventory, incident response, risk monitoring, and threat
analysis. It also requires building a well-considered security architecture, proper systems
analysis, and solving and resolving on-going business needs.
A bottom-up approach for security architecture is best, using well-understood sub-systems. If
security spends all day focused on spam filters, they'll have no time for risk analysis and end up
behind the curve.
While many of these preceding six (6) practices were once considered normal for cyber
security, they have little value in a modern enterprise. Obsolete practices are likely to result in a
security program that is in fire-fighting mode and addresses fixes in an ad-hoc manner.
Whether it's the pre-audit panic, analysis paralysis or rushing from one incident to the next, this
is a fast ticket to burnout and missing something vital that can lead to a breach.