Global spending on cybersecurity products and services is predicted to exceed $1 trillion during the period of five years, between 2017 to 2021, with different analysts predicting the Compound Annual Growth Rate (CAGR) at anywhere between 8 to 15%.
It is not surprising to see this growth in spending, which is primarily driven by the evolving sophistication and volume of attacks as well as the surmounting costs of a successful data breach.
And yet, data breaches continue.
The sad news is that about 80% of data breaches can be prevented with basic actions; such as vulnerability assessments, patching, and proper security configurations.
The specific reasons vary; but include staffing and resource issues, lack of expertise to optimize complex, multi-vendor security systems, and a host of other reasons. Whatever the specific cause, the common theme is that security lagged either internal IT changes or changes in the external threat landscape.
The phenomenon is well known in technology spheres – from things like configuration drift as applications and platforms change without reorganization; to Cloud drift as new serverless resources evolve to suite point-issues but are not accounted for in overall infrastructure growth estimates.
Because of this, we’re looking at a new form of drift centered primarily on changes that impact cybersecurity – essentially a security drift.
IT & Security Teams Face a Double Whammy
On the one hand, security teams have to continuously address evolving threats and adversarial sophistication, and on the other, IT teams are continually adapting to change and making alterations to environments that can create security drift, some addressed, and some invisible.
At the end of the spectrum are high-visibility changes revolving around hot topics like Information Technology and Operational Technology (IT/OT) convergence – and these usually (though not always) get concurrent attention from cybersecurity teams.
At the other end of the security drift spectrum, it’s day-to-day maintenance operations that may not get the deserved attention from security teams. These include routine activities such as software updates for new features, bug fixes, and vulnerability patching, and the upgrade or replacing of commodity software that does not require major planning.
No matter if the changes are happening to new systems going into production, or existing systems in production, the drift is created as the changes are made without security oversight or with insufficient security oversight.
Unfortunately, there are many examples of security drift situations where routine software updates and IT changes introduce vulnerabilities that require discovery and patching.
A high-tech company that had a robust (or so they thought) A/V solution allowed for a three-week patch drift for 2% of its systems. This was because some systems required testing before patching (due to OS and application concerns), and others were delayed due to operational constraints. The company was hit by a worm that was propagated to almost all unpatched systems, close to 3,000 machines.
The consequence was a denial of service from within that disrupted business and hampered remediation and restoration of the company’s IT systems.
A multinational outsourcing company deployed FTP servers for the purpose of dedicated file sharing with their customer. Their procedure for onboarding a new customer was to clone an existing service, change the default credentials, exclude the new system from DNS, and test the new system within a week of deployment.
Unfortunately, in one case, the lag between deploying and testing was enough for a hacker to find a system that was inadvertently left with default credentials and penetrate the customer’s data at great cost to the outsourcing company. The security drift created by the new instance created the opening that an adversary needed to initiate and successfully complete an attack.
These examples are significant in size and impact, but it’s the small examples of security drift that are the true silent killers, the proverbial loss of a nail in a horseshoe that loses the kingdom.
For example, a Web Application Firewall that was misconfigured and placed into learning mode (monitoring only) and a case in which IT changed the name of a server that had restricted access. The name-change inadvertently made the server accessible to everyone. Luckily, this was detected before any damage was incurred, and the rule that enforces the access policy was updated.
There is one thing that links all of these incidents together. Security drift is the consequence of change, and security operations are either unaware of the change or its significance. In some cases, it will create manageable risk, and in other cases, the risk demands immediate attention; but in all cases, the drift exists and puts the organization at risk. This lack of insight makes security drift the silent killer.
Avoiding the Silent Killer
The traditional practice for identifying and dealing with security drift is a combination of IT procedures and policies, vulnerability management systems, and pen-testing. While vulnerability scanning provides near-real-time results; pen testing does not. This may provide a lengthy window for security drift to occur that is unacceptable.
A new paradigm of security validation is becoming widely available for the security Blue Team, one that automates security validation in production environments. Complementing periodic pen testing by filling in the void between tests, continuous security validation becomes a powerful way to reduce the impact of security drift by detecting and identifying instances of drift in near-real-time.
Continuous security validation with Breach and Attack Simulation platforms can match the rate of internal and external change with the ability of the organization to detect changes that create weaknesses and gaps to help manage security drift better. Don’t let the silent killer getya’.
For more information, visit www.cymulate.com and register for a Free Trial.
Leave a Reply