Earlier this week, I started back up at TSA supporting their private sector critical infrastructure responsibilities under HSPD-7 and the NIPP. Being new (well, new again), I just had to get on some of my recurring soap boxes. One of them was our doomed-to-failure to security approaches. (Nice to start off on an optimistic foot yeh?) Pretty soon, the conversation narrowed down to the role of CERTs and incident response. In the middle of trying to explain how sending a bunch of guys in trenches to combat an enemy who could nuke from thousands of miles away was a waste of time, I had a revelation: The “bad guys”, with complete cooperation with the “good guys”, are creating a denial of service condition across the country and planet: a Responder Denial of Service – or, an “RDOS”.
What exactly is an RDoS? It works a lot like a syn-flood, which spins up a whole lot of blank connection attempts to a server. The server must receive these connections, wait for awhile to see if valid data arrives, then close them. The thing is, because the sender knows the connections are blank (and using things like botnets and such), it can generate a lot more connection attempts than the server can handle. Eventually, the server gets so busy that it fails to respond to real connections.
Now, think of how we handle “security”. We religiously and studiously avoid building hardened, defensible systems from the ground up and rely on fixes, patches, and incident responders to cope with the eventual problems later (hoping all the while – in vain – that the attacks never come).
What we end up with, by and large, are systems that are so poorly constructed that it takes a large amount of effort to detect, confirm, respond to, and recover from attacks. Further, while attackers can fairly easily attack multiple systems simultaneously, we require dedicated defenders/responses for much smaller groups of systems (or even individual systems). This leaves us with an “RDoS”. Our security philosophies leave so much open that we can never, ever sufficiently resource our defenses at an adequate level. Everyone is occupied. Just ask your incident response vendors, teams, and CERT’s (over beers, of course), about their available resources vs the demand for their services, vs the large iceberg of incidents under the water that aren’t even talked about yet.
As I’ve said before: Good guys – you, we, have failed and will continue to fail if we keep going down this same road. We can’t win until we change strategies completely. We need to embrace our failure and build systems which are defensible from the inside, which are measurably effective against operational/business objectives, and which assume, from the get go, that sections and components have, are, and will continue to be compromised. This hacking perimeters on, giving lip service to change control, and our complete inability to integrate cyber into our ORM and our ORM into our business decision making is a waste of time and resources. We’d be better off spending the money and time elsewhere if we’re going to keep doing security as badly as we do it now.
If anyone disagrees with this post, I’d LOVE to hear a rational argument as to why. (Really!)
(UPDATE: 08/06/10)
I really think some of Bruce Potter’s remarks at Shmoocon in 2009 are pertinent here:
People are getting owned a lot.
Trends
- Increased success in getting past our defenses
- Increasingly malicious motivations. The bad guys aren’t after web defacements
- In spite of the above, we haven’t changed our methods. Its a lot of the same
- Spear phishing and drive-bys are unabated.
What we have is a Maginot line…in depth
Of 66 million websites indexed by Google, 5 percent had drivebys.
These sites with drivebys weren’t just the risky underbelly of the web. It was every category of website. I don’t think that is surprising to anyone who has paid attention to security.
These findings were published last year in in USENIX.
The malicious content on these sites was then scanned using three top Antivirus vendors. The best detection rate among these three vendors was only 75%. The worst was 30%. These are untargeted attacks. Imagine the ability of an attack targeted at your organization to cut through your antivirus defenses.
So What do you do?
NAC? Most people don’t have that deployed even if they’ve bought it.
Firewall Internally?
Token authentication?
Change jobs?
4 comments
Comments feed for this article
August 6, 2010 at 10:36 am
Top 3 NoVA Infosec Blog Posts of the Week | NovaInfosecPortal.com
[...] #1 -We’re being RDoS’d! (Responder Denial of Service) Where’s the product for that? What is an RDoS? Jack Whitsitt introduces us to RDos and how it’s created. If you want to learn more about RDos then click here [...]
August 6, 2010 at 4:36 pm
evejou
I was thinking yesterday about the full disclosure debate and the fact that security vendors, if they want to be relevant, should be as concerned about solving the holes as the vendors themselves would be, rather than waiting for actual exploits to show up. Even cooler (theoretically) would be if security devs could be part of the a vendor’s development process (or maybe that would slow down the already taxing developers’ schedules). But hypotheticals aside, what’s your thought on what a practical solution would be?
August 10, 2010 at 9:02 pm
Jack Whitsitt
Evejou: The problem with solving the holes is that someone has to rationalize the cost/effort to do so. And, while I can’t offer a solution yet, I think that gives us an indicator for where we should begin. We cannot solve the “security” problem – in fact, we don’t even know if it’s a tractable problem – because we haven’t covered the basics yet. We don’t treat businesses like end-to-end systems, so we can’t rationalize/normalize operational and business requirements for our systems. If we can’t express what they should be doing, we don’t know what they should be doing. If we don’t know what they should be doing, we can’t tell where the gaps and risks are. If we can’t tell where the gaps are, we can’t create assured controls.
Finally, if we do manage to do that once, we don’t build that process into how we make decisions at a business level, so the cost of repeating it for changing requirements in changing environments becomes so prohibitive that we don’t do it at all.
Follow the rest of the line of reasoning?
August 29, 2010 at 11:29 pm
Follow-up: Ender’s Shadow Describes RDoS’ing « Jack Whitsitt: Art and Security in Washington, DC
[...] of this blog, but there was a series of passages early on that I think resonate closely with my last post here, and with my overall feeling that we need a real strategy for changing the odds on the cyber [...]