In its December newsletter, the Program Management Office for the Federal Risk and Authorization Management Program (FedRAMP) rolled out a new FedRAMP logo and announced the addition of four cloud systems to its list of authorized service providers, bringing the total of authorized solutions to 27 since the program was first announced in late 2011. These cloud systems break down into three categories according to the approach used to achieve FedRAMP authorization:
The availability of multiple paths to FedRAMP compliance seems to support the program’s commitment to encouraging as many service providers as possible to participate. Both the 3PAO and CSP-supplied paths can be undertaken without an existing federal agency contract in place, although the finalization of the FedRAMP authorization process under the third approach still requires the involvement of an agency customer. The CSP-supplied approach is significantly less expensive than using a 3PAO – independent assessments typically require six-figure investments by CSPs – but leaves the CSP without an actual authorization to operate. To date, only one of the 27 cloud systems on the FedRAMP list falls under the CSP-supplied category, while there are 15 systems with JAB provisional ATOs and 11 agency-authorized systems (some of which have been authorized by more than one agency).
On December 12, the National Institute of Standards and Technology (NIST) Computer Security Division announced the final release of Special Publication 800-53A Revision 4, Assessing Security and Privacy Controls in Federal Information Systems and Organizations. This new update brings security control assessment procedures into alignment with the current version of the government’s security control framework, the latest revision of which was published in April 2013.
The final version of this guidance should lead to a revision in security control assessment practices in all agencies and also remove a practical obstacle to the adoption of 800-53 Rev. 4, as many agencies delay their migration from one version to the next until corresponding assessment guidance is available. The more than 18-month gap between the release of 800-53 Rev. 4 and 800-53A Rev. 4 can be attributed in part to the substantial changes seen in the control framework compared to the previous version, notably including the addition of separate set of 26 privacy controls and an expansion in program management controls, all of which are mandatory for federal information systems and security management programs.
The fundamental structure of security control assessment procedures in 800-53A remains the same as in previous versions (NIST skipped from Rev. 1 straight to Rev. 4 in the latest release, to synchronize the revision numbers with 800-53). For each control, 800-53A provides a set of assessment objectives, with each objective broken down into one or more determination statements that tell an assessor what to look for when deciding whether a system or agency satisfies an objective. Assessment procedures specify different methods assessors should use (examine, interview, and test) against the objects of the assessment (specifications, mechanisms, activities, and individuals). The guidance in 800-53A also defines various levels of detail (and effort) with which each method can be applied to help assessors appropriately tailor assessments to the assurance requirements specific to each system.
What is noticeably different in 800-53A Rev. 4 is the level of granularity in the determination statements found in the catalog of assessment procedures in Appendix F of the document. While the prior version included assessment objectives and determination statements for every security control and enhancement, those statements often were long phrases that included many details in each statement. In contrast, the new version has many many more determination statements, but each statement is short and explicit, addressing a single concept, action, or detail related to an assessment objective. For example, for the “Account Management” control (AC-2), the previous version of 800-53A had three numbered determination statements, the first of which incorporated nine attributes. The new assessment procedure for AC-2 has eleven primary determination statements, all but four of which are broken down further into subordinate statements (and in the case of one statement into a third level of detail). This results in a total of 30 numbered items each subject to a satisfied/other-than-satisfied finding.
Guidance for producing assessment reports carries forward the increased level of detail, as an assessor’s determination of “satisfied” or “other than satisfied” is applied to every determination statement in the assessment procedures. This change could make security assessment reports more closely resemble audit reports and compliance checklists commonly found in traditional financial and IT auditing contexts, but it also greatly increases the set of items for which individual findings would be recorded. Federal security control assessment procedures and the broader Risk Management Framework of which assessments are a part requires agencies to apply risk-based decision making and, where appropriate, corrective action to all “other than satisfied” findings. Organizations following the assessment reporting guidance in 800-53A Rev. 4 may initially find that they have a much higher number of findings to address, but the finer granularity of the determination statements and assessment procedures should greatly reduce the scope and, potentially, level of effort required to address each finding.
One other notable addition to 800-53A Rev. 4 is the introduction (in official guidance) of the concept of security and privacy capabilities, which are essentially functional descriptions that correspond to multiple underlying security controls. It seems the intent of recommending the use of capabilities to agencies is to increase the alignment between implemented security controls and the security or privacy requirements they are designed to meet or support. Based on the description in 800-53A Rev. 4, the concept of capabilities also reflects an acknowledgement that weaknesses in or absence of any single security control may not significantly impact the ability of an agency to delivery the capabilities it needs.
After several Congressional sessions that saw proposed information security legislation fail to pass, within the span of 10 days in December both houses of Congress passed, and the president signed into law, the Federal Information Security Modernization Act of 2014. This act, which provides the first comprehensive update to federal security regulations since 2002, is touted by legislators and the media as a significant and long-overdue effort to bring federal cybersecurity practice into the 21st century, but upon initial inspection appears to be more of an incremental improvement rather than a sweeping change. The key provisions in the law – which handily condenses to the same FISMA acronym as its predecessor, the Federal Information Security Management Act of 2002 – serve to codify changes in federal policy and security management guidance to agencies that had previously been made through official memoranda issued by the Office of Management and Budget (OMB).
These changes to FISMA 2002 written into FISMA 2014 include:
The new FISMA legislation remains limited in its applicability to federal executive branch agencies, although Congress also passed separate bills to codify the cybersecurity framework developed by the National Institute of Standards and Technology (NIST) as directed under a February 2013 Executive Order on critical infrastructure cybersecurity and to formalize the DHS National Cybersecurity and Communications Integration Center (NCCIC) as the government nexus for public and private sector information sharing about cybersecurity threats and incidents. The bulk of the FISMA 2014 legislation mirrors the text of the 2002 law and of the Government Information Security Reform Act of 2000, at least in terms of the primary obligations it imposes on federal executive agencies and their information security management programs.
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.
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.