After being married for coming up on 14 years, some things about your beloved you just need to accept. They aren’t changing. The Boss would like me to be more affectionate. As much as I’d like to, it just doesn’t occur to me. It’s not an intentional slight – the thought of giving an unprompted hug, etc., just never enters my mind. It causes her some angst, but she knows I love her and that I’m not likely to change.

My issue is the dishwasher. You see I’m a systems guy. I like to come up with better and more efficient ways to do something. Like load the dishwasher. There is a right way and a wrong way to load the thing. Even if you think your way is fine, it’s not. My way is the way. Believe me, I’ve thought long and hard about how to fit the most crap into the machine and not impact cleaning function. The Boss has not, I assure you.

Hard to find the right place for this... You know those wider spaces on the bottom shelf? Yeah, those are for bowls, which slide in perfectly and get clean. The more narrow spaces are for the plastic plates without edges. The slightly larger spaces are for our fancy plates with edges. Everything just fits.

That’s not the way she looks at the problem. If there is a space, she’ll just ram the dirty dish in question into the space. Structure be damned. I can hear the bending metal tines of the shelf crying in agony. And don’t be me started about the upper shelf or whether you should actually rinse the caked on food from the dish before putting it in the dishwasher. Let’s not go there.

Her way is just not efficient and that irks me. Of course, I have to fix it. That’s right, regardless of what time it is I’ll likely take everything out and repack it. I just can’t help it. Even when I’m dog tired and can think of nothing more than getting in my bed, I have to repack it. I know, it’s silly. But I do it anyway.

For a while my repacking activities annoyed her. Now she just laughs. Because just as she’s not going to pack the dishwasher more efficiently, I’m not going to stop repacking it until it’s right.

And that’s the way it is.

– Mike.

Photo credits: “In ur dishwashr” originally uploaded by mollyali


Incite 4 U

  1. LHF from Gunnar and James McGovern – I’m a big fan of low hanging fruit. The reality is most folks don’t have the stomach for systemic change or the brutally hard work of implementing a real security program. Not that we shouldn’t, but most don’t. So Gunnar and James’ 10 Quick, Dirty and Cheap Things to Improve Enterprise Security (PDF) was music to my ears. There is, well, quick and dirty stuff in here. Like actually marketing to developers, prioritizing security needs, and getting involved in application security organizations to learn and share best practices. And RTFM – yeah! Of course, in reality some of these things aren’t necessarily easy or quick, but they are important. So read it and do it. Or pat yourself on the back if you are already there. – MR
  2. Diversion, McAfee-style – Before I take my meds, let’s put on the tinfoil hats and speculate on some conspiracy theories. Our friends at McAfee are still spinning hard about their DAT FAIL, talking about funding the channel to finish cleaning up the mess and to restore customer faith as the other AV vultures circle. What better way to divert attention from the screw-up than to leak a rumor about HP fishing around to acquire Little Red, yet again. That’s the oldest trick in the book. The issue isn’t that we screwed the pooch on a DAT update, but wouldn’t it be cool to be part of HP and put a hurt on Cisco? When you don’t want to talk about something anymore, just change the subject. Too bad that doesn’t work in the real world. Not with the Boss anyway. Do I think MFE really leaked something? Nah. Could the rumblings be true? Maybe. But given the ink is hardly dry on the HP/3Com deal, it would seem a bit much to swallow McAfee right now. Especially since McAfee is a little busy at the moment. – MR
  3. Metrics. Kinda, Sorta. – Managers love metrics. In fact they need them. How else do you judge when a software release is ready to go live? We only have a handful of metrics in software development, and they only loosely equate to abstract concepts like ‘security’ and ‘quality’. We use yardsticks like bug counts, lines of new code, number of QA tests performed, percentage of code modules tested, and a whole bunch of other arbitrary data points to gauge progress toward our end goal. And then derive some value from that data. None of the metrics are accurate indications of quality or security, but they trend close enough that we get a relative indicator. That is relative to where you were a week ago, or a month ago, or perhaps in relation to your last release cycle. You can get a pretty good idea of how well the code has been covered and whether you have shaken the tree hard enough for the serious bugs to fall out. Rafal Los, in his post on The Validation Fallacy, makes the good point that the discovery of vulnerabilities itself is not a very good metric. This is really no different than general software testing, with the total number of bugs telling you very little. You may have twice as many bugs this release as last, but if you have four times the amount of new code, you’re probably doing pretty well. In the greater scheme of things you don’t really care about the individual bugs, but the trends. When you are monitoring the output of pen testing or code review prior to release, Defects over Cycles is a handy metric to determine the relative readiness of code, and Recurring Defect Rates indicates which developers need re-education on coding practices. A couple that Rafal did not mention which I find very useful are: Bugs per Module and Bugs per Developer. I have had individual developers responsible for 56% of the bugs, and 80% of the security defects found, in a given software release. These metrics are useful in knowing how to focus your testing, code review, and educational investment. – AL
  4. Evolve or die… – Jimmy Ray asks here whether network security is a dead end career. Sure, the tools are improving, and the attacks are changing, and the path of least resistance is not the network anymore, it’s the applications. But I never looked at security from the perspective of the network or the database or the application. It’s just security. Sure you can (and should) specialize, but that doesn’t mean you are pigeon-holed, does it? Lots of folks started as sysadmins. And then they learned something else when it was time. Dead end, ha! It’s more about being engaged. When you find you aren’t engaged anymore in your daily activities, it’s time to figure out what’s next. And go there. – MR
  5. IronKey, Squishy Login – IronKey announced that they were releasing a version of their USB Drive for online banking this week. Called Trusted Access for Banking, they are offering an encrypted USB drive with a self-contained application for the user to communicate with the bank electronically. Their VP of Marketing, Dave Tripier, states that the two main attack vectors are keylogging and Man in the Middle attacks (MitM). I have written about the ability to create a secure island from which to conduct online banking before. Provided IronKey actually secures DNS lookups and encrypts the banking session on the USB stick rather than on the PC, this approach has a lot of promise. Two very big ifs, but it could help with MitM. But this does not protect against the other threat: keyloggers grabbing system or banking passwords (check out the demonstration). Virtual keyboards thwart most keystroke loggers because they are hardcoded to look for passwords in the keyboard buffer (or on the PS/2 or USB connection, but that’s much less of a concern for home users). But you could still pull the password from the message blocks between the Windows platform and the USB device. Similar hack, just gathering data from a different place. And once a piece of malware has your password, it can either communicate with your bank through your IronKey on your behalf (Cha-ching!), or present you with an unsecured fake (or functional but leaky) banking application. IronKey’s approach will thwart attacks in the short term because the malware has not been specifically written to attack this type of media, but that will take about 24 hours once the drives get deployed. I applaud the encrypted USB vendors looking for new market opportunities, but they are overselling their capabilities here. Keep in mind that encrypted drives are really effective for protecting data when the USB drive is lost. During use, especially when the OS itself has been hacked or rooted, far less protection is available. – AL
  6. Why build one when you can build two at twice the price… – So it seems Microsoft alarmed a number of folks when they announced they will not release the Forefront Protection Manager, which was a stand-alone console to manage the Forefront endpoint offering. Instead they are going to build that capability into the System Center Configuration Manager. Duh. Folks that use Forefront likely have a lot of MSFT product, and the functions tend to be managed by the endpoint team (not the security team, especially in the mid-market), so this makes sense given most customers want fewer management interfaces and consoles. Good for Microsoft: it’s very hard to kill a previously announced product – no matter how much sense it makes. – MR
  7. Learning from Blippy’s privacy FAIL – You’ve probably heard about the Blippy privacy issue, where some of their users’ private information got indexed by Google and, well, that’s bad. One of the key aspects of incident response is containing the damage and then doing a post-mortem to make sure it doesn’t happen again. As you read the analysis on Blippy’s blog, you’ll see the entire process mapped out pretty effectively. Basically how they found the issue, analyzed the damage, ensured no more data loss, and notified the affected folks. Then in the post-mortem section they came clean about their faulty assumptions and put in place a plan to make sure it doesn’t happen again. This is pretty straightforward stuff for us security folks, but unfortunately these guys had to learn the hard way. Now maybe you can learn from them. – MR
  8. SSL Primer for Oracle DBAs – I am surprised at how often I see databases set up with a remote application connecting to a database but not using SSL. I ran across an overview of setting up SSL for Oracle Applications at the Online Training web site. It’s a vanilla introduction, but provides fairly easy steps to set up SSL for Oracle. They also provide an overview of the sequence of handshaking signals used to establish the SSL connection to show how the session is initiated. While they don’t make clear that this sequence of events is used to establish trust between the client and server, it gives you enough information to get SSL working. A lot of DBAs forget to set up SSL with a certificate, or don’t want to wait to get one from VeriSign or another certificate authority. You can also generate your own certificates and import them into the Wallet if you don’t want to bother with the time and expense of dealing with a certificate authority. Just don’t forget to set the listener to require connecting applications to use SSL, otherwise they may default to clear text. – AL
  9. Making the bad guys play defense – Very interesting research from Andrzej Dereszowski, who showed a proof of concept mechanism to counterattack a hacker via issues in the malware. Wouldn’t it be great to turn the tables on the bad guys while they are mid-attack? The reality is the bad guys spend zero time protecting themselves. They leave stolen data on open servers and basically focus all their efforts on offense, not defense. I know it’s probably not legal to launch any kind of counterattack, but who is going to tell? You think the bad guys are going to report you to the FBI for pwning their C&C? Now that would make for a great Black Hat presentation. – MR
Share: