By Ray Pompon, Director of Security for Linedata Capitalstream, Linedata
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.
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.
You don’t know where all your stuff is located
Good security means keeping your eye on the ball - and the ball is your critical asset. An up-to-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 fundamental component of risk management.
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.
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 high-level 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.
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.
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.