I gave a presentation on Cloud Security, Compliance & Trust the other day. The basic message was to look beyond the Cloud buzzword and see the actual technologies which are used, understand which security principles still apply and which need to be re-thought, giving a rough direction about regulatory compliance in Cloud environments (which of course is non-binding, as I’m not a lawyer), and the importance of trust evaluations (especially) when it comes to Cloud services.
I had the pleasure to sit in Mark Townsley “Addressing Networking Challenges With Latest Innovations in IPv6” session at Cisco Live yesterday and – somewhat inevitably – there was a mention of Facebook having implemented an IPv6-only approach in their data centers (here’s a talk from Paul Saab/FB laying out details). So, with the “IPv6 Panel” looming, I started reflecting on “Why don’t we see this in our customer space?”. This post quickly summarizes some observations and thoughts.
I’ll be on the “IPv6 Panel” at Cisco Live next week and somewhat in preparation I started thinking about what we currently see when it comes to IPv6 deployment in our customer space. We notably observe a large gap between “textbook planning & transition strategies” and what’s happening in real-life in those organizations. I hence decided to write down some of these observations in a quick series of posts to be published in the upcoming days and, maybe more importantly, to reflect on the reasoning of this apparent mismatch between theory and practice. I dare to add a dose of devil’s advocate here+there…
For today let’s start with some comments on IPv6 address planning.
In this part of the series (for the other parts see [1], [2], [3], [4], [5]) we’ll discuss approaches to implement security measures suited to protect from IPv6-related threats on the host level.
In the last few years, attack techniques which fall in the categories of “Credential Theft” or “Credential Reuse” have grown into one of the biggest threats to Microsoft Windows environments. Microsoft has stated more than one time, that nearly almost all of their customers that run Active Directory have experienced “Pass-the-Hash” (PtH) attacks recently.[1] Once an attacker gains an initial foothold on a single system in the environment it takes often less than 48 hours until the entire Active Directory infrastructure is compromised. To defend against this kind of attacks, a well-planned approach is required as part of a comprehensive security architecture and operations program. As breach has to be assumed[2], this includes a preventative mitigating control strategy, where technical and organizational controls are implemented, as well as preparations against insider attacks. This is mainly achieved by partitioning the credential flow in order to firstly limit their exposure and secondly limit their usefulness if an attacker was able to get them. Although we spoke last year at Troopers 15 about “How to Efficiently Protect Active Directory from Credential Theft & Large Scale Compromise”[3], we would like to summarize exemplary later in this post Active Directory pentest findings that we classified in four categories in order to better understand what goes typically wrong and thus has to be addressed. For a better understanding of the overall security goals, we classified the findings as to belonging as a security best practice violation of the following categories: Continue reading “TROOPERS16 Training Teaser: Dos and Don’ts of Secure Active Directory Administration”
today I’m going to suspend the “Developing an Enterprise IPv6 Security Strategy” series for a moment and discuss some other aspects of IPv6 deployment.
We’ve been involved in a number of IPv6 projects in large organizations in the past few years and in many of those there was a planning phase in which several documents were created (often these include a road map, an address concept/plan and a security concept).
Point is: at some point it’s getting real ;-), read: IPv6 is actually enabled on some systems. Pretty much all enterprise customers we know start(ed) their IPv6 deployment “at the perimeter”, enabling IPv6 (usually in dual-stack mode) on some systems/services facing the Internet and/or external parties.
Unfortunately there’s a number of (seemingly small) things that can go wrong in this phase and “little errors” made today are probably meant to stay for a long time (in German we have the nice phrase “Nichts ist so dauerhaft wie ein Provisorium”, and I’m sure people with an IT operations background will understand this even without a translator…).
In this post I will hence lay out some things to consider when you enable IPv6 on perimeter elements for the first time. Continue reading “Things to Consider When Starting Your IPv6 Deployment”
In the previous parts of this series (part 1, part 2, part 3, part 4) we covered several aspects of IPv6 security, mainly on the infrastructure level. In today’s post I will follow up by briefly discussing so-called First Hop Security features.
In this part of our little series (part 1, part 2, part 3) we continue discussing IPv6 specific filtering of network traffic, namely at intersection points.
As stated in the 1st part, a number of potential security problems in IPv6 networks are related to Extension Headers of IPv6, in particular when combined with fragmentation. At the same time, as of today (December 2015) there is no Internet service or application that actually needs those headers.
So this is the third part of our little series on securing IPv6 in enterprise environments. In the first part we tried to develop an understanding of threats in IPv4 networks as a kind-of baseline while analyzing the main differences induced by IPv6 and in the second part we laid out protection strategies on the infrastructure level, focusing on network isolation on the routing layer. Today I’ll dive into discussing IPv6-specific filtering of network traffic.
In the first part of this series we tried to identify which risks related to network-related threats actually change when IPv6 gets deployed and hence which ones to take care of in a prioritized manner (as opposed to those which one might be tempted to [initially] disregard with a “has been there in IPv4 already and we did not address it then, why now?” stance). Let’s assume we went through this step and, for those most relevant risks we identified, we want to come up with infrastructure level controls first, before tackling controls to be deployed on the host level (as in many organizations the sysowners of “hosts” like servers in datacenters tend to expect “the network/infrastructure guys to provide the 1st layer of defense against threats”, in particular once those originate from an apparent network layer protocol, that is IPv6).