Posted: 21 Aug 2008 06:17 AM CDT
August 21, 2008 - Volume 3, #71
Top Security News
Taking the wraps off PCI 1.2
Top Blog Postings
What do Will, Skill, Bill and Nil have in common?
Posted: 21 Aug 2008 12:15 AM CDT
Today, we are releasing a brand new version of the Personal Identity Portal (PIP). With support for two-factor authentication, the PIP remains a strong OpenID provider as VeriSign remains committed to the broad deployment of OpenID across the Internet. Beyond OpenID, the new PIP also includes some unique identity management features. As the user-centric identity movement reaches beyond authentication and attribute exchange, we wanted to evolve the PIP into an identity aggregation service that enhances control, convenience and security over personal data even when the data is scattered across non-interoperable Web sites.This theme of identity aggregation is going to remain an important product philosophy for us moving forward. Our first implementation focuses on personalization, convenience and security. This post provides a brief overview of the new features. For those of you who never read product description, you can sign up for a free PIP account here. For the more curious minds, please, read on, and let us know what you think.
Posted: 20 Aug 2008 06:20 PM CDT
I am not sure if it is my heightened sense of post-DefCon paranoia, but this just seems like a bad idea to me. If I were a hacker, wouldn’t I just love a way to insert myself into the payment process? With most security analysis processes, I start by examining trust relationships I can exploit. This tends to be fertile ground for logic flaws, and these trust points tend not to be closely inspected by users. If I can insert myself into an established trust relationship to launch my attack, I am far more likely to succeed, and this seems like an open window for me to do just that. Bogus image tags, XSS, XSRF, inline frames, or whatever attack du jour; it seems like a natural target for inserting myself between these two trusted entities. I am not saying that any particular merchant site is insecure at this time, but I am willing to bet that regardless of any vetting process third parties go through, their security is not uniformly as strong as eBay’s and PayPal’s.
In general, I have no relationship with any of the third party merchant software, so I have no reason to trust the sites or their security. I make purchases on eBay with PayPal because I have a basic trust in their sites, processes, and security teams. This trust does not fully extend to every one of their affiliated merchants and third party sites, now and in the future. Not only that, the third party site offers me, the buyer, no added value, only potentially decreased security.
From PayPal’s own “Top Ten Safety Tips”, which they provide with the Security Key, tip number nine is “Stay Safe on eBay: … Pay safely using PayPal, the secure payment method that enables you to shop without sharing your financial information with the seller”. But if the merchant has been linked into the process, and you have to go to a merchant site first, it is somewhat at the seller’s discretion. And if the merchant site has been hacked, all bets are off.
I sent the question over to eBay and PayPal security and have not received a response, so I wanted to know what the community at large felt about this.
Posted: 20 Aug 2008 04:06 PM CDT
The Verizon Communications Inc. (NYSE: VZ) Business Division Security Blog’s Peter Tippet has posted a detailed update to the companys’ previously released 2008 Data Breach Investigations Report (DBIR) in June. If you haven’t already done so, download the report from the Infosecurity.US Document Repository.
Posted: 20 Aug 2008 03:41 PM CDT
Adobe’s (NasdaqGS: ADBE) PSIRT (Product Security Incident Response Team) has acknowledged, but not provided a timeline for the fix (specifically for the recently reported Flash based exploit). Many mainstream sites, including MSNBC, CNN, NBC, CBS, ABC, YouTube (the list goes on…) are at significant risk, and are definitely in a pickle.
Posted: 20 Aug 2008 10:38 AM CDT
Next week I’ll be out of the office on one of my occasional stints as a federal emergency responder. I haven’t had the opportunity to do much since we responded to Katrina, and, to be honest, am surprised the team still lets me hang on (it’s in Colorado, I’m in Arizona, and I don’t get to train much anymore). Who knows how much longer I’ll get to put the uniform on- the politics of domestic response are a freaking mess these days, with all the cash funding the war, and I won’t be surprised if some of the more expensive (and thus capable) parts of the system are dismantled. Hopefully we can hang on through the next election.
Anyway, enough of my left wing liberal complaints about domestic security and on to incident management.
Although I haven’t written much about it on the blog (just the occasional post), one area I talk a lot about is incident response and disaster management. Translating my experiences as a 9-1-1 and disaster responder into useful business principles. I’m frequently asked where people can get management level training on incident management. While SANS and others have some technology-oriented incident response courses, the best management level training out there is from FEMA.
Yes, that FEMA.
For no cost you can take some of their Incident Command Systems (ICS) courses online. I highly recommend ICS 100 and ICS 200 for anyone interested in the topic. No, not all of it will apply, but the fundamental principles are designed for ANY kind of incident of ANY scale. If nothing else, it will get you thinking.
And while I’m at it, here’s a definition of “Incident” that I like to use:
Although I’ve sat through a lot of the training before, I never actually went through the program and test. I’m fairly impressed- these are some of the better online courses I’ve seen.
Posted: 20 Aug 2008 10:00 AM CDT
Here are some of the recent — and thought provoking — conversations of the Security Catalyst Community (SCC):
Opportunities to meet, network and join together
Join the in the Discussion!
Your participation is your currency (means no charge to join) - the more you contribute the more you learn and the more valuable the community becomes to everyone (so dive in and share). If you have not yet registered, please remember to use firstname.lastname as the standard.
Posted: 20 Aug 2008 07:27 AM CDT
Off to see client X this morning. I’m rather optimistic that this will be a good day.
Click here to subscribe to Liquidmatrix Security Digest!.
And now, the news…
Posted: 20 Aug 2008 07:11 AM CDT
So why the fuss over the MIT student presentation that “never was” at Defcon? Why the court order barring them from speaking AFTER the presentation had been handed out to 7000 or so attendees and had been available on an MIT website for several months?
Well, money. MBTA is drowning in red ink.
From The Boston Globe:
Well, the gag order has been lifted. Which, in all fairness, should never had been in place to start with.
The MIFARE wireless chips are popping up in transit systems all over the place. Case in point, in the greater Toronto area (GTA) an amalgamated transit card is being rolled out that will provide users the ability to travel several systems on one card. London’s implementation of Mifare technology has been less than stellar.
Our own Myrcurial attempted to contact the Prestocard folks about the Mifare technology at the beginning of July but, he was given the Heisman (a “straight arm” for the non-sports inclined). So, is the Presto Card headed for an epic failure? We’ll have to wait and see.
Posted: 20 Aug 2008 06:31 AM CDT
Where there’s money to made, illegally, you can be sure someone will hear the call of easy money. One such gang was taken down a few days ago by UK police.
From ZDNet Asia:
This is nothing new except that the criminals were threatening their victims into installing them. Usually the perps aren’t quite so brazen opting for a more discreet approach.
Posted: 20 Aug 2008 12:49 AM CDT
Earlier today, the US District Court dealt a victory to the MBTA hackers and the EFF, lifting the injunction issued on August 9th to prevent the three MIT students from presenting their findings at DEFCON 16. In summary:
This sets a good precedent for future cases, and perhaps next time a similar situation arises, a judge will not be so quick to issue a gag order. It’s not a happy ending yet though, as the original lawsuit is still in effect.
As Chris Wysopal pointed out last week, the MBTA’s ire is misdirected. Rather than suing the vendor who sold them the defective system, they sued and attempted to silence the students who discovered the weakness. This is 2008, not 1988 — did they honestly think a gag order would prevent the information from reaching the general public? The DEFCON presentation was already available on the Intertubes prior to the injunction being issued, and the MBTA attorneys included a copy of the confidential whitepaper with their filing, thereby making it public.
I guess you wouldn’t expect that a transit authority would have paid any attention to theCiscogate fiasco from a few years ago. That presentation never got out either, did it? All that taxpayer money the MBTA spent on ridiculous lawsuits and restraining orders could have been put toward fixing the security flaws. What a concept.
Posted: 19 Aug 2008 10:39 PM CDT
And I thought we weren’t going to be part of the disaster recovery test on Friday. Boy was I wrong! In the early hours of Friday morning we had a hardware failure on the firewall for the link used for the VPN to the disaster recovery site for our mainframe (which was conducting a DR test on Friday). To add insult to injury this was the same link that our remote users use for access. So Friday morning El Sidekick was taking fire from all directions with remote users unable to get in. During all of the chaos it escaped everyone except for myself that the DR test was dead before it even began. A remote user can drive to the office if remote access is unavailable. The DR test doesn’t have the same luxury.
Let’s get to the heart of the problem…the hardware failure. Luckily, we had a spare firewall appliance sitting in a closet that had been retired because of some reliability issues. Unluckily, I had never deployed a Check Point firewall on a Nokia appliance before. I have been administrating them for over four years now but have never installed one. Oh, did I mention we didn’t have support on this hardware (or Check Point for that matter)? So I was on my own to figure this out. Nothing better than having the pressure of an expensive disaster recovery test sitting on your shoulders as you try to figure something out that you’ve never done before! This stuff isn’t rocket surgery and it didn’t take too long to get the ball moving. I figured out how to wipe the previous config (rm /config/active). After going through the IPSO setup we were able to then delete the previous Check Point packages and install new/fresh ones. Well, that was the plan anyway. I went to the most likely place to have a copy of the package I needed, our SmartCenter server. Not there. Fother mucker! Okay…now what do I do? Maybe its on one of the two firewalls at the other location. First firewall check? Not there. Shit. Second firewall check? Jackpot! So I FTP that down to a FTP server and upload it to the firewall I’m trying to load. The upload was successful so I went to install the package. Corrupt. Son of a bitch! Well that left us with one last chance to get this firewall operational. The unit that replaced this retired hardware I was trying to install came with a cd that had a new IPSO version on it along with a new Check Point version. Hells bells, let’s upgrade the IPSO and install this newer package. I got the IPSO upgraded no problem, got the Check Point package uploaded and installed. Everything seemed to be falling into place. I added the firewall into SmartCenter and tried to initialize the SIC. It failed and I really didn’t know where to go from there. By this time it was approaching mid-afternoon and people more important than me were needing to know if this disaster recovery test was going to be able to happen in any capacity. Having never done this before and having no idea how much longer it was going to take we decided to go to ”plan B.” ”Plan B” was to connect the router the VPN terminates on to another router and lock it down with ACLs so only the DR traffic can traverse this interface. Luckily I know Cisco way better than I know Check Point so I was able to have access to the VPN site in about 15 minutes as opposed to the nearly 5 hours of trying to work through the Check Point stuff for the first time.
I walked away a beaten man that afternoon. I hate it when I can’t figure something out. Luckily I had the Jack Johnson concert Friday night and my daughter’s 2nd birthday on Saturday to get my mind off of it. Sunday I was ready to give it another go. First thing I tried was to reset the SIC on the firewall itself. You do this by typing “cpconfig” and then choosing the “Secure Internal Communication” option. Guess what, you have to run “cpconfig” after you install a package as well! Had I known that Friday could have ended on a happy note. After I figured that out things went a lot better. Through some trial and error I got the installation down to a science and am now able to do it in roughly 20 minutes. Not to bad considering Friday I’d never done it before! So there you have it. Sometimes you have to learn things the hard way. The things I learned from this failure were numerous and definately learned the hard way!!
Posted: 19 Aug 2008 09:30 PM CDT
In his axiom 'Everything will ultimately fail', Michael Nygard writes that in IT systems, one must:
"Accept that, no matter what, your system will have a variety of failure modes. Deny that inevitability, and you lose your power to control and contain them. [....] If you do not design your failure modes, then you will get whatever unpredictable---and usually dangerous---ones happen to emerge."I'm pretty sure that I've seen a whole bunch of systems and applications where that sort of thinking isn't on the top of the software architects or developers stack. Foe example, I've seen :
So the interesting question is - if there are many failure modes, how do you determine which failure modes that you need to engineer around and which ones you can safely ignore?
On the wide area network side of things, we have a pretty good idea what the failure modes are, and it is clearly a long tail sort of problem, something like:
Presumably each system has a large set of possible failure modes, and coming up with a rational response to the failure modes that are on the left side of the long tail is critical to building available systems, but it is important to keep in mind that not all failure modes are caused by non-animate things.
In system management, human failures, as in a human pushing the wrong button at the wrong time, are common and need to be engineered around just like mechanical or software failures. I suspect that is why we need things like change management or change control, documentation and the other no-so-fun parts of managing systems. And humans have the interesting property of being able to compound a failure by attempting to repair the problem, perhaps the reason why some form of outage/incident handling is important.
In any case, Nygard's axiom is worth the read.
(Apologies to the syndicators for the premature partial post. It turns out that slapping a moquito and publishing to a blog use very similar hand/arm motions. Hmm....another failure mode to think about....)
Posted: 19 Aug 2008 01:18 PM CDT
Greetings from Sierra Vista, Arizona with a long overdue update. While I may have been quiet (rare, I know), I have not been idle.
A few months ago I was focused on tracking down security fundamentals - and how they need to be applied; last week I was able to craft an intense training section that brought a group of professionals through a unique training class designed around that very concept. It was a great week and really has me energized (despite the need for sleep).
I also shared some insights from Into the Breach with a group at Fort Huachucha yesterday. The best part - for everyone, myself included - was the hour-long conversation that ensued after the keynote. We talked about current challenges and how we can face them by addressing the true problems (not the symptoms) and how to engage people to take responsibility while increasing our ability to hold them accountable.
We are going to take some time today to visit Bisbee, AZ before heading up to Tempe, AZ tomorrow. This is our final “pre-tour” trip as we work out the kinks of driving cross-country in the RV multiple times a year, running the business and spending time as a family. This trip was much smoother than the spring “expedition” and we are already looking forward to the onTour launch in September!
As we make our way back to NY, here is our schedule for the next two weeks:
I love Phoenix and look forward to catching up with a lot of good clients, friends and even some new faces.
Arrive: Wednesday, August 20, 2008
Depart: Friday, August 22, 2008
Staying here: http://www.apachepalmsrvpark.com/
We have a lot of friends that we hope to see while we stop in Dallas. The best part of traveling by RV is the complete flexibility to see clients, potential clients and friends (most of whom were once clients or will be clients). We really enjoy life as a family and seeing the country in a way that allows us to work with people we would chose to spend time with!
Arrive: Saturday, August 23
Depart: Monday, August 25
* we have not yet picked a park, but these are the top three options - have experience or insight? Drop me a line *
** Will be meeting some friends and potential clients to discuss how Into the Breach influences “Awareness that Works”; I love the opportunity to discuss my passions and share research. I’m really pumped about this!
Arrive: Tuesday, August 26
Depart: Thursday, August 28
Staying here: http://atlantasouthrvresort.com/
Potential other stops on the way “home”
Are you along our path?
If you are along our path or in one of the cities where we are touching down, I would love to meet, say hello and can offer you a preview copy of Into the Breach! I am currently tweaking the onTour website in time for our September launch and will be announcing the 6-week onTour Fall leg in about a week or so.
Other Quick Updates
Posted: 19 Aug 2008 09:13 AM CDT
August 19, 2008 - Volume 3, #70
Top Security News
Maybe we should check Hoover's file cabinet
Top Blog Postings
I break your cert, and you will like it
Posted: 19 Aug 2008 08:09 AM CDT
The North American Electric Reliability Corporation (NERC) announced yesterday that they had managed to lure Michael Assante away from Idaho National Labs. Assante was formerly CSO for American Power and American Electric Power prior to that.
From the press release:
NERC has made a positive move with Assante’s hiring. It is a touch disconcerting that NERC didn’t have a CSO function previously, when you consider their role:
Hopefully, he will be able to drag pretenders to the throne kicking and screaming into the sunlight.
(Thx to CJ for the heads up)
|You are subscribed to email updates from Security Bloggers Network |
To stop receiving these emails, you may unsubscribe now.
|Email Delivery powered by FeedBurner|
|Inbox too full? Subscribe to the feed version of Security Bloggers Network in a feed reader.|
|If you prefer to unsubscribe via postal mail, write to: Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610|