It’s May Day, and Henry Blodget is celebrating — if that’s the right word — with three charts, of which the most germane is the one above. It shows total US wages as a proportion of total US GDP — a number which continues to hit all-time lows. Blodget also puts up the converse chart — corporate profits as a percentage of GDP. That line, you won’t be surprised to hear, is hitting new all-time highs. He’s clear about how destructive these trends are:

Low employee wages are one reason the economy is so weak: Those “wages” are represent spending power for consumers. And consumer spending is “revenue” for other companies. So the short-term corporate profit obsession is actually starving the rest of the economy of revenue growth.

In other words, we’re in a vicious cycle, where low incomes create low demand which in turn means that there’s no appetite to hire workers, who in turn become discouraged and drop out of the labor force. Blodget’s third chart is one we’re all familiar with: the employment-to-population ratio, which fell off a cliff during the Great Recession and which will probably never recover. The current “recovery” is not actually a recovery for the bottom 99%, for real people who need to live on paychecks. And today is exactly the right day to point that out.

Conversely, today is exactly the wrong day to declare that these broad and inexorable trends are not really big top-down trends at all, and in fact merely reflect the inability of individual workers to “access learning, retrain, engage in commerce, seek or advertise a job, invent, invest and crowd source”. And yet that’s Tom Friedman’s column this May Day:

If you are self-motivated, wow, this world is tailored for you. The boundaries are all gone. But if you’re not self-motivated, this world will be a challenge because the walls, ceilings and floors that protected people are also disappearing. That is what I mean when I say “it is a 401(k) world.”

This manages to be both incomprehensible and incredibly offensive at the same time. I have no idea what Friedman thinks he’s talking about when he blathers on about disappearing protective floors; I can only hope that he isn’t making a super-tasteless reference to the recent disaster in Bangladesh. But it’s simply wrong that today’s world is “tailored” for anybody who happens to be “self-motivated”. Both the self and the motivation are components of labor, not capital, and as such they’re on the losing side of the global economy, not the winning side.

Friedman is a billionaire* billionaire (by marriage) who — like all billionaires these days — is convinced that he achieved his current prominent position by merit alone, rather than through luck and through the diligent application of cultural and financial capital. His paean to self-motivation recalls nothing so much as Margaret Thatcher’s “there is no such thing as society” quote: “parenting, teaching or leadership that ‘inspires’ individuals to act on their own will be the most valued of all,” he writes, bizarrely choosing to wrap his scare quotes around the word “inspires” rather than around the word “leadership”, where they belong.

True leadership, in a society where the workers are failing to be paid even half the fruits of their labor, would involve attempting to turn the red line in Blodget’s chart around, and to spread the nation’s prosperity among all its citizens. Rather than telling everybody that they’re “on their own” and that if they’re not a success then hey, they’re probably just not “self-motivated” enough.

The ultimate Friedman kick in the balls, however, doesn’t come from his lazily meritocratic priors. Rather, it comes from his overarching metaphor: the idea that if you have a 401(k) plan, then you’re somehow in charge of your own destiny. Friedman might be right that we’re living in a 401(k) world, but if he is then he’s right for the wrong reason. In Friedman’s mind, a 401(k) plan is an icon of self-determination: you get out what you put in. “Your specific contribution,” he writes, italics and all, “will define your specific benefits.”

In reality, however, a 401(k) plan is an icon of futility and the way in which the owners of capital extract rents from the owners of labor. Yves Smith is good on this, as is Matt Yglesias, although the real expert is Helaine Olen: the 401(k) is a way for both your government and your employer to disown you, and to leave your life savings to be raided by the financial-services industry and its plethora of hidden and invidious fees. The well-kept secret about old-fashioned pension funds is that, for the most part, they’re actually very good at generating decent returns for their beneficiaries. They tend to have extremely long time horizons, and are run by professionals who know what they’re doing and who have a fair amount of negotiating leverage when they deal with Wall Street. Savers are always strengthened by being united: disaggregating them and forcing them to take matters into their own hands is tantamount to feeding them directly to the Wall Street sharks.

Yglesias says that in a 401(k) world, “you’ve got to save a lot of money for retirement. More than you think.” This is true for five big reasons. Firstly, because wages are shrinking, any given level of savings will constitute a steadily-increasing proportion of any given worker’s GDP-adjusted paycheck. Secondly, because the employment-to-population ratio is shrinking, all workers need to save to support not only themselves in retirement, but also a number of dependents which is also growing over time. Thirdly, because 401(k) plans have lower returns than traditional pension plans, you need to save more in order to make up the difference. Fourthly, life happens: while the money in your 401(k) is nominally there for your retirement, in practice there’s a good chance that you’re going to tap it, at some point, to pay some kind of large and unexpected bill, whether that comes from unemployment or divorce or ill health. And finally, 401(k) plans don’t have the clever cross-subsidy that traditional pension plans have, where people who die early cross-subsidize people who live for a long time. With a pension plan, you get income when you need it — when you’re alive — and you don’t get money when you’re dead, and don’t need it any more. With a 401(k), by contrast, you have to save more than you really need, because there’s always a chance that you’re going to live to 102.

Add them all together, and to a first approximation you arrive at our current world, where pretty much no one relying on their 401(k) is actually saving enough for retirement. If you’re rich today, you’ll probably be fine when you retire. But if you’re someone who (in contrast to Tom Friedman) actually lives on your paycheck, then there’s almost no chance that your retirement savings will be enough, when the time comes. That’s not your fault: the reasons are deeply systemic. And as a result, the solutions cannot possibly be the kind of bottom-up schemes that Friedman is extolling. They have to come from the top: from real leaders, rather than jumped-up “thought leaders“.

*Or was, anyway. Maybe he isn’t any more.

There has been plenty of buzz and chatter on the Internet recently concerning a very large DDoS attack against CloudFlare, with coverage on their blog, the New York Times, and the BBC, among many others.

While attacks of this nature are certainly nothing new, the scale of this attack was surprising, reported to hit 120Gbps. For a sense of scale, your average cable modem is only about 20Mbps, or about 0.016% of that bandwidth.

So how does one generate an attack of that size? The technique that appears to have been used is called DNS Amplification. The attacker will typically use a network of infected hosts, known as a botnet, to send DNS queries to servers, faking the source address to be that of their target. When the servers reply to these queries, they send the reply to that false address.

Since the response packet is bigger than the query packet, the DNS server is helping out in the attack by increasing the amount of bandwidth being used. This is not a new technique, and has been around since at least the late 1990s.

What has changed is how effective this attack is, mostly due to the introduction of DNSSEC records. For example, a DNS query for isc.org/ANY with DNSSEC is only 78 bytes, but the reply is 3,586 bytes — so big it gets fragmented and spread across three packets. This makes it very easy to use a little bit of bandwidth to make a huge attack, and since your compromised hosts don't need to send out a lot of data, it's less likely they'll be detected and shut down.

Open Recursives Are Not the (Only) Problem

A lot of these attacks make use of recursive resolvers to perform this amplification. These are the servers that are typically run by your ISP or by services such as Dyn's Internet Guide, OpenDNS, or Google's Public DNS.

It is intended that the end user will query these servers, they'll take care of finding the answer, caching it, and returning it to the user. In the case of an ISP's resolvers, these are usually locked down so only the ISP's customers can use it. It has long been considered a security risk to operate a resolver that will respond to just anyone (an "open" resolver) without taking special care to consider the consequences.

There has been a lot of renewed interest in finding and shutting down unintentional open resolvers, through things like the Open DNS Resolver Project. This is a good thing, but it only addresses part of the problem. These attacks do not need to use open resolvers; they can use the authoritative servers directly to do their amplification. The authoritative servers are the systems that ultimately serve the answers in DNS.

These are the sorts of systems operated by DynECT Managed DNS and Standard DNS. And since these servers must be open in order to function, it's much more difficult to secure them against abuse and the attackers are using them.

Dyn observed this activity back in December 2011, and it has only gotten worse since then. Other authoritative operators have seen the same behavior, typically DNS queries for "ANY" records on zones that have been DNSSEC signed. We have our own in-house tools for mitigating these attacks, but there has been public work to counter the problem, such as the Response Rate Limiting patches to the BIND nameserver software.

But these are really only temporary fixes in an arms race between DNS operators and the people who want to abuse their systems.

The Real Problem and its Solution

At its core, the problem that enables these attacks to work is source address spoofing. This is when a packet is sent from a computer using a source address that isn't actually on that computer, but instead belongs to some other system — usually not even on the same network, such as a home PC on a cable modem, sending traffic that appears to be from a popular website. This has been seen as a security problem for a long time, and yet there are still plenty of networks that allow it to happen.

The solution has also been around for a while, known as BCP38. This document, part of a series of Best Common Practices, describes a very simple concept of not allowing packets to pass through a router from hosts that shouldn't be sending from those addresses. It was published nearly 13 years ago, and is often brought up in tech circles as a solution to a number of problems, but there is still a lack of implementation on the Internet at large.

It boils down to a very simple logic, described in section 4:

IF packet's source address from within [its assigned space]
THEN forward as appropriate

IF packet's source address is anything else
THEN deny packet

There has been a renewed effort recently to push the adoption of this practice, with a boost from this recent DDoS attack on CloudFlare, with some new websites popping up, such as BCP38.info, and a lot of discussion in public forums. This is something that really needs to be done for the security of the Internet as a whole.

So, if you're a network operator, please consider implementing BCP38. If you're buying internet service, ask your provider about BCP38. The rest of the Internet will thank you.

Written by Chip Marshall, Network and Security Analyst

Follow CircleID on Twitter

More under: Cyberattack, DDoS, DNS, DNS Security, Security

Where do you start?

So you’ve walked into a new job, you’ve been given the task of securing all the things and you are wondering, where do I start? I’ve been there, I think most of us have. It’s a major ask, it’s a bit overwhelming and so I’d like to share some of the questions I ask when in a new environment. (You can apply this to any environment, not just a new one though)

I start by asking 5 fundamental questions, 5 things that I feel cover the core, the basics, the initial things that any org must be doing in order to even have a chance. These aren’t random, they are in order and if you read other “top” lists, you will notice I didn’t invent these or make them up. These are also not exhaustive, there are a GREAT MANY other things you can/should be doing but if you can’t nail these 5, you might be sabotaging your success.

• What is on the network?
• How secure is it?
• What is it doing?
• What do we do when things go wrong?
• What are our rules?

These are nothing to do with any of the latest buzzwords, they are not sexy but if your org cannot master this stuff, you have next to no chance of dealing with todays exotic targeted attacks (or hell the non exotic off the shelf stuff either).

These 5 questions resolve to 5 main focus areas which in turn are made up of a multitude (and more than I mention here) processes. Initially I pick just 4 processes in each area to deliver because I wanted to scope it. That gives me 20 deliverables to measure/work on. I try to make these action oriented, things that I can actually do or implement to improve security. They tend to be a process of some kind or an artifact that can be seen, measured and demonstrated. As with all good processes, they are not complete until they are documented and measure. If you don’t like the 4 I choose, pick your own.

First lets talk about tracking/measuring our progress.

I use a modified COBIT maturity model that has 4 basic levels. 0-3. Why 4? I don’t think many people get to “optimized” and I would move on to something else before working on that. Use 5 if you like.

I use these process maturity scores and colors to produce a heat map. I use the colors to show progress. I would go through and “score” the environment on that process or artifact, honestly, so I would know how much work I had to do to get it to green. Green being a established repeatable process that is documented and measured. That is a wholly achievable goal for any process or artifact and this whole approach is about achievable goals that have a real impact on security.

The heat map approach lets me baseline an org and show real easy to identify progress that execs and digest with a glance. They can see a hexagon go from red to orange to yellow to green and with that simple visual change they can immediately see areas that need resources and work. I’ve used the model to justify what I am working on and to justify new resources multiple times. I can’t think of a simpler way to show progress or highlight issues to a busy exec.

So on to the 5 questions.

What is on the network?

Do you know what is on your network? Do you know who owns it? How it got there? How important is it?

How can you be sure you are securing all the things if you have no idea what “All The Things” consists of? Asset Management flows to vulnerability management and on to a great many IT processes (in fact it can be said that if your IT department is not doing asset management, you cannot do effective security).

The basic premise is that everything that is on the network was put there by us, in a manner that we approve of and is being managed by us.

This means we put it there, we baselined/configured/hardened it and we are patching/logging/backup up/monitoring it. You can’t do all that unless you have good process to onboard new systems, sunset old systems and discover rogue systems. All key parts of your asset management program.

How secure is it?

So now we know what we have, we should measure its security right? We need to check that it’s being patched, and has been deployed with a secure configuration and maybe measure it against some baselines. To do this we need to do some vulnerability scanning.

Vulnerability scanning will measure the patching and configuration management processes of the IT organisation, not just report on vulnerabilities.

Having vulnerabilities is a sure sign that the patch management and/or configuration management processes are broken.

I like to throw password management into this area , how they are being created, used, stored etc in the environment for both users and admins. This includes auditing for default passwords, password policy, looking at how/where passwords are stored and who has access to them.

What is it doing?

Ok next up we want to know what our assets are doing. What is happening on our VPN? Our firewalls? Our network? Our Active Directory/LDAP?

Before we can know all that, we have to ensure things are being logged in a correct manner and to a central location. We probably want to ensure we are doing some looking at time synchronisation across systems so that we can compare timestamps between logs.

If we don’t have a good view into the network traffic that is going into and out of our egress points (we did identify those right?… right?), now would be a great time to look at doing that.

We have no hope of detecting incidents in our org if we are not logging, if we are not watching the network, if our times are not synched.

Many orgs reach directly for the SIEM in times like these and you might wonder why that is not step 1.

Before you can automate a process, you must be able to do it manually.

Before you can SIEM, you must be able to manually correlate events between logs from various systems. A SIEM is not a magical system that makes everything in your environment spontaneously start logging things to a central location in a useful manner.

Once we can do all this, we must put in process to deal with the alerts and reporting that is happening. it is said that a security tool that has no process attached with the output, might as well not be running.

What do we do when something goes wrong?

Stuff will go wrong. Laptops will be stolen, malware will be found, bad links will be clicked on and we all know it. We know it’s not if but when. So what do we do when it happens? Who do we tell? who is in charge? who fixes what?

Start by writing a high level policy for incident response, something that outlines the who, the why, the when. When you have that, work on the what, the Incident Response Process. This is more in depth, more thorough, contains more details and details around the kinds of incidents you might encounter, how to document them, communicate them etc.

It is said that no plan survives contact with the enemy and in this way, very few incident response processes survive being used through an incident.

So test it, often, start simple. Test it, change it, evolve it, grow it, retest it in more complex ways as it matures. Don’t let the first test of your incident response process and capabilities be a real incident.

A core piece of incident response is getting back to business. depending on the kind of incident this can be simple or monumental. Plan for it. Back things up, have plans to rebuild systems. if you started with asset management you should have a starting point on which systems are important and need to be recovered first if the incident is massive.

What are our rules?

We need some rules, we need some guidance, we all need to be working from the same playbook. Our IT needs a set of rules, our users need come education, our developers need both. We might have external rules we need to follow also. We might also need to measure some things.

We need a master plan for security, the basic set of rules that lays out our core rules for security. The enterprise security policy. This forms the core of the other policies we lay out.

Our users need training and awareness. Security doesn’t come naturally to everyone and people need to be taught what is important, why it is important and their role in the bigger picture.

Users need to be educated regularly on what our rules are and how to be secure. They are the single biggest vulnerability we have. Even after we secure everything, a single user can undo everything with a uneducated click.

We also need to measure some things. The org probably wants to know how secure they are, what their money is buying, what we are doing to secure all the things. If we’ve done things right, just about every process we implement should have some kind of metric. This serves to show others that it is being done and to keep us honest. If no one is looking at the metrics, it’s easy to drop the ball and shortcut the metric. I’ve often used metrics to drive IT to implement a process. Simply say you will measure something and they will implement process to drive that metric in the right direction.

Get your metrics from good security, don’t let metrics drive the security.

Now these translate into 5 Programs with action oriented deliverables. (Part 2 coming soon.. ish)