Category: security

One of my readers sent me a question along these lines after reading the anti-automation blog post:

Your blog post has me worried as we're currently reviewing offers for NGFW solution... I understand the need to keep the lid on the details rather than name and shame, but is it possible to get the details off the record?

I always believed in giving my readers enough information to solve their challenges on their own (you know, the Teach a man to fish idea).

Some of my readers got annoyed when I mentioned Google’s BeyondCorp and RFC 1925 in the same sentence (to be perfectly clear, I had Rule#11 in mind). I totally understand that sentiment – reading the reactions from industry press it seems to be the best thing that happened to Enterprise IT in decades.

Let me explain in simple terms why I think it’s not such a big deal and definitely not something new, let alone revolutionary.

Got an interesting microsegmentation-focused email from one of my readers. He started with:

Since every SDDC vendor is bragging about need for microsegmentation in order to protect East West traffic and how their specific products are better compared to competition, I’d like to ask your opinion on a few quick questions.

First one: does it even make sense?

One of my readers sent me this question:

Do you have any thoughts on this meltdown HPTI thing? How does a hardware issue/feature become a software vulnerability? Hasn't there always been an appropriate level of separation between kernel and user space?

There’s always been privilege-level separation between kernel and user space, but not the address space separation - kernel has been permanently mapped into the high-end addresses of user space (but not visible from the user-space code on systems that had decent virtual memory management hardware) since the days of OS/360, CP/M and VAX/VMS (RSX-11M was an exception since it ran on 16-bit CPU architecture and its designers wanted to support programs up to 64K byte in size).

My friend Christoph Jaggi published new versions of his Metro- and Carrier Ethernet Encryptor documents:

• Technology introduction, including an overview of encryption mechanisms, Carrier Ethernet connectivity models, typical deployments, and key management challenges.
• Market overview, including standards, control- and data plane considerations, key- and system management, and network integration.

Enjoy!

A great essay by Bruce Schneier about (lack of) security in IoT and why things won’t improve without some serious intervention.

The awesome Troopers crew published conference videos, including my Securing Network Automation presentation (more, including slide deck).

Niki Vonderwell kindly invited me to Troopers 2017 and I decided to talk about security and reliability aspects of network automation.

The presentation is available on my web site, and I’ll post the link to the video when they upload it. An extended version of the presentation will eventually become part of Network Automation Use Cases webinar.

Matthias Luft (a good friend of mine, and a guest speaker in the upcoming Building Next-Generation Data Center course) wrote a great post about the (lack of) security in software development.

The parts I like most (and they apply equally well to networking):

In the next session of Network Automation Use Cases webinar (on Thursday, February 16th) I’ll describe how you could implement automatic deployment of network services, and what you could do to minimize the impact of unintended consequences.

If you attended one of the previous sessions of this webinar, you’re already registered for this one, if not, visit this page and register.

A blog post by Russ White pointed me to an article describing how IPv6 services tend to be less protected than IPv4 services. No surprise there, people like Eric Vyncke and I were telling anyone who was willing to listen that operating two-protocol networks isn’t the same thing as operating a single-protocol one (see also RFC 1925 rule 4).

A while ago I wrote:

I haven’t seen any hard data, but intuition suggests that apart from hardware failures a standalone firewall might be more stable than a state-sharing firewall cluster.

Guillaume Sachot (working for a web hosting company) sent me his first-hand experience on this topic:

One of my readers sent me this question:

Using SSL over the Internet is a must when dealing with sensitive data. What about SSL between data center components (frontend load-balancers and backend web servers for example)? Does it make sense to you? Can the question be summarized as "do I trust my Datacenter network team"? Or is there more at stake?

In the ideal world in which you’d have a totally reliable transport infrastructure the answer would be “There’s no need for SSL across that infrastructure”.

My friend Matthias Luft sent me an interesting tweet a while ago:

@ioshints What’s your take on firewall rule sets & IP addresses vs. hostnames?

— Matthias Luft (@uchi_mata) August 16, 2016

All I could say in 160 characters was “it depends”. Here’s a longer answer.

One of my subscribers considered attending the Virtual Firewalls workshop on September 1st and asked:

Would it make sense to attend the workshop? How is it different from the Virtual Firewalls webinar? Will it be recorded?

The last answer is easy: No. Now for the other two.