SecurityArchitecture.com
Home Depot breach shows vulnerability of external vendors
In September retailer Home Depot announced a large-scale breach of customer credit-card data, affecting as many as 56 million consumers. The attack bears strong similarities to the theft of customer data Target suffered late last year, particularly because the Home Depot breach also involved compromised point-of-sale systems. Home Depot subsequently reported that the data stolen in the attack includes tens of millions of customer email addresses, making it seem very likely that shoppers who made purchases at Home Depot during the five-month period when the attack was underway may be targets in phishing scams at some point in the future. The fact that the point-of-sale malware that attackers were able to install at Home Depot went undetected for such a long time provides some evidence to support media reports and comments attributed to former Home Depot employees that the company didn’t take information security very seriously (a statement that does not seem to apply to Target, despite the mistakes it made).
The Home Depot breach also resembles the Target incident in that the first avenue of attack was network credentials that had been provided to a third party – a HVAC contractor in Target’s case and an unspecified member of Home Depot’s vendor community. In both cases the attackers seem to have found less rigorous security (or perhaps security awareness) among external parties that had nonetheless been granted access to the companies’ networks. Given the large number of partners and external vendors with whom these retailers work, it seems highly unlikely that Home Depot or Target imposes any type of rigorous security standards on third-party organizations. This is one area in which companies in sectors such as financial services or health care have more robust requirements, as external partners and business associates in these industries typically are bound by formal contractual agreements that at least require them to provide adequate safeguards for sensitive or confidential information. Similarly, federal government agencies often require third-party service providers to either attest or actual demonstrate that they have appropriate security measures in place as a condition of doing business with the government. While it may not be reasonable to expect external partners to adhere to the same level of protection as major retailers, if reported accounts are accurate that third-party credentials were obtained through phishing or other social engineering methods, then requiring such vendors to at least undergo basic security awareness training help reduce the likelihood of attackers exploiting these business relationships.
Operational security lessons from the Target breach
In the wake of revelations from major retailer Target that hackers compromised its point-of-sale systems and stole credit card information on tens of millions of its customers during a two-to-three week period in the busy holiday shopping season, initial media attention focused on the means by which the attackers were able to gain access to Target’s systems and possible security weaknesses in those systems. Subsequent disclosures by the company revealed that, contrary to early assumptions, Target’s corporate network environments were in fact monitored by sophisticated intrusion detection technology. More troubling is that its intrusion detection system produced alerts about potentially malicious activity shortly after the attack began, and that Target security personnel notified the company’s management about those alerts, but the alerts were dismissed as not significant enough to warrant an immediate response. While in hindsight this decision not to act has clearly been seen as a mistake, company representatives and some security analysts have essentially excused the error as an anticipated outcome when security operations teams face a daily barrage of alerts and notifications, many of which turn out to be benign “false positives” or are judged to have a low impact. Although it is possible that additional configuration or fine-tuning of the FireEye monitoring software that Target uses could have improved the quality of its security team’s analysis, when an organization has the information it needs to identify a security incident but fails to act, it suggests issues with operational or management controls that may be far more significant than any technical gaps.
It is difficult to assess the effectiveness of the security monitoring technology specifically implemented and operate by Target. FireEye offers industry-specific monitoring solutions for retail as well as several other sectors, and the company certainly markets its “adaptive defense” approach as a way to reduce false positives and thereby increase a company’s ability to respond to actual incidents. It is important to remember, however, that no intrusion detection systems can be fully effective without detailed analysis of the log and alert information that they produce. This analysis can be performed by automated or manual methods, often within the broader framework of an integrated security information and event monitoring (SIEM) tool. FireEye does perform some types of automated analysis, but it is a threat detection tool, not a SIEM tool, so it is misleading for anyone at Target to suggest that its security analysts can only rely on whatever information the FireEye tool produces for them. Even if Target saw dozens of daily alerts similar to the one it received for this attack, the fact that the issue related to its payment systems should have immediately escalated its significance to any retailer.
Equally unclear is how operational security is really managed at Target. In management and security circles alike, much has been made of the fact that prior to the breach Target had no chief information security officer, raising questions of accountability and highlighting the problems that can arise with decentralized decision making involving risk. Whatever shortcomings may exist in Target’s global security monitoring, the massive credit card data theft and the fact that it went on for nearly three weeks suggests substantial room for improvement in incident response procedures. At a more purely administrative level, Target is almost certainly revisiting the ways in which it provisions and monitors network access credentials provided to third parties, since in this case the first key point of attack for the hackers was through one of Target’s external vendors.
Microsoft Azure Cloud receives FedRAMP provisional authorization
On September 30, Microsoft received a provisional authorization to operate (ATO) for its Windows Azure Public Cloud from the Joint Authorization Board (JAB) of the Federal Risk and Authorization Management Program (FedRAMP). Windows Azure offers infrastructure-as-a-service (IaaS), platform-as-as-service (PaaS), and data storage and management services to commercial and public sector clients. In order to meet FedRAMP requirements, Microsoft has designated multiple U.S.-based data centers with corresponding network and hardware infrastructure and application services, supported by U.S. personnel and protected by security measures that adhere to federal security policies, standards, and other requirements.
For its FedRAMP authorization, Microsoft chose to follow a process under which its security was assessed by SecureInfo, one of several third-party assessment organizations (3PAO) authorized by the JAB to help cloud service providers meet FedRAMP requirements and to perform FedRAMP evaluations and make recommendations to the JAB on the extent to which each provider complies with FedRAMP. The provisional authorization (P-ATO) granted by the JAB to Microsoft is not tied to any specific use of Azure services or to any individual federal agencies. Agencies may choose to evaluate projects or solutions leveraging Windows Azure to make their own authorization decisions or opt to accept the P-ATO as sufficient evidence that appropriate security requirements are being met. Vendors or solution providers looking to serve federal customers may find it valuable to use Azure to satisfy policies in place at many agencies that external service providers comply with federal security standards.
Two Amazon Web Services environments attain FedRAMP compliance
Last week, Amazon announced that it had received separate agency authorizations to operate (ATO) from the U.S. Department of Health and Human Services (HHS) for two of its Amazon Web Services cloud computing offerings, and that those cloud services are now compliant with security requirements in the government’s Federal Risk and Authorization Management Program (FedRAMP). The authorizations to operate are for the AWS GovCloud environment – a government community cloud offering infrastructure-as-a-service (IaaS) specifically to U.S. government customers – and for the AWS US East/West environment, a public cloud available to commercial and public sector customers that also delivers IaaS using entirely U.S.-based data centers and infrastructure.
The FedRAMP designation, coupled with the ATO actions by HHS, gives other federal agencies the option to streamline their own authorization decisions for use of the AWS environments. Generally speaking, other agencies will still need to evaluate the security control documentation provided by Amazon and grant their own agency ATOs before using the AWS environments to host systems, but the fact that Amazon has already implemented security controls required under FedRAMP and undergone an agency ATO process should greatly reduce the level of effort required for other agencies (or even operating divisions within HHS) to issue their own authorizations.
NIST releases 800-53 revision 4
The National Institute of Standards and Technology (NIST) has released the final version of its Special Publication 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations. The 800-53 framework, which is required for all federal agencies under Federal Information Processing Standard (FIPS) 200 and more generally under the provisions of the Federal Information Security Management Act of 2002 (FISMA), specifies security controls to be implemented for federal information systems. This most recent update, the first major revision in nearly four years, includes many newly added controls and implementation standards intended to address access control, identity management, configuration management, data protection, and newer hosting models such as cloud computing. It also for the first time includes a set of controls and enhancements specifically focuses on privacy, and expands the set of program management controls first introduced with Revision 3 in 2009.
Federal agencies are not likely to move quickly to migrate their internal security practices from Revision 3 to Revision 4, in part because the corresponding NIST guidance on security control assessment (Special Publication 800-53A) has not yet been updated to match the revised control framework. It may be a year or more before the assessment guidance is updated, giving many agencies a justification for sticking with the prior version of 800-53. The adoption of Revision 4 is likely to be driven in part by a separate but parallel effort of the Joint Task Force Transformation Initiative Working Group (which includes representatives from civilian, defense, and intelligence agencies) to unify security control frameworks with 800-53 and system assessment and authorization procedures prescribed in Special Publication 800-37 Revision 1. Over the past 5 years, revisions to 800-53 have been strongly influenced by requirements and preferences coming from military and intelligence communities, so as these non-civilian agencies transition to government-wide processes and standards they will presumably use the latest version of 800-53 to guide their activities.