Earlier today, Cisco released their 2018 Annual Cyber Security Report. I’ve spent some time digging through the report and thinking about what they’ve written. It’s interesting to read through the trends and survey results, and try to get an idea of where security efforts should be focused for the coming year. This post is going to cover just a subset of what’s in the complete report. I’ll be covering the topics that I found particularly interesting, and give my own thoughts/views on them.

The Encrypted Web is Great… For Attackers

Unsurprisingly, Cisco reports a growing trend in attacks and exploits that are taking advantage of encrypted transport. As a lot of large companies and Internet bodies are pushing for a 100% encrypted web, should we be surprised? Nah, it’s the logical next step. Users want encryption because it means privacy - but that privacy also brings a method of concealing attacks.

New exploits and malware are heavily leveraging encrypted transport to bypass all of the security we put in place to detect them. Typical defense technologies like intrusion prevention systems (IPS) are fantastic, but only when they can actually read the data. If a user download’s malware through an HTTPS call, IPS won’t usually catch it. And when that malware can now take advantage of SSL to reach back out to a command & control server? Yeah, IPS might not help us there either.

There are technologies out there that allow enterprises to see this traffic - but maybe not enough of us are adopting it yet. A forward proxy for outbound web filtering is great. One that implements SSL decryption and inspection is even better. If your company isn’t already decrypting outbound web traffic, then this needs to be a priority.

Inbound web traffic can be just as dangerous. New IIS vulnerability? Sure, let’s grab the latest IPS signatures and … Oh wait, our IPS runs on our edge firewall, which sits in front of those web servers - which are all using SSL for encryption. That means any malicious traffic is going to slide right through our IPS undetected and land on our unpatched web servers. Get a Web Application Firewall (WAF), and let it front-end your SSL traffic. These things can be expensive and a nightmare to configure and tune properly, but right now they are one of your best options for inspecting web traffic.

Old Attacks Aren’t Going Away - They’re Just Getting an Upgrade

This year’s report highlighted that much of the older attacks are still here, and they’re not giving up yet. Attacks via email are still present and doing more damage than you would hope. We’re certainly getting better about implementing spam filters with reputation filtering, but attackers aren’t giving up yet.

Email attacks are relying more on social engineering and targeted phishing. These messages are also utilizing SSL to encrypt the malicious links within the emails. Infected attachments are surprisingly still a big issue, with Microsoft Office and PDF files still being the worst offenders. Just because attackers are finding new and exciting ways to hit us doesn’t mean they’re giving up on the tried and true methods. We still need to focus on all the standard attack vectors, like email. Implementing intelligent email/spam filters and providing user awareness training are the primary methods we have to combat this.

The Cloud is Secure! …We Think

This one I found particularly fun. Out of all the companies surveyed by Cisco for this report, 57% of them said they believe the cloud offers better security. Wait - Did I misread that? More than halfof respondents think that the cloud offers better security than their own infrastructure! This makes me wonder…

From my perspective, a cloud service provider is just another company. In most cases, they run just another network and hit a lot of the same challenges that non-cloud companies are facing. And we can only assume that cloud providers are prioritizing security and not just trying to turn a quick profit. Cloud companies have the advantage of being able to hire a dedicated security team that their customers can leverage. However, enterprises are complaining about lack of skilled security engineers, and I’ll bet it’s not because cloud providers are picking them all up.

Cloud definitely offers benefits - but this needs to be a well-calculated risk. For a smaller company without dedicated IT staff, a cloud solution would most likely offer security improvements over their own infrastructure. As companies scale, however, their security requirements do too. We need to make sure that the cloud providers we choose are also capable of adhering to those standards. Before you move to the cloud: ask questions about their security practices, get answers, and demand more information on the parts that are important to your business.

Another fun note from Cisco - some of the damage done by cloud providers is a simple mis-understanding of ownership. If you subscribe to a complete Software as a Service (SaaS) provider, chances are good that the provider worries about all of the critical security configurations. However, if you’re going to a cloud provider just for infrastructure (like AWS), then you are likely responsible. In the case of AWS, you’re being provided a server - and that’s where Amazon’s responsibilities end. It’s up to the enterprise to still make sure that those servers are patched, hardened, and audited. Treat the cloud as an extension of your own infrastructure and polices, not a separate entity.

Diversifying Risks? Maybe not

It used to be a somewhat well-established security practice to use multiple vendors. Have a need for two sets of firewalls? Make sure you use two vendors, so that a vulnerability in one doesn’t affect the other. Seems like sounds logic - until you have to train staff to be experts on multiple platforms, and keep up to date on all the latest patches from each vendor.

Cisco is finding that the more vendors a company has in their environment, the more problem we have maintaining everything. From my own experiences, I can say this is certainly a problem. In environments where I’ve had up to four vendors for firewalls and switching, it becomes difficult to work with. It’s hard on IT staff to maintain knowledge of configuration and best practices for each different vendor - and when a new vulnerability comes out, we end up spending way more time trying to track down each vendor’s responses and patches.

It makes sense that companies who have a more tightly integrated infrastructure might have an easier time managing it. Cisco might want you to buy 100% into their ecosystem (of course), but I do think there is value in consolidating your infrastructure. One or two vendors will be much easier to establish relationships with than half a dozen of them. Your IT staff can dedicate their focus to mastering only a couple of technologies, rather than spreading themselves over a dozen different platforms. And when that new vulnerability is released? It should be much more straightforward to patch all of your systems quickly.

There’s That Automation Thing Again

I think we’re finally beginning to reach a point where automation is really showing it’s value in the security realm. A typical company is going to have so many different systems and alerts that it doesn’t make sense for someone to manually review and act upon every one. This is where automation really begins to shine.

Cisco’s report shows that more companies are relying heavily on automation. This can be used for alert response, reporting, and behavioral analytics. Especially when I keep hearing that there is a skills shortage in security, we need to take advantage of what automation can offer. This doesn’t always have to be home-grown scripts either - there are a number of offerings already available.

Take a second look this year. Try to see where automation can fit into your infrastructure to help improve both operations and security.

Thanks for reading! Just as a friendly reminder - All of the opinions stated in this post (and all others here) are 100% my own, and do not represent any vendor or employer. Since security has become more of an important part of my job, reports like this are always very interesting to read. I’ve only covered a handful of what was in the report - just what was particularly interesting to me. If you’re interested in reading more, check out the full report here.

Risk acceptance is something that I’ve seen misunderstood by engineers over and over again. Especially when you’re earlier in your career, you get the feeling that you know what you’re doing - and therefore management should listen to you. I get it - I’ve been there too. It can be hard to propose an idea, then have that idea immediately shot down by your peers or management. That’s not to say that they aren’t listening, but maybe you might not have a great view of everything behind their decision.

Let’s take an example. As an engineer (server/network/security/etc), you’ve been alerted by your vendor that there is a huge vulnerability in a critical business application. That vendor has been extremely proactive, and has promptly provided you with detailed KB articles and download links to the upgrade package. The vulnerability that’s been disclosed certainly seems bad enough - it allows for remote code execution by an unauthenticated user. What do we do with this? Well we immediately meet with management to tell them that we need to patch this application immediately.

Their answer?

No.

Well that seems just impractical, doesn’t it? They don’t really want to leave the company at a massive risk to attack, do they? No - they certainly don’t. However, it may be that management has chosen to accept the risk for one reason or another. Let’s dig into a few reasons why they might:

Expense (Money) - It could be that the cost to remediate the issue is significant. Maybe the software is a bit out-dated and the company hasn’t paid for support. Renewing that support contract might be tens of thousands of dollars or more. If there are enough mitigating factors, that cost might not be worth it.

Expense (Time) - People also cost money, and time spent on fixing this issue also means lost productivity on other tasks. For some enterprises, an upgrade of a critical business application could take months of work. What happens when this new version breaks compatibility with another business application? Well now we’ve added on extra time so we can upgrade both. If there is no other value to the upgrade, then the fix might be held until there is.

Mitigating Factors - There may be enough other security controls in the network to reduce risk. Maybe in this case only the core servers for this application are affected - and they reside on their own network segment behind a firewall. Maybe that firewall also runs an intrusion prevention system, which has already been updated with signatures to stop this particular attack. There could be a number of things going on which have given management the comfort that the system is still safe.

Any of these might lead to the final decision: we’re going to live with this risk. By accepting it, we’ve evaluated it, we’re aware of it, and we are consciously choosing not to fix it. We may have limited the scope of this risk via other mitigations - but ultimately we are not completely ridding ourselves of this risk.

Does risk acceptance only apply to security? Nope. It applies to just about anything really. What if I recommend that we need to replace older hardware or risk network instability? That risk could be acceptable if the hardware isn’t critical. Same thing goes if we decide to forego renewing support on a pair of firewalls. Maybe it’s even suggesting an implementation of a new technology. Proposing to a big cloud provider that they should prepare for IPv6? There is a good chance they may still accept the risk of IPv4 depletion 🙂

As an IT engineer, it’s not just our job to keep things running and get projects done - it’s also our responsibility to keep the best interests of the business in mind when it comes to design, implementation, and maintenance. We need to evaluate all our options and always recommend what we think the best path is. However, we also need to respect that our recommendations may not always be followed. There may always be something else going on that we’re not aware of.

One last piece of advice I can give - If there is ever something you feel very strong about, get the final decision in writing. If you truly feel that the risk is too great, and you’ve made your pitch that has still been rejected - get the decision in writing (whether email, chat log, etc). This may seem silly at the time, but it’s better to be safe. People forget, whether intentionally or not - and if the risk becomes a reality, you don’t want to give them any reason to put the blame on you.