Cisco Midyear Cybersecurity Report

Posted on  by

We’ve got the tl;dr on Cisco’s 90 page midyear cybersecurity report for you! “Major Findings” on page five of the report can give you the gist of the report as well.

One of the bigger developments of note is the decline and stagnation of exploit kits. Due to multiple factors, mainly the hardening/reduced patch time/decline of Flash, Angler has disappeared from the landscape. Angler was the main innovator in the space and with their reduced presence, other kits don’t seem to be pushing for new and novel techniques. This trend isn’t expected to last, but it’s a welcome change for now.The decline of exploit kits coincides with an increase in spam, to potentially replace delivery mechanisms of malware.

It’s no surprise that ransomware is on the rise, with many variants being found in the wild. The careful selection of a price that a victim is willing to pay to get back to business can make this attack lucrative. The escalation of this is ransoming high value targets that generate large amounts of revenue, such as MRI machines(which are often operated by legacy operating systems, such as Windows XP).

On the vulnerabilities front, there has been an observed increase in particular attacks after vulnerabilities have been disclosed. This can be made as a case for the use of responsible disclosure in the time leading up to patch development/release, and a subsequent announcement of a vulnerability. With increased responsible disclosure, the real issue then becomes patch maintenance/management, which is a more routine and manageable task.

There is some cognitive dissonance in the report between Figure 41 on page 49, and statements made on page 50. Figure 41 claims that there were zero CWE-16 issues(configuration), while espousing the MongoDB(and other DBs) issues to particular DevOps stacks. The issues surrounding MongoDB and friends was most definitely insecure default configurations.

The section on IoT(Internet of Things) also makes a statement which is a bit confounding with regard to an IoT device to “have unpatched or outdated applications that are vulnerable, like Windows XP”. There are important distinctions between a consumer IoT device, like a thermostat, and a Windows XP machine that controls an MRI or baggage screening hardware. Consumer IoT devices are usually vulnerable through negligence - either by the owner, or the producer, while systems that need a standalone computer are more correctly defined as Industrial Control Systems(ICS). Lumping devices that cost less than $100 in with multi-million dollar installations does not illuminate the vast differences in the requirements of each. ICS installations are often governed by acceptance criteria, which may not allow for alterations of any sort, by either the customer, supplier, or a regulator. The lifespan and expected uptime of ICS installations also often runs into the span of decades, and expects near 100% availability at all times. ICS installations require robust controls to avoid ever exposing them to the world, and are largely to be used in strictly controlled environments.

The newly(?) coined acronym for Destruction of Service in the report, DeOS(or perhaps should be DeoS?), refers to the destruction, or “bricking”, of a device. The concept of bricking applies to IoT devices in the report, but its origins come from hardware hacking, where the penalty for failure turns working electronics into a non-functional brick. Bricking an IoT device with bad default passwords, or blatant security vulnerabilities prevents it from joining botnets, such as Mirai. Potential motivations for bricking devices could be twofold: 1. Keeping them out of the hands of DDoS operators, and 2. Creating a negative brand association to vendors with poor security practices. The second option in particular has the potential to not only damage the reputation of a hardware producer, but to also case massive warranty claims due to “broken” devices. Lax security practices are, most likely, going to end up having IoT vendors receiving regulation with regard to minimum security standards.

In a potential effort to redefine an existing attack, business email compromise(BEC) is made to sound as if it is something other than phishing. BEC is simply spear phishing, in which an employee, with the ability to release funds, is highly researched and targeted. BEC has yielded $5.3B USD between October 2013 and December 2016. Training to defend against this effective, and companies would be best served by setting guidelines for transaction verification by personnel that are able to release funds.

Overall, the report is illuminating, despite some of the attempts to reinvent, or redefine, terms/attacks that already exist. I found the most value to be in learning of the potential causal link between a decrease in exploit kits and the increase of spam volumes. I feel that the report could have easily been trimmed down to 30 pages and still be a great resource.