Why time is crucial in security execution
By Brad O’Hearne
DISCLAIMER: As with all security operations, always act in accordance with the highest standard of legality and ethics, making sure you have the proper authorization for any security exercises in which you engage.
Suppose for a moment that the relevance of time was removed from all human endeavor. How would that change the nature of athletic races? What if it no longer mattered how long it took an Olympic bobsled team to reach the bottom of the track, just that they reached it? Consider the field of medicine: what if the time required to discover a treatment for a fatal disease held no detrimental impact to those desperately needing a cure? What if military operations resulted in equal casualties and outcomes regardless of the timing?
Grasping these scenarios is difficult to fathom because, in our world, their significance derives from the speed of execution accompanying the effort. Without the defining aspect of time, efficiency and speed would cease to be relevant as well. Only the ability to complete a challenge would be important. So, if a few beer-swilling gents plucked from a Saturday barbecue were able to make It across the pool without drowning, they’d be equally deserving as Michael Phelps for an Olympic gold medal in the 100 m freestyle. Everyone suffering from a terminal disease would live indefinitely until a cure was available. Or each side in a military conflict would wait for all troops and weaponry to arrive and position in the battlefield before the first shot was fired.
These imaginations are clearly ridiculous because, in the real world, the mere ability is not enough: time matters. The fastest wins the race. The cure discovered quickly saves the most lives. Militarily, perhaps General George S. Patton said it best: “A good plan violently executed now is better than a perfect plan executed next week.”
Yet when it comes to security implementation, the sole presence of capability commonly remains the focus, as opposed to the speed of execution. Particularly amongst management, security programs are evaluated through inquiries such as:
- Is a vulnerability management program in place?
- Is there an intrusion detection system in place?
- Is there an incident response policy?
Questions of this nature typically feed checkbox-type evaluation, absent of a qualitative analysis based on merit. Thus, both solid and awful security programs simultaneously have the possibility of resulting in the same answers to these questions. Viewing a security program through these have-it-or-don’t lenses can encourage a mindset that improving security is the byproduct of increasing capabilities, i.e. defining more policies and adding more security tools to the mix. This is a sibling of the false perception that
the most money and resources necessarily results in a superior security program. While having abundant resources and a full toolbox is no doubt a desirable luxury which can help tremendously if employed strategically, it guarantees nothing. If it did, security news headlines would be dominated by under-resourced, fledgling companies. But they aren’t – the largest companies and governments in the world, with comparatively massive security budgets and headcounts, can’t keep out of the limelight.
Organizations of any size and budget can significantly improve their security posture by shifting their focus from stockpiling security tools and capabilities to focus instead on the speed of execution of a few key abilities.
Threat intelligence
Every day, new vulnerabilities and threat vectors are discovered in operating systems, common services, third-party component libraries, etc. Likewise, waves of attacks often follow trends (such as the recent spate of cryptocurrency-mining malware distributed by botnets). It is crucial to have an awareness of these developments in as close to real-time as possible. Reports of new vulnerabilities often hit the news media well before they are cataloged in public vulnerability databases. It can take much longer for vulnerabilities to appear in updates to industry vulnerability scanners, which it would seem many rely on as their means to stay current.
Recently, I came across a particular vulnerability where the time between public disclosure and appearance in vulnerability scanner updates was around ninety days. If relying on security tool vendors to keep pace, this example gives potential attackers three full months lead time before even having awareness of whether the vulnerability exists in organization apps and systems – this doesn’t include analysis and remediation time.
If you have the opportunity to employ a commercial threat intelligence tool, that can be a helpful time-saver. But if not, all is not lost. For the past several years, I’ve daily monitored a number of security-related websites, RSS feeds and listened to a number of weekly security podcasts to keep current. It has consistently paid off – I am nearly always ahead of both those around me and vendor tools. Furthermore, acquiring this knowledge immediately when available has allowed me to quickly investigate other implications of these vulnerabilities to apps and systems before external exploit attempts to kick into high gear.
Goal: reduce time to become aware of new threats to your apps and systems. Narrow the time gap between public disclosure of vulnerabilities and positive identification of impact to your apps and systems.
Vulnerability management
Once a vulnerability has been determined to have an impact, analysis and remediation will follow. Typically, an organization’s vulnerability management program will have defined remediation time windows based upon severity. Time windows can vary widely across organizations. I’ve seen expected remediation times for common severities defined anywhere along the following spectrums:
- Critical severity: ASAP to thirty
- High severity: a few weeks to over sixty
- Medium severity: sixty days to six
- Low severity: ninety days to no commitment at
Those time ranges are diverse enough that they really call into question the primary motivation. In my observation, the approach to defining remediation time windows often derives from what efforts are considered nonintrusive and can be absorbed comfortably. While desirable to set goals that can be feasibly accomplished, if remediation arrives too late and fails to thwart attacks, those goals are at best a placebo, which eventually will fail.
Furthermore, there’s a big difference between defining remediation time windows, and consistently remediating within those time windows. The definition is irrelevant if actual remediation times fall outside of those windows.
If I had to give an organization only one piece of security advice, it would be to become exceptionally efficient at consistently remediating vulnerabilities within tight time windows. The ability to remediate vulnerabilities quickly is the difference between preventing an attack, and having that vulnerability exploited (and all of the aftermath which may follow, including complete organization compromise). Preventing attacks, breaches, and destructive impact is the objective, and vulnerability remediation time windows should be defined to that end. If not successful defensively, a vulnerability management program is prioritizing style over substance.
Goal: set tight vulnerability remediation time windows. Reorganize operations to become extremely efficient at consistently remediating vulnerabilities as quickly as possible.
Intrusion detection & response
With many companies still trying to figure out how to respond to new vulnerabilities when disclosed, to what degree have companies successfully organized tactical intrusion detection and response operations? Even if they have such teams and programs, do they have any concrete appreciation for their actual execution while under live attack?
I’d speculate that the majority of organizations probably have, at best, a network monitoring tool and perhaps a SIEM for intrusion detection; and some kind of policy and designated personnel in the event that indent response is required. These are necessary parts of the equation, but devoid of live simulations and rehearsals, nothing can ultimately be concluded about the ability to deal with a real attack.
Going back to the original three examples: how well could an athletic team be expected to perform in a game if they never practiced or scrimmaged? How well would a doctor perform in the operating room if never involved in a prior surgery? What could be reasonably expected from a platoon of soldiers who had never rehearsed coordinated troop movements and war games? Yet insecurity, there seems to be a perception that operations can be played by ear when an attack occurs, and a favorable outcome will result.
During a live attack, the answers to the following questions hang in the balance:
- Will the attack goes unnoticed, or will it be detected?
- Will the app or system be successfully exploited, or will the attack be thwarted?
- If the app or system is exploited, will the attacker gain a foothold, or will they be identified and locked out?
- How long will an intruder foothold persist before it is detected?
- What undesirable impact will intrusion have against apps, systems, and data?
- How quickly and to what degree can the organization recover from destructive impact?
The answers to the above questions are highly dependent upon the speed of execution of both intrusion detection and intrusion response. The attacker most likely has performed the attack before and has scripted their intended actions to some degree. They know they are working against time and detection. Unless your organization can efficiently execute quicker than the attacker, you will lose.
Goal: construct a coordinated plan for intrusion detection and response. Put the plan to the test under live attack conditions, timing the speed of defensive operations and ultimate success milestones. Analyze the outcome, and revise strategy to counter weaknesses. Run simulations again, trying to lower the amount of time it takes to nullify the attack.
Survivability
There are more holistic organizational benefits which come from executing security operations swiftly. Some may consider it liability, others may refer to it as reputation, or call it PR. But it really includes all of the above: it is the ability for an organization to favorably survive a serious security incident. The speed at which security operations are executed says something about an organization’s attitude toward security. When vulnerabilities are remediated slowly, and when there’s no dedicated effort to detect an intrusion or respond to an incident with urgency, it communicates a lack of priority to the organization.
When assets and potentially private user data hangs in the balance, it is important that actions document responsible security handling. Actions should be explainable, and defensible if necessary. How security operations are conducted should be evidence that the company places a high priority on security. Should these actions become public, their reality should serve as a PR asset, enforcing a message to the public that an organization takes security seriously. Otherwise, lax policies and procedures, or actions inconsistent with adequate policies and procedures, may have the opposite effect, and serve to demonstrate neglect. An organization’s mishandling of security operations can become a bigger damage control problem than the actual security incident in play.
Conclusion
Insecurity, it isn’t enough to have policies and procedures defined. It isn’t even enough to execute those policies and procedures. Battles against attackers are won by whoever presses their initiative first. What determines the effectiveness of a security program is the ability to execute at speed. As security professionals, we are always on the clock.
About the Author
Brad O’Hearne is a 25-year career software architect/ developer, application security expert, an independent security researcher. He resides in Gilbert, AZ and enjoys cycling, soccer, reading, and spending time with his family. He is available for consultation and can be contacted at [email protected].
