Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (17)
Ähnlich wie Critical Controls Might Have Prevented the Target Breach
Ähnlich wie Critical Controls Might Have Prevented the Target Breach (20)
Mehr von Teri Radichel
Mehr von Teri Radichel (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Critical Controls Might Have Prevented the Target Breach
- 1. 1SANS Technology Institute - Candidate for Master of Science Degree 1 Critical Controls Might Have Prevented the Target Breach Teri Radichel May 2016 GSEC, GCIH, GCIA
- 2. SANS Technology Institute - Candidate for Master of Science Degree 2 The Target Breach • Over 40 million credit cards stolen • Over $200 million in losses • Over 140 lawsuits • What happened? • How could it have been prevented? • The 20 Critical Controls
- 3. SANS Technology Institute - Candidate for Master of Science Degree 3 Reconnaissance ● Google Search ● Microsoft case study and vendor list ● Controls: – Security Skills Assessment / Training – Need to Know ● Result: No useful information for attack
- 4. SANS Technology Institute - Candidate for Master of Science Degree 4 Phishing & Malware • Email sent to Fazio Mechanical • Malware installed • Password stolen • Controls: – Malware Defenses – Security Skills Assessment / Training • Result: Malware fails to get credentials
- 5. SANS Technology Institute - Candidate for Master of Science Degree 5 Vendor Portal Compromise • Stolen credentials access vendor portal • Controls: – Boundary Defense: Limit Network – Account Monitoring / Control • Result: MFA and network controls prevent access
- 6. SANS Technology Institute - Candidate for Master of Science Degree 6 Lateral Movement • Installation of network tools • Scanning and network traversal • Controls: – Controlled Admin Privilege – Secure Network Engineering – Maintain, Monitor, Analyze Logs • Result: Anomalous behavior prevented
- 7. SANS Technology Institute - Candidate for Master of Science Degree 7 Misconfigured Systems • Misconfigured systems allow access • Some passwords left as default • Controls: – Secure Configurations – Account Monitoring & Control • Result: System cannot be leveraged by attackers
- 8. SANS Technology Institute - Candidate for Master of Science Degree 8 POS System Malware • SCCM installs malware on POS systems • Malware undetectable by virus scanner • Controls: – Inventory of Software – Malware Defenses • Result: Malware install prevented
- 9. SANS Technology Institute - Candidate for Master of Science Degree 9 Incomplete Encryption • Unencrypted data in memory • Controls: – Application Software Security – Data Protection • Result: Malware only sees data that was encrypted at swipe (TRSM)
- 10. SANS Technology Institute - Candidate for Master of Science Degree 10 Data Movement In Network • Ports 139, 443 and 80 open • Data moved via NetBIOS shares • Controls – Secure Configuration – Secure Network Engineering – Maintain, Monitor, Analyze Logs • Result: Data movement prevented
- 11. SANS Technology Institute - Candidate for Master of Science Degree 11 Network Tunnels • ICMP tunnel, crafted PING packets • Other customized components • Controls: – Secure Network Engineering – Maintain, Monitor, Analyze Logs • Result: Traffic discovered and blocked
- 12. SANS Technology Institute - Candidate for Master of Science Degree 12 Data Exfiltration • Data moved to compromised servers around the world • FTP used to retrieve data • Controls: – Data Protection – Maintain, Monitor, Analyze Logs • Result: Prevention of data exfiltration
- 13. SANS Technology Institute - Candidate for Master of Science Degree 13 Incident Response Failure • Staff did not respond correctly to alerts • Controls: – Security Skills Assessment/Training – Maintain, Monitor, Analyze Logs – Incident Response Management – Pen tests and Red Team exercises • Result: Response limits damage
- 14. SANS Technology Institute - Candidate for Master of Science Degree 14 Credit Cards Sold • Stolen cards sold on the black market • Control: – Data protection • Result: EMV prevents some use of stolen card data • Note: EMV has limitations; better to prevent loss at source
- 15. SANS Technology Institute - Candidate for Master of Science Degree 15 Summary • Focus on security, not compliance • Determine risk: likelihood + severity • Understand anatomy of common attacks • Protect critical assets • Leverage the Critical Controls
Hinweis der Redaktion
- <number>
- <number> In December 2013, 40 million Target credit cards had been stolen by accessing data on point of sale (POS) systems. Target later revised that number to include private data for 70 million customers. Over 11 GB of data was stolen. Target missed internal alerts and was notified of the breach by the Department of Justice. The breach affected Target, customers, employees and banks. Employees lost their jobs including the CEO and CIO. Members of Target’s board of directors were threatened with removal. Banks had to refund fraudulent credit card transactions and pay $200 million for replacement cards. Over 140 lawsuits were filed against Target. Banks sued Target’s PCI compliance auditor, Trustwave. Target faced investigations involving the Department of Justice, the FTC and SEC and possible state fines. Profits dropped 46% in the fourth quarter of 2013 during the holiday season. Customer visits dropped in the new year. How could this attack have been prevented? One possible solution would be to apply industry standard controls to prevent various steps in the attack. In 2008, the federal government arranged a consortium of public and private organizations to come up with a list of Critical Controls based on various other cyber security lists and guidelines. Critical Controls are added to the list because they help prevent and detect known attacks effectively. The Consortium for Cybersecurity Action (CCA) regularly updates the Critical Controls. The Sans Institute web site provides more details about each control at http://www.sans.org/critical-security-controls. By reviewing the Target breach, the Critical Controls can be evaluated to determine if they would have helped prevent this attack. Each step the attackers took to gain access is a point in the system where the attack could have potentially been thwarted. Analysis of each action can determine if there is a Critical Control that would prevent a similar attack in the future. The steps taken by the attackers and Critical Controls are based on the information available at the time this paper was written: https://www.sans.org/reading-room/whitepapers/casestudies/case-study-critical-controls-prevented-target-breach-35412
- <number> A Google search would have supplied a great deal of information about how Target interacts with vendors. Results would have revealed a vendor portal and a list of HVAC and refrigeration companies. This reconnaissance would have also revealed a detailed case study on the Microsoft web site that describes how Target uses Microsoft virtualization software, centralized name resolution and Microsoft System Center Configuration Manager (SCCM) to deploy security patches and system updates. The case study describes the Target technical infrastructure, including POS system information, in significant detail. Critical Controls: Security Skills Assessment and Training: Use security awareness training to make employees aware of the danger of sharing too much information. Controlled Access Based on the Need to Know: Remove vendor information and Microsoft case study with detailed information about Target technical systems, processes and staff. Restrict access to vendor and technical information. Replay: No revealing data such as the list of vendors found on Target web site. No access to vendor portal web URL unless coming from an approved network. No case study would be published that had details about the infrastructure of the Target stores, systems, software or maintenance processes. Separation of duties would have prevented insiders from having end-to-end system knowledge or access. Result: Attackers would not have found information about what to attack.
- <number> An email containing malware was sent to a refrigeration vendor, Fazio Mechanical, two months prior to the credit card breach. Malware installed on vendor machine may have been Citadel – a password-stealing bot program that is a derivative of the ZeuS banking trojan. The malware stole credentials to an online vendor portal. Controls: Malware Defenses: Require vendors to use commercial virus checking software and other security precautions on the systems used to interact with vendor portals. Security Skills Assessment and Training: Require vendors to go through basic security training or agree to train staff. Replay: Vendor staff is familiar with phishing attacks because Target required vendor training. Commercial virus scanning software prevents installation of malware on the vendor machines. Result: Malware in phishing attack would have failed to install. Attackers would not have obtained access to vendor portal credentials.
- <number> Criminals accessed Target’s vendor portal via Fazio Mechanical’s stolen credentials. Controls: Boundary Defense: Limit network access to vendor portal so anyone who obtained the credentials would not be able to access the vendor portal unless on an unauthorized network. Account Monitoring and Control: Require multi-factor authentication to log into vendor portal. Monitor use of vendor portal logins. Profile accounts for normal activity and usage periods to spot anomalies. Replay: A VPN or restricted network is required to access the vendor portal. Multi-factor authentication prevents logging into the portal without an MFA token. Result: Attacker cannot see the portal from an untrusted network. Attacker with stolen password alone could not access vendor portal since the MFA token would also be required. Vulnerabilities within vendor portal and other systems accessible after login would be unavailable to attacker. Without access to portal attacker could not pivot and access other systems on the network.
- <number> From this pivot point the attackers could have further infiltrated the network. The specific details are not available but we can speculate that the criminals used the attack cycle described in Mandiant’s APT1 report to find vulnerabilities in the vendor portal and move laterally through the network via back doors, reconnaissance and other vulnerable systems. Common network tools were used to do reconnaissance once inside the network. Controls: Controlled Use of Admin Privileges: Access to admin accounts may have allowed attackers to install tools and bypass network segregation boundaries. Secure Network Engineering: Segregate critical systems from the rest of the network. Maintenance, Monitoring, and Analysis of Logs: Monitor for anomalies including malformed or unexpected packets. Replay: Administrative privilege control prevents install of network tools. More well trained staff monitor logs and recognize anomalies, proactively preventing the breach. Better tools and automation discover and prevent anomalous traffic. Result: Limited network and accounts prevent network traversal. Suspicious activity leads to discovery of infiltration and problem is resolved before attackers reach POS systems.
- <number> A Mandiant report describes how reconnaissance in a retail attack uncovered misconfigured systems. A vulnerable system such as a domain controller could be used to obtain access to POS systems. The Microsoft Target Case Study states “Except for centralized authentication, domain name resolution, and endpoint monitoring services, each retail store functions as an autonomous unit” so the attacker would know to look for these pivot points. Another report indicated data was retrieved using the default user name and password for BMC’s Performance Assurance for Microsoft Servers. Controls: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers: Alerts could have been generated by a HIDS when key server configurations were changed. Account Monitoring and Control: Require multi-factor authentication for critical accounts. Monitor accounts. Profile accounts for normal activity and usage periods to spot anomalies. Account privileges should be limited to need to know. Segregate account access across network tiers. Change default passwords. Disable and delete unneeded accounts. Replay: Servers are hardened. Extraneous software is removed. Configuration files do not contain sensitive data and/or any configuration data is encrypted. Encryption keys and processing occurs in an HSM. Configurations are monitored for changes and changes are reviewed for flaws so any misconfigurations would be fixed immediately. Critical systems and accounts require multi-factor authentication. Accounts are given minimal access for specific purposes. All default passwords are changed and passwords are properly managed. Result: Attacker may obtain access to one machine or account but will be limited in what they can access or do after reaching that machine. Attack would have been limited in scope and not been able to interact with POS machines.
- <number> Once access was obtained to the necessary systems, malware was installed on point of sale systems. The number of POS machines that were compromised in a short amount of time indicates that the software was likely distributed via an automated update process. A Dell SecureWorks report explains how the malware was installed using SCCM. The malware was custom software, undetectable by virus scanners. Controls: Inventory of Authorized and Unauthorized Software: Whitelisted software on POS systems. Scanning for configuration changes with a HIDS. Malware Defenses: Monitoring via a HIDS may have helped uncover the fact that malware was installed. Replay: Software is inventoried and white listed, preventing new software from installing or running. Applications run under non-admin account. Strong passwords are changed regularly. A Host Intrusion Detection System alerts on system changes. Access to centralized build systems are limited and audited. Additional controls are placed on gold images for POS systems. A central management system ensures software images are signed, managed, secured and audited. Result: Installation of malware on POS machines is not be possible. Any changes to POS configurations would generate alerts to quickly respond to and resolve the problem.
- As for the encryption itself, additional layers of protection could have been added to protect card data in POS operating system memory. A tamper resistant security module (TRSM) encrypts data in hardware, not software. Some POS models use a TRSM to encrypt the data at point of swipe. The card data goes directly to the TRSM where it is encrypted. Even if malware got on the POS operating system, it would have been reading encrypted data. Controls: Application Software Security: Developers trained in security should develop systems processing sensitive data. Target software on POS machines was a custom product. Data Protection: P2PE (Point to Point Encryption) for POS systems from PCI compliant vendors may have helped protect card data in memory. Hardware encryption devices directly connected to the pin pad would have kept credit card data out of memory. POI pin pads with tamper resistant security module (TRSM) provide hardware encryption. Replay: Credit card data is encrypted end-to-end and never accessible in memory to malware. POS system uses approved P2PE vendors from PCI web site. Testing verifies data is not stored in memory or inappropriately. POI pin pads with tamper resistant security module (TRSM) use hardware encryption to encrypt credit card data so it never enters the memory on the machine and key is protected. A pin pad is used that encrypts the magnetic stripe data using the TRSM, not just the pin. Result: Credit card data would not have been available to the memory scraping malware. <number>
- <number> The software gathered credit card information from memory as cards were swiped. The data was saved to a .dll file and stored in a temporary NetBIOS share over ports 139, 443 or 80. Controls: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers: NetBIOS could be used because port 139 was open and the service was available. Lockdown ports and remove extraneous services. Secure Network Engineering: Prevent data movement across network by limiting open ports that allow traffic to and from critical systems. Maintenance, Monitoring, and Analysis of Logs: Monitoring tools pinpoint data exfiltration and trigger appropriate response. Replay: NetBIOS and file and printer sharing are unaccessible. No extraneous ports or services are available. Inventory of network devices and shares is maintained and monitored, especially on critical systems with sensitive data. Blocked NetBIOS traffic would have generated rejects in logs that could be used to pinpoint and block malicious activity. Result: Data could not be exfiltrated via NetBIOS shares or open ports.
- <number> Components used by attackers communicated via an ICMP tunnel. The ICMP traffic consisted of PING packets with custom text messages to initiate data movement from POS machines to compromised machine on the corporate LAN. Other customized components were used to send raw commands over the network that would not be discoverable by common network forensics tools in order to bypass network controls. Controls: Secure Network Engineering: Implement network segregation that limits access to critical systems to specific addresses and ports. URL filtering for egress limits outbound access. Maintenance, Monitoring, and Analysis of Audit Logs: Hiring more staff or better training staff to adequately monitor logs may have helped mitigate losses. Tune logging systems to limit false positives, making it easier to pinpoint real threats. Use tools that detect and prevent anomalous traffic. Replay: Additional logging and alerting exists for traffic coming in or out of POS systems. NetBIOS and open ports are not available to exfiltrate data. Use of ICMP and other protocols is limited to what is explicitly required. Better monitoring tools spot unusual ICMP traffic and trigger appropriate response. Result: Unusual packets and traffic patterns are discovered and blocked.
- <number> Data was moved to drop locations on compromised servers all over the world via FTP. The attackers retrieved the data from drop locations. Controls: Data Protection: Employ tools at perimeters to monitor for sensitive data leaving the company. Use Data Loss Prevention systems. Monitor traffic. Block known compromised hosts. Maintain, Monitor, Analyze Logs: Anomalous traffic patterns can indicating possible data exfiltration generate alerts and appropriate response. Replay: Implement strict access for data moving out of the company via FTP or known file transfer protocols. Create a proxy specifically for data movement such as FTP, SFTP and other protocols used to send data to remote locations. Carefully monitor traffic for unexpected activity. Monitor outbound traffic for unexpected changes and anomalies. Result: Data moving out of the organization would have been spotted. Breach would have been stopped sooner.
- <number> While the attack was in progress, monitoring software (FireEye) alerted staff in Bangalore, India. They in turn notified Target staff in Minneapolis but no action was taken to stop the data exfiltration. Controls: Security Skills Assessment and Training: Make sure security staff is adequate to monitor logs appropriately and well trained. Maintenance, Monitoring, and Analysis of Audit Logs: Hiring more staff or better training staff to adequately monitor logs may have helped mitigate losses. Incident Response and Management: Better policies and procedures for incident management may have prevented this breach or minimized the losses. Penetration Tests and Red Team Exercises: Pen testing exercises to mimic attacks and generate alerts could indicate whether or not staff responds to alerts appropriately and aid in training. Replay: Adequate staff are available to look at alerts in detail and respond accordingly. Processes are appropriate and staff is well trained to handle alerts in such a way that the breach would have been uncovered and quickly stopped. Better network monitoring systems help uncover the breach sooner. Penetration tests and Red Team testing ensure security teams are prepared to respond. Result: The alerts would have been analyzed differently and the data breach and the response would have mitigated losses by stopping the breach sooner.
- <number> Credit cards were sold on the black market after stolen from Target. Stolen card data was used to create fake cards and facilitate fraudulent transactions Controls: Data Protection: EMV (Europay, MasterCard and VISA), otherwise known as chip and pin, will help prevent some use of stolen cards because it requires a pin at the time the card is used. This technology protects the customer after the data has been stolen because it prevents using a cloned card in some cases. It would not have completely prevented loss because some devices support or failover to the magnetic stripe method when chip and pin is not available. Replay: Use of the cards would have been prevented when sold on the black market if the fake card was originally a chip and pin card, and then used on a card reader that supported chip and pin technology. Result: Some fraudulent transactions using stolen cards could have been prevented. Note: Protection is thwarted on manual entry and on failover to MSR when the card reader doesn’t support the chip and pin technology and the card still has a magnetic stripe. When EMV is not present, transaction will failover to magnetic stripe, so protection of data at source is better than after the fact. EMV does not prevent stealing data from a POS system.
- <number> Target passed PCI compliance audits prior to this breach, indicating they had implemented security required by the credit card processing industry. Fazio Mechanical issued a statement claiming they were compliant with industry standard information security regulations. PCI compliance alone is not a risk management strategy. Only assets related to payment card processes are considered. Many businesses approach PCI compliance by trying to minimize what is in scope for the PCI audit. Assets and implementation details that may pose the greatest risks to the organization may fall outside of this scope and therefore not be adequately addressed if PCI alone drives a business security decisions. For example, at the time of the breach, the current PCI standard says consideration should be made for data stored in memory but no specific requirements are defined. Rather than relying on a mandated checklist, organizations will be better able to mitigate losses by performing organization-wide risk management activities on a regular basis. Vulnerabilities are system weaknesses that can be exploited. Threats are events that have negative consequences. Threats and vulnerabilities for all systems, not just those within scope for compliance audits, are identified. Threats and vulnerabilities are then prioritized and fixed to limit risk to an acceptable level. Constant re-evaluation is required as the threat landscape is always changing. After threats and vulnerabilities are identified for all systems, the risk posed by each is carefully analyzed. Generally, the vulnerabilities with the highest likelihood of occurring and most severe consequence in terms of cost to the organization should be prioritized highest and fixed first. This has nothing to do with compliance and everything to do with what poses the greatest risk to the organization. Then application of the Critical Controls where risk is greatest may help thwart attacks such as those used in the Target breach.