2-factor auth, target, remote access, and segregation

For the next year, we’re going to hear a ton of speculation and details and suggestions and eventually facts on the recent Target data breach. Whee! It is, however, a personal pet peeve when expectations are made higher than they should be. Case in point follows!

So Target was breached, and Brian Krebs posted an article about how the attackers may have (read: probably) piggy-backed into the Target network by using the credentials of a third party vendor who apparently provided project management services (or HVAC services, the actual business relationship details are vague) to Target and thus had the ability to remotely connect to Target’s network. Makes sense!

Sophos’ Naked Security blog jumps in as well with Did the crooks who broke into Target tailgate the cleaners? and A hearty welcome to all Cyberoamers! The combination of these articles triggers a few thoughts.

First, it’s “easy” to require two-factor authentication for individual users. It’s more difficult to require it for an entire vendor. Who at the vendor gets the other auth factors? Do they share them? Is it software-based? There are logistics questions going on here that make this an annoying task, especially when something like this is planned, requested, and completed more than likely without any oversight in many companies. This is because it’s easier to just do it, and not involve cost centers like security.

Second, I don’t want alarms on remote connections occuring at 2am. I’m sorry, a firm may not have any business connecting at that time (this is why you time-box accounts or the remote connection portal), but sometimes someone may be burning the midnight oil and I don’t want to spend much time chasing these things down every morning when I check out my SEIM dashboard. Yes, you should log these. No, these aren’t valid alarms that should have, on their own, scrambled the security teams.

Third, HVAC and/or physical equipment vendors do routinely require some sort of remote access. This isn’t strange or rare, and is probably especially true when your business owns and operates, in full, building facilities in hundreds of locations.

Fourth, it’s probably not uncommon that the same pipes that connect remote facilities vendors to your remote facilities also connect your payment and data communication to your remote facilities. It’s annoying (not impossible, but highly annoying and costly) to get those truly separated. In other words, I think it would be, very strictly speaking, very annoying to truly segregate retail payment in-scope systems and networks from those that are not in-scope for PCI. This is because it’s easier to just do it, and not involve cost centers like security and IT, which then have to solve the above headaches and I can tell you it won’t effect the retail business revenues in any positive way.

Now, I’ll admit I’m nitpicking here. The major questions still remains as the articles all ask: Why did this third party have access to not only, apparently, the full internal Target network, but access into every remote facility? (I know, it’s easier to just make normal accounts than to take the time to lock them down or limit their scope with whatever remote access tools you’re using.) Why are the payment systems not segregated? (Despite being annoying, this is *still* a valid question to keep on the table.) Where was the rest of the monitoring such as on POS systems, netflow traffic egress, and so on?

Damn, IT and security cost so much money! 🙂

One thought on “2-factor auth, target, remote access, and segregation

  1. The takeaway is obvious to me: Forget firewall, IPS, UTM, and WAF. App-assure RBACs and always provide app-assured MFA schemes. That doesn’t mean RSA SecurID to all of your partners. It means utilizing the right trust relationships in your AD/X.500/LDAP infrastructure with the right ACLs. It means revoking through policy, but providing exception management (expensive, but not really that expensive given what else IT and the business spends on). It means having that extra step when fraud detection systems (think OWASP AppSensor) rank a potential risky situation. This could be a picture of someone’s baby at their specific office. Something that nobody would share or give up, something based on trusted introducer, and something that integrates with RBACs and MFA. Btw, I think YubiKey NEO and a Nexus 5 (or Nexus 7) would be great for partner connectivity, especially if communications and messaging are done with that new Google conferencing gear. It is what Google and Facebook use.

Comments are closed.