January 09, 2008 - Volume 3, #3

Good Morning:
Over the holidays, we got to spend some time with my brother-in-law and his family - including my 7-month old niece. Babies are a lot of fun, as long as you can give them back when they start to fuss or decide that it's cool to start their day at 2 AM. As my own kids get older, there are times when I miss the days when they didn't talk, didn't walk and for the most part, minded their own business.

Now a favorite pastime for my girls is to bicker. You know the sweet sound of chatting, then annoyance, and then outright rage - which usually accompanies crying, screaming, and for the last few weeks - fighting. Bickering is cute (in a weird way) because the girls are actually learning an important lesson. They need to be able to deal with frustration and handle issues in a more positive fashion. 

At some point (unless Pavlov was wrong), they'll figure out that screaming at each other isn't really productive and by calmly discussing the issue - they'll be able to come to a common ground. Or maybe they can actually agree to disagree. Of course, they may be 30 by the time this happens, but I'm confident it will happen.

When the girls start to bicker at home - it's not an issue. We separate them and the behavior usually stops. Yet, when you are on a road trip and separating them means, well you can't, you're kind of hosed. That's when I put in the other ear plug of my iPod and wait for the storm to blow over. Too bad the Boss doesn't have that option. Maybe for the next trip, we should bring her iPod along as well. I'll call that the Ostrich parenting method. Turn up your iPod and hope the problem goes away. Or at a minimum that no one ends up in the hospital.

This got me thinking about bickering in our work lives. Having spent far too many years doing battle to get my way, I'm pretty sure that inflicting your will on everyone else you work with is a recipe for disaster. Especially in a security role. You can certainly be Dr. No, and bicker with everyone that wants to open up a port on the firewall or roll out a new application or let those pesky contractors in to the applications from wherever they may reside or even build an integrated business process with a trading partner.

What you'll find is that you quickly lose your credibility and then the operations folks will go around you and do it anyway. That's when you know it's time to pack up camp and set up your tepee somewhere else. Sometimes they "forget" to consult the security folks before rolling out a major initiative. Most of the time it's very intentional. If you make their life harder, they'll ask for forgiveness, not permission.

So the next time you find yourself bickering with a colleague over something minor, think about how those actions are impacting your credibility. It takes you years to be invited into the conversation, and you can blow up all that hard work with one ill-advised NO.

Have a great day.

The Dutch Couple image originally uploaded by billbarber1

Technorati: Information Security, CSO, Security Mike, Internet Security

The Pragmatic CSO: Available Now! Read the Intro and Get "5 Tips to be a Better CSO" www.pragmaticcso.com

Get Your Special Report: 6 Easy Steps to Protect Your Identity and get access to Security Mike's Portal today www.securitymike.com

Top Security News

Hopefully there was a crisis communications reserve...
So what? - It came to light yesterday that yet another of the "Hacker Safe" certified web sites was compromised and private data stolen. This time is was Geeks.com. But isn't that certification indicative that the site is actually "Hacker Safe?" Yeah right. Nothing is safe from a determined and talented bad guy. And I've always thought these web site testing services set the wrong expectation for customers. And McAfee laid down a cool 50 big (that's $50 million for those not familiar with Incite lingo) to buy access to that market. Hopefully they also built in the cost of some extra PR spin-meisters to deal with these situations, which will inevitably happen. ScanAlert (the company that provides the Hacker Safe service) is blaming the customer, which is always a good customer retention tactic, by saying their certification was revoked a number of times in the last year when they found vulnerabilities. HUH?!?!? I wonder how many of ScanAlert's customers pass the certification EVERY SINGLE DAY? If it's a lot, then the scans are not very rigorous, now are they? And even when the customer does address the issue, ScanAlert has no way to know if their systems were compromised when they "weren't certified." So the web site then proudly displays their little date-stamped image, while the bad guys are running roughshod over the database and stealing data. That's why you need to monitor your own financials and credit accounts (as Security Mike says) because don't believe that anything is really "Hacker Safe."
Link to this

The NAC customer sat tactic
So what? - This week's NAC shill newsletter on NetworkWorld brings up an interesting point, which is how to introduce the technology into an environment, especially when it's likely that a large percentage of machines will fail the endpoint checks. That was the case at Columbia University Medical Center, who did a NAC pilot and turned on blocking. So all those devices that weren't up to snuff with the latest patches and up to date AV, were bounced from the network. User unhappiness ensued, which is shocking. NOT. Tim Greene's point is that it's probably a better idea to run the device in monitoring mode initially and have some way to notify those offending devices that they'll be bounced out of the network if they don't fix their stuff. Of course, having up to date AV and patches doesn't mean a machine is actually clean, but there is a better chance of that than if the machines aren't up to date. Which brings us to the next topic, the inevitable NAC fallout has started. Caymas went belly-up last year and now it seems Vernier is relaunching as something else. We saw FireEye take a similar tactic in starting initially as a NAC vendor and then quickly spinning their stuff as new IPS-type stuff. Of course, the NAC-sters will come running to the defense of the market and say those are execution problems, not market problems - and they'll be partially right (so you can give your fingers a rest Shimmy). But not entirely right. NAC disappointed in 2007 and will also suffer more of a shake-out this year. Yes, that's a preview of my 2008 Incite on NAC.
Link to this

Understanding open source business models
So what? - In one of my 2008 prediction pieces I mention the fact that a lot of emerging security technology will happen via open-source. So what? What does that have to do with an end user, since I'm supposed to be writing from the perspective of the practitioners out there? It turns out that every time you buy something, you are implicitly validating the vendor's business model. I'm sure you still have some road rash scars of making a big commitment to some bubbleicious technology back in 1998 that went belly up because it turns out making a profit is kind of important. So end users need to think about open source as well. This piece in InformationWeek lays out the 5 main business models inherent to open source. It's stuff you already know, but probably haven't thought about it in this context. Is there an open source alternative to what you are buying? Does it make sense to cut your teeth on that? What are the operational impacts and TCO metrics to that path? You very well may end up buying the commercial product since having an appliance or support may be important to the bigger picture. But at least you are asking the question before you write the check.
Link to this

The Laundry List

Top Blog Postings

Sticking your head in the sand is not an answer
Kurt Wismer went on a tirade at the expense of RSnake last week regarding the Snake's "contest" to see who could write the smallest XSS proof of concept worm. Kurt thinks that this is going to uncover an attack that wouldn't have been discovered otherwise and that's a bad thing. That we shouldn't trust these researchers because they think like hackers. Hoff asks for our opinions on this, and here is mine. Kurt is wrong. Very wrong. He is reflective of old security thinking. The type of thinking that needs to be exterminated quickly and ruthlessly. One of the statements that usually gets the most laughs in my public pitches is that "the bad guys don't sign a code of ethics." My point is that in all likelihood they are working on smaller footprint and more innovative XSS attacks and they are going to figure stuff out. Then they are going to use it against us. There is a real economic incentive to do so for them, so they will. So we need to engage in similar tactics to understand the attack surface and protect our stuff. How will we defend ourselves if we aren't doing similar research? Kurt's entire argument is based on the assumption that the bad guys aren't going to figure the stuff out anyway. I don't like to make assumptions. That's how you get hurt. If anything, you assume the bad guys already know how to do this, and work that much harder to find defenses against these new attacks. But playing the ostrich game and hoping the problem goes away doesn't work very well.
http://anti-virus-rants.blogspot.com/2008/01/ethical-conflict-in-webappsec-domain.html
Link to this

Those that violate policy must pay
LonerVamp highlights a post from Microsoft's Mark Russinovich (original post here) about how Mark has skirted Microsoft's internal policies to allow autoplay to run on his corporate machine, so he can do some demos to show some new Vista capabilities. There are a couple of underlying themes here. First, it goes to show that GPO's can still be rendered useless by a savvy technologist with local admin privileges. It's an interesting post to see how Mark figured out what the issues were and how he configured his machine to lock out the GPO update from changing the setting. Is this acceptable behavior? I don't think so. If he knowingly violated corporate policies, then there should be some kind of penalty. What kind of example is that to set for the tens of millions of other Microsoft customers that actually depend on GPO to maybe enforce the policies? AutoPlay is bad mojo and should be turned off (another Security Mike tactic). If this demo is so absolutely critical, he should do it on a different machine. Or do it in a virtualization environment on his corporate machine, so the other VM wouldn't connect to the Microsoft domain (and therefore not be subject to the policy). But don't just ignore the policies. Or get a sanctioned rider from the IT folks to say it's cool. Or tell them why that policy may not make any sense. Yes, that takes time and is a pain in the ass. If we security folks are supposed to lead by example, it means we have to eat our own dog food, even if it's inconvenient sometimes.
http://www.terminal23.net/2008/01/irony_in_local_admins_circumve.html
Link to this

The category auto-generator is working over time
I've come down on the term "Security Risk Management" pretty ferociously over the past year because it doesn't mean anything. Or maybe it means everything. Now Symantec is talking about their big compliance story using the term "IT Security Compliance." And they talk about 3 easy steps to get there. Of course, all of this stuff is totally obvious, but it gives the Big Yellow a way to introduce a new graphic and process (Define - Control - Govern) to stay on the right side of the regulators. Of course, it involves buying a lot of stuff in yellow boxes to "automate" the process. Again, I think this is an bass-akwards way of looking at the problem. As opposed to starting with the regulations and figuring out your control needs, why don't you actually figure out how to protect your data and resources. I can assure you that all the regulations were built to do that, so if you do a good job at this protection - you are very likely to be compliant. I guess it'll be another year of tilting at the compliance windmill with my Security FIRST messages.
http://www.symantec.com/enterprise/security_response/weblog/2008/01/it_security_compliance_what_ar.html
Link to this

Recently on the Security Incite's Blogs

Find out what Security Mike is talking about
http://sm-blog.securitymike.com

Check out the latest on the Security Incite blog
http://blog.securityincite.com/

Read the most recent Daily Incite
http://securityincite.com/security-incite-rants/daily-incite