What is normal? It changes most every day, especially when you are 8. We picked up the Boy from a month away at camp last weekend and we weren’t sure how he’d respond to, uh, real life. After seeing him on Visiting Day the week before, we knew he was having a great time. Maybe too great a time, as the downside is the inevitable adjustment period when times aren’t as fun or active or exciting or anything besides 16 hours of non-stop playtime.

To give you some context, we had him explain a typical day at camp. They’d rise at 7, line up to raise the flag, clean up their bunk for inspection, have breakfast, do an elective, then move on to a bunk activity before instructional swim. Then they’d eat lunch. Right, that was just the morning. After lunch they’d have another bunk activity, free swim, rest time, then dinner. After dinner, they’d chill out at the canteen and have an evening activity. Then it was bed time, finally. I get tired just typing up this list.

Think about it — non-stop activity every day for a month. Of course it would take some time to get back into the swing of being home. Let’s just say his activity level at home is not. like. that.

He was fine the first day, as he got fawned over by his parents, grandma and cousins. On the second day we drove back to GA. It didn’t go well. Not well at all. He got a bit car sick and thus the iPad was out of play. That was a problem. So he proceeded to make us miserable for the first four hours of the drive. As much activity as he had at camp, he had none on this day. The 180 degree turn gave him some whiplash. And he let us know it wasn’t fun. As if driving 10 hours was just a load of laughs for me.

Then it hit me — he had the DTs. Thankfully without the vomiting or convulsions, as that would have made a mess in my new car. So we just had to ride it out and let him detox from his activity addiction. He slept, a lot, I listened to a lot of Pandora, and the Boss watched some movies. When we finally got home, he was genuinely happy to be home. He liked the changes we made in the house when he was away. He couldn’t wait to see his buddies.

We still have to manage his expectations a bit by providing a minute by minute description of what he’ll be doing each day. And he’ll have fun, but not as much fun as when he was at camp. Then he’ll be back in school, and fun will be a distant memory. I wonder if they have methadone treatments for that?

-Mike

Photo credits: Novus Medical Detox Center 01 originally uploaded by thetawarrior

Securosis at Black Hat

As Adrian posted on Monday, the extended team is descending on Vegas this week for the madness that is Black Hat and DEFCON. That means not just Rich, Adrian and I, but Mort, Jamie and Dave will be there also. Seems that only Gunnar has the sense to stay off the surface of the sun in August.

I can only speak for myself and my schedule’s been locked down for weeks. But I’ll look forward to seeing some of you on the party circuit through Thursday night. Follow us on the Tweeter and you’ll sure to get some idea of where we’re milling around.

Incite 4 U

1. Beware the PDoS: I’m not sure if Krebs should be flattered or horrified that he’s the unknowing beta tester of all sorts of bad stuff in development. He details his experience as the target of a PDoS (personal denial of service), getting flooded by emails, texts and calls one day. It was a crippling attack, even for someone knowing what they are doing. Amazingly enough shortly thereafter, Brian saw a commercial offering hit to provide the same kind of attack. As you can imagine, if a bad guy was trying to prevent some kind of notification of bad stuff happening (like a huge bank transfer, etc.), shutting down someone’s methods of communication could be pretty effective. So the question for all of us (assuming you require notification and authorization of some types of transactions) is whether your institution fails open (allows the transaction) or fails closed (doesn’t). I’m not going to assume anything, and will be checking all of my accounts ASAP. — MR
2. Mah SIEM sux: Mark Runals’ discusses some of the limitations with misuse detection, examining both statistical analysis and rule based policies, as they relate to SIEM and Log Management platforms. I agree with his conclusion about the value of starting with statistical analysis (you know, baselines) as an easier first step, but keep in mind that threat-model based rules is a great way to isolate specific actions and alert/report on unwanted behavior. Most firms have a handful of very specific actions/attacks they want to detect. But some of the reasons people say ‘Mah SIEM sux’ is that the logs lack enough context and/or some of the necessary attributes, to provide truly effective rules. And the log data is often normalized into uselessness along the way, with correlation focused on network-based attributes that don’t really help you understand the impact of application or system events. Enrichment is supposed to help fill this deficiency, but then rules need to evolve to take advantage of the enriched logs, increasing the amount of work it takes to write rules. This, and the fact that we can’t predict – and subsequently write policies – for all possible conditions we need to watch for. Policies are limited only by the imagination of the policy manager, the time it takes to write/tune the policies, and the processing power available to analyze the ruleset. Not to mention the more granular the policies and the tighter the thresholds – to avoid false positives by identifying specific conditions we know should not occur – the fewer suspect conditions they detect. Sounds like a day in the park, right? Still, rule-based analysis is really powerful for detecting specific problems of misuse. Statistical analysis is part of the balancing act we need to address limitations in rule based analysis; the two are used in tandem to offset the other’s weaknesses. — AL
3. Tracking a moving target: I’m fascinated by the cat and mouse game between malware authors and malware researchers/hunters. Reading a recent post on the Damballa blog called the Evolution of Sinkholes provides some insight to the evolution of C&C traffic. Basically a lot of malware out there has a hard-coded pattern of C&C target servers, but nothing fixed. The targets change daily, providing some agility for the bad guys to set up a new shop whenever they need to. But figure out the pattern, and you can get ahead of it establishing a bunch of sinkholes, as the Damballa researchers (w/ some help from the folks at GA Tech) did. Seems not only will the malware connect to any server meeting the pattern, but then a bunch of security vendors will start poking around the newly established C&C targets as well. Reactive much? — MR
4. Designing Out the DoS: The Building Real Software blog nails it with this post: It’s About Confidentiality and Integrity (not so much Availability). The ‘CIA’ concept has never caught on with those in data security, as maintaining privacy and integrity are way more important than availability. But the really important point is that availability is a DevOps problem. And software engineers usually fall down in this respect. In fact, most software engineers should be looking at ways lessen the impact of DoS attacks during the design phase. Most strive for simple and fast connection establishment to improve user experience, but you really don’t want that the client to have an easy time of it until I’ve validated who they are. For example, with protocol design you can make initial client connections very computationally expensive with simple cryptographic challenges. Or at a service level requiring an authentication requirement prior to the server performing any work. There are lots of tricks that help a service both quickly identify garbage requests, as well as reduce the server’s relative burden when handling client requests. This is something they should teach as part of software design curriculum because availability may not be Job #1, but you can’t ignore it either. — AL
5. Writing a story about losers: Anyone spending any time doing software development knows all about user stories and that metaphor for designing features, functions, and experience. Our man Gunnar takes the user story down a different path by talking about the other side of a user story: a LOSER story where you map out failure scenarios and figure out how to build more survivable systems. Obviously you want to continue focusing on preventing issues where possible (either via controls, better software, etc.), but as we preach with React Faster and Better, shame on you if you aren’t planning for things to go South. — MR