Cisco Encrypted Traffic Analytics (ETA) sounds just a little bit like magic the first time you hear about it. Cisco is basically proposing that when you turn on ETA, your network can (magically!) detect malicious traffic (ie, malware, trojans, ransomware, etc) inside encrypted flows. Further, Cisco proposes that ETA can differentiate legitimate encrypted traffic from malicious encrypted traffic.

Uhmm, how?

The immediate mental model that springs to mind is that of a web proxy that intercepts HTTP traffic. In order to intercept TLS-encrypted HTTPS traffic, there's a complicated dance that has to happen around building a Certificate Authority, distributing the CA's public certificate to every device that will connect through the proxy and then actually configuring the endpoints and/or network to push the HTTPS traffic to the proxy. This is often referred to as "man-in-the-middle" (MiTM) because the proxy actually breaks into the encrypted session between the client and the server. In the end, the proxy has access to the clear-text communication.

Is ETA using a similar method and breaking into the encrypted session?

In this article, I'm going to use an analogy to describe how ETA does what it does. Afterwards, you should feel more comfortable about how ETA works and not be worried about any magic taking place in your network. ?

Whether it's Dropbox, LinkedIn, MySpace, PlayStation, or whatever the latest breach happens to be, it's almost inevitable that you will be caught up in one of these breaches and have your username, password and possibly other information exposed in a data dump. Here's how to respond when that happens.

I'm a big fan of Let's Encrypt (free, widely trusted SSL certificates) but not a big fan of most of the client software available for requesting and renewing certificates. Unlike a typical certificate authority, Let's Encrypt doesn't have a webui for requesting/renewing certs; everything is driven via an automated process that is run between a Let's Encrypt software client and the Let's Encrypt web service.

Since the protocols that Let's Encrypt uses are standards-based, there are many open source clients available. Being security conscious, I have a few concerns with most of the clients:

• Complication. Many of the clients are hundreds of lines long and unnecessarily complicated. This makes the code really hard to audit and since this code is playing with my crypto key material, I do want to audit it.
• Elevated privilege. At least one of the clients I saw required root permission. That's a non starter.

I wanted to jot down some quick notes relating to running a virtual Firepower sensor on ESXi and how to validate that all the settings are correct for getting traffic from the physical network down into the sensor.

Firepower is the name of Cisco's (formerly Sourcefire's) so-called Next-Gen IPS. The IPS comes in many form-factors, including beefy physical appliances, integrated into the ASA firewall, and as a discrete virtual machine.

Since the virtual machine (likely) does not sit in-line of the traffic that needs to be monitored, traffic needs to be fed into the VM via some method such as a SPAN port or a tap of some sort.

Presenter: Eric Kostlan, Technical Marketing Engineer, Cisco Security Technologies Group

"Above all, Snort is a community" -Eric

Snort stats

• over 4 million downloads
• nearly 500,000 registered users

Snort was created in 1998 (!!). Sourcefire founded in 2001.

Presenter: Eric Howard, Techincal Marketing Engineer

"Why aren't we stopping all the malware???"

Presenter: Craig Williams (@security_craig) - Sr Technical Leader / Security Outreach Manager, Cisco TALOS

"I'm from Talos. We love to stop bad guys."

Talos by the numbers:

• 1.1 million incoming malware samples per day
• 1.5 billion Sender Base reputation queries per day

Talos has a serious amount of data. For serious.

Presenter: Jeff Schutt - Cybersecurity Solutions Architect (Jeff works in Adv Services in the IoT team)

Full Title: An IoT Security Model & Architecture for Securing Cyber-Physical and IT-OT Converged Assets

Mix of IT/OT folks in the room.

This post is for anyone who administers a Juniper SSL VPN. I saw an issue in our environment recently that was created by an unexpected interaction between two different systems that were working to enforce our computer security policy. Because the way the systems were configured is pretty common and because the issue is not specifically warned against by Juniper, I'm going to share it here.