Third-Party Contractors: The Target Breach’s Bulls-eye

Target has reached a number of settlements with different financial institutions – including Visa and MasterCard – over its 2013 data breach, paying more than $100 million dollars to reimburse the funds lost compensating customers affected by the hack. This may seem like a huge sum, but it’s only the latest in a series of financial hits Target has taken. In 2013 and 2014 alone, the retailer was expected to have lost $162 million as a result of the exposure of 40M customer debit and credit card accounts, with analysts forecasting as much as $1 billion in damages before all is said and done.

The incident serves as a stark reminder that an enterprise’s security strategy is only as strong as its weakest link. In the Target case, the hackers, who eventually gained access to the retailer’s point-of-sale terminals, entered the network through a HVAC contractor, despite the fact that they had limited access to Target’s IT infrastructure. Once inside the network, many of the traditional perimeter-focused security measures deployed by IT had already been bypassed, allowing the criminals to actively siphon payment data for almost a month.

Unfortunately, there is no foolproof solution for preventing breaches like the one experienced by Target. Enterprises trying to avoid a similar fate must control a number of variables, some of which can’t be accounted for via traditional defenses such as firewalls and anti-malware scans. One such factor is identity, which involves access privileges, authentication and a host of other processes associated with managing a company’s most vulnerable asset: its users.

Identity and access management systems are an essential part of the puzzle, and there are many ways in which the right IAM system could have helped Target during its data breach:

  • Visibility: You can’t protect yourself from something you can’t see, making visibility and control of access privileges essential for keeping tabs on who is accessing what. With an emphasis on mission-critical applications and data, IAM systems offer data controls capable of assuring user access privileges conform to the appropriate policy.
  • Detective Controls: These controls make decisions related to certifying user privileges and revoking access when inappropriate or rogue access patterns exist. For instance, if you noticed your HVAC vendor had access to your credit card data, it would set off major red flags. Additional security can be assured by enabling event-based certifications, which automatically trigger processes for manager review/approval whenever users’ privileges are changed.
  • Robust Access Policies: IAM systems can detect and prevent “toxic combinations” of access privilege that can be created when an employee changes rolls, when policies are changed and countless other scenarios. These policies enforce network segmentation by restricting certain access privileges from interacting and assuring that users only have access to data and applications within their workflow.
  • Automated Account Reconciliation: This feature of IAM deals with the issue of “rogue users” or employees who grant themselves unauthorized access privileges. Automated account reconciliation processes (which can be run nightly to reduce network strain) detect privileges granted outside of the typical provisioning processes and immediately flag users to the relevant approvers or automatically de-provision access.

Has your company integrated an IAM system into its security strategy? Sound off in the comments below to let us know about your experience.


One thought on “Third-Party Contractors: The Target Breach’s Bulls-eye”

  1. The HVAC creds were only used for initial access. So credit card data was not being accessed and syphoned using that specific ID. Nevertheless, controls around time of access and other metadata information that could be policy driven within SailPoint around that 3rd party access are still cogent to the discussion as per the article.

    What ISN’T mentioned in the article that SailPoint and IdM could and should have a very big part to play in gathering and providing governance around is Non-User IDs — testing IDs, training IDs, generic admin IDs (that should be PAM’d anyway), **application IDs**, etc.

    To an attacker, an ID is an ID is an ID. It doesn’t matter whether it’s technically a user ID with governance around it or a Non-User ID that typically is not being properly tracked and governed within an organization. Non-User IDs represent a bit of a governance challenge because ideally they should be associated with owners and then those IDs and owners become part of the joiner, leaver, mover lifecycle management and access certification cycle.

    Most organizations have no optics into these IDs whatsoever, much less active governance around them. Not only do organizations not have good governance around them, they typically don’t have much governance around the CREATION of these IDs (an active NUID request and approval process) and so these IDs are handed out like candy in organizations. (Who wants to stand in the way of handing out and asking hard questions around an application ID that will enable a multi-million dollar application for example?! Or 15 training IDs necessary for the 15 highly paid rock stars your organization just hired?!)

    Governance around Non-User IDs is something that SailPoint is very good at doing and every organization should initiate efforts into looking into the gaps and exposures here as again, very few organizations actually are.

    If you have access to SailPoint’s Community forum (formerly called Compass), be sure to check out the white paper SailPoint has written aimed directly at solving this problem of Non-User IDs using SailPoint IdentityIQ.

Leave a Reply

Your email address will not be published. Required fields are marked *