So someone is attacking you, maybe with a flood of traffic as a noisy backdrop to distract you while the bad guy slips in undetected. So how do you stop the hacker amidst the noise, fast enough to act to stop the attack? That was the subject of many vendors and conversations at RSA – how to survive the security data deluge. For one thing, just storing the raw data for logging and monitoring can be daunting. But what about getting it back, from whatever sensor, in time to do something about it in a security context?

That question has a lot of security professionals trying new and innovative approaches, highlighted at the show. From slick frontend apps that parse data, to fast hardware and correlation engines, the floor was abuzz with ways to handle security data sprawl within your organization. Here are a few approaches.

1. Outsource the whole thing to the cloud: Well really this could be a hybrid setup, with an appliance installed locally at your facility and then a remote monitoring setup. The advantage is that it’s mostly hands off. The disadvantage is that you might see delays, since the cloud portion of the equation could be many thousands of miles away, and so there’s transfer latency that needs to be factored into the equation.

2. Combine all your logs into one place with a dashboard to monitor it: The advantage of this system is that you retain all your data in house. But do you have enough in house talent to set it all up? And then, you would have to tune the system and make it all work fast enough to respond to an incident in a proactive manner.

3. Trick scammers with sinkhole technology: By placing the digital equivalent of a tarpit at various locations you expect attackers to hit, you can either block them, delay them, or reply with fake information that sends them on a wild goose chase, making them think they’ve broken in so they concentrate their efforts on hacking a decoy of sorts. This really doesn’t directly address the problem of parsing massive log files, but it could blunt large attacks and spearphishing attempts at the perimeter, thereby providing less traffic internally, to keep your logs far less busy. Some third party vendors direct whole sections of DDoS traffic to a remote location where they have the network bandwidth to shunt the attack, forming a remotely hosted proxy sinkhole of sorts.

It seems organizations are using a blended approach to handle the problem, with some sensors managed remotely by third party vendors, consolidating sensor logs you want to keep more internal to the organization, and experimenting with decoy technologies.

Whatever your approach, take some time to vet the technology in a closed, sandboxed test environment before rolling it out enterprise-wide. This way any surprises won’t take down large sections of your network and cause outages.