Much like physicians, security vendors prescribe remedies for their customers' ailments.
Unlike physicians, no Hippocratic oath exists for security vendors. What if our industry operated under a basic tenet like "First, do no harm?" Instead, security vendors continue to add new layers of complexity, and therefore new attack surfaces, with the intention of solving a security problem on the stack below.
Their rationale? That it is better than doing nothing or better than what the customer had in place the day before.
This argument is short-sighted and indicates a lack of comprehension of the risk they are imparting to their customers. Is it intentional or mere ignorance on the part of the vendors? And what can enterprises do to protect themselves? How do we get to a new cybersecurity industry ethos, focused on viable solutions and committed to doing no harm?
The cure is worse than the disease
Apple, Google, and Microsoft have spent millions of dollars, on both technology and developers, to lock down the OS and build resiliency subsystems to make exploitation highly expensive for the attacker in terms of time and labor -- for example, jailbreaking or sandbox evasion.
And yet, security vendors (including many of the biggest brands in endpoint, network security and container security) introduce new vulnerabilities and additional risk by breaking the default security boundaries established in all the major operating systems.
Many endpoint and network security vendors introduce new attack surfaces by adding complexity. Instead of looking at the root cause of an issue, they continue to branch out and apply point solutions.
Sometimes, these solutions break the default secure design principles established by the platform vendors. Endpoint and anti-virus software vendors that do not use privilege-separation and sandboxing therefore create a new and large attack surface at the highest privilege level of the endpoint.
Network security appliances are essentially anti-virus software inlined at critical vantage point of a network and suffer from same diagnosis as above.
Infrastructure security vendors expose guest virtual machine data streams to a complex parser running at the host with root privileges. The container security vendor corollary to that would be exposing the data streams from a container to an agent running at a high-privilege level at the host.
In addition to the clearly risky behaviors above, there is a whole subset of solutions that I call homeopathic. Essentially, these do no harm -- but also do not solve any problems. You can safely list most of the governance, risk, and compliance (GRC) solutions under this subset.
As an industry, we do a disservice to our customers and the trust that they put in us when we not only solve their real security issues but expose them to much worse. That network appliance on the tap port is a higher order systemic risk than anything else they endured the day before its installation.
Snake oil or solution? How to tell the difference
In my experience, many enterprise IT professionals feel confused by the claims of vendors and the conflicting attacks they lob at each other.
Here are a few tips and questions that help cut through the morass of mixed messages and get to the truth behind the hype.
- How easy is the product to acquire? If the software is cloaked in secrecy, beware. Externally untested software is likely to have unseen flaws or skeletons in the proverbial closet.
- Is the product written in a managed language? Managed languages like C#, Python and Go are much less likely to suffer from memory corruption issues compared to C or C++.
- What are the open source and third-party components of the product? Understand the balance of proprietary and open source elements and the associated risks. Ask for a FOSS scan report a tool like FOSSology or similar. Make sure held them accountable for outdated FOSS or 3rd-party components.
- Does the vendor deploy Secure Development (SDL) practices? Ask about their SDL process and code audit metrics. Get documented confirmation.
- Does the product break the default operating system security design? Any product that works outside the well established boundaries of the operating system will create more security issues than it solves. Ask whether they run complex parsers in sandboxes and use privilege process separation and brokering? A firm "yes" is what you want to hear. Does the product turn off any exploit mitigation technologies such as Address Space Layout Randomization (ASLR)? A firm no in this case.
A prescription for vendors
- Use the operating system paradigms for security. Operating system vendors have done the hard work and made the investment. Take advantage of the stringent security they deploy. Remain in user-mode and improve security hygiene.
- Use established secure development principles. Get counsel on this! (Feel free to reach out directly to me for introductions to top talent consultants.)
- Be transparent. Hire researchers, get real-world feedback, and make your product available to outside researchers.
- Sandbox risky components. Employ privilege separation and broker complex work to sandboxed worker processes.
- Stay up-to-date. Many vendors use outdated open source or third-party code and libraries that opens new attack surfaces in the software.
In the end...
We must have an ethical shift in the cybersecurity industry. The majority of solutions are akin to the bloodletting "cures" of the dark ages. Count yourself lucky if you don't die from them.
I have been in this industry for over 20 years. Our moral compass is broken and we need to act for the greater good rather than for self-promotion to fill our pockets. We must take action before a massive "extinction-like" event. A self-propagating ransomware attack could one day spread using an anti-virus vulnerability or through a network security appliance that infects all inbound email attachments in its wake.
We cannot afford such a catastrophe. I challenge my fellow security industry leaders to make the changes necessary to evolve the industry for all our benefit.
Read the full article at ZDNet
