Better Security Data From a Lower Noise Floor

Back in the hazy mists of time, when dinosaurs ruled the earth, I used to warn clients that major holidays, news events, etc., would increase attacks. It was actually in my calendar to do it at the start of the winter holiday season. That is no longer necessary; organizations possessed of competent staff expect this.

I rather expect those same organizations have evolved their strategies well beyond what I advised in those ancient days. But let us dip into history for a bit. Once upon a time, the American 4^th of July holiday was a predictable yearly low point in Web traffic. I do not know if this is still the case, because I no longer track these data; only the least sophisticated organizations do not already have these data already in hand.

Does that mean that I have changed my opinion from almost a year ago, when I wrote that We still fail at log analysis?

Not really, at least in a security context. My experience continues to be that data is far more likely to be retained and (far more importantly) analyzed on short time scales, if it is related to sales, the efficiency of marketing campaigns, correlations to external events that may indicate sentiment shifts, and related matters.

It continues to be all about budgets and perceptions, and the need to mount a business case in support of arguments for security expenditures. This is in no way surprising.

A Bit of Speculation

Assume, for the moment, the following points

- A low-traffic period may be about to occur for many popular Web sites

- All adversaries are not sophisticated enough to proportionally scale back efforts related to network characterization, and related techniques, even if target (you) traffic data are available to them.

It follows that hostile acts would then provide a clearer signal against the noise floor of legitimate traffic. The irony bit is set, in this case: your adversary is not a Magical Being (Black Swans, APT, and other security hype aside) , and is roughly as likely to fail at log analysis as you are. I would speculate that as adversarial sophistication grows, and they more resemble a traditional IT-like organization, the more likely they are to themselves fail in log analysis.

Potential Exploits

'Exploit' has some obvious negative connotations amongst members of the security community, mainly regarding 0-day vulnerabilities, buffer overflows, etc. Sometimes it seems to me that this term is forbidden (much like the term 'hacker') amongst the security community worker.

Personally, I like it. It implies an agressive, forward-leaning security posture. I do not favor passive defense, because the record of that approach seems both clear and unfavorable. That, however, is a matter for another post.

1. You are mostly likely to have extensive data on traffic highs and lows.

2. All else being equal, favor short-term enhanced logging when traffic is low. It's likely to yield valuable information related to common threats, at minimal infrastructure load.

3. Never assume that the data gathered is the entire story. Always allow for the possibility that your adversary is more clever than you, or that you have otherwise underestimated your adversary. E.g. your adversary may have scaled back network traffic to match your expectations.

3. Characterizing the effort required at the 'most-easy' point is a valuable data point when building business cases.

4. When everything goes pear-shaped, be doubly sure that you characterize the response effort. This is a tremendously hard problem, but the value is proportional to the effort. If you get it right, any future risk analyst (who might happen to be sane) will thank $DEITY for your efforts.