A team of IPv6 security experts I highly respect (including my good friends Enno Rey, Eric Vyncke and Merike Kaeo) put together a lengthy document describing security considerations for IPv6 networks. The document is a 35-page overview of things you should know about IPv6 security, listing over a hundred relevant RFCs and other references.
No wonder enterprise IPv6 adoption is so slow – we managed to make a total mess.
After figuring out how packet forwarding really works within AWS VPC (here’s an overview, the slide deck is already available to ipSpace.net subscribers) the next obvious question should be: “and how do I integrate a network services device like a next-generation firewall I have to use because $securityPolicy into that environment?”
Please don’t get me started on whether that makes sense, that’s a different discussion.
Christer Swartz, an old-time CCIE and occasional guest on Software Gone Wild podcast will show you how to do it with a Palo Alto firewall during my Amazon Web Services Networking Deep Dive workshop on June 13th in Zurich, Switzerland (register here).
Not long after I published the blog post arguing against physical appliances, Oven wrote a very valid comment: "But then you'd have 20 individual systems to manage, add licenses to for additional features, updates etc."
Even though the blog post (and the comment) was written in 2013, not much has changed in the meantime.
One of my readers sent me a container security question after reading the Application Container Security Guide from NIST:
We are considering segregating dev/test/prod environments with bare-metal hardware. I did not find something in the standard concerning this. What should a financial institution do in your opinion?
I am no security expert and know just enough about containers to be dangerous, but there’s a rule that usually works well: use common sense and identify similar scenarios that have already been solved.
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.
A great essay by Bruce Schneier about (lack of) security in IoT and why things won’t improve without some serious intervention.
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.
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.