It’s hardly treason, but Trump’s call for Russian hacking still encourages illegal actions

Despite speaking for more than an hour at a rally in Florida on July 27, media attention following the speech centered on just two sentences uttered by Republican presidential nominee Donald Trump. Leveraging widespread speculation that Russian hackers were responsible for the recently publicized attack of Democratic National Committee computer systems, Trump made an appeal directly to that nation: “Russia, if you’re listening, I hope you’re able to find the 30,000 emails that are missing,” an apparent reference to the email messages that Hillary Clinton determined to be personal and deleted from her private server before handing the server over to the State Department and the FBI. Trump continued, “I think you will probably be rewarded mightily by our press.” Reaction to Trump statements was swift and predominantly critical, from both Democrats and Republicans, with a general consensus that Trump was actively encouraging espionage by a foreign power against American information technology assets. Michael Inboden, a member of the National Security Council under former president George W. Bush, called Trump’s comments “tantamount to treason,” although most politicians and analysts chose not to go that far, instead emphasizing how inappropriate it would be for a foreign government to try to intervene in or influence a U.S. presidential election.

A brief examination of relevant laws codified in the United States Code suggests that Trump, assuming for the sake of argument that his statements were serious and not a joke, is at the very least encouraging action that violates U.S. law, because computer hacking generally (whether perpetrated by domestic or foreign actors) is illegal under 18 USC §1030, which says in relevant part that anyone who “intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains … information from any department or agency of the United States or information from any protected computer” may be subject to a fine or imprisonment of up to 10 years. It’s somewhat unfortunate that so many incensed observers chose to use the word espionage to characterize what Trump purportedly asked Russia to do, since under U.S. law (18 USC Chapter 37) that term only applies to defense information or to classified information, and at least according to Clinton, the deleted emails were personal in nature and did not contain any classified information (or, presumably, any information about matters of national defense). Michael Inboden also seems to have been overzealous in painting Trump’s words as treasonous, because acts of treason involve levying war against the United States (18 USC §2381), and it would be hard to characterize hacking emails as waging war. Still, it seems irresponsible to imply that any type of computer hacking or intrusion by Russia would be welcome, especially given the long history of alleged cyberattacks carried out by Russian nationals, whether or not they were working on behalf of the Russian government.

FedRAMP not delivering on promise of standard authorization

Nearly five years after the federal government launched the Federal Risk and Authorization Management Program (FedRAMP) and more than three years after the first FedRAMP authorization, many federal sector observers are questioning the effectiveness and even the relevance of the program. Although the number of FedRAMP-authorized service providers continues to grow – including as of June 21 the first set of providers authorized at a high FIPS 199 security categorization level – the more rapid adoption of cloud computing services FedRAMP was intended to facilitate has been hampered by many federal agencies’ unwillingness to accept FedRAMP authorization as sufficient for granting their own authorization to operate (ATO) or to accept ATOs granted by other agencies. This lack of reciprocity was highlighted by former Navy CIO and Department of Defense Deputy CIO Dave Wennergren in a commentary written for Federal Computer Week, in which he suggests that the Office of Management and Budget (OMB) needs to require agencies to accept ATOs previously granted by other agencies or by the FedRAMP Joint Authorization Board (JAB) to avoid the delays and unnecessary spending associated with the current prevalent practice of each agency repeating the authorization process even when selecting the same cloud service provider. As an example, the Department of Defense in January issued Defense Acquisition Services instructions to all DoD components that requires cloud service providers to obtain both a DoD provisional authorization from the Defense Information Systems Agency (DISA) and an ATO from the component’s authorizing official. This means that even DoD programs that choose to use one of the services DISA has already authorized under FedRAMP (such as Amazon Web Services Government Community Cloud, Microsoft’s Office365 Multi-Tenant & Supporting Services, or Verizon’s Enterprise Cloud Federal Edition) still need to complete an agency-specific ATO, and they cannot choose FedRAMP-authorized providers whose authorization came from another agency or JAB. This behavior is common among civilian agencies as well, who appear no more likely than the DoD to accept the judgment of the JAB or of agencies with ostensibly stricter security requirements than their own.

FDIC data breaches indicate systemic failures in security management and monitoring

Initial reports last month of a data breach at the Federal Deposit Insurance Corporation (FDIC), the quasi-federal government agency that oversees the soundness of the nation’s banks and insures millions of Americans’ deposits held by those banks, triggered an embarrassing and troubling series of disclosures about what seems to be a pattern of data exfiltration by FDIC employees who are leaving the agency. The February 2016 incident, which apparently included personal data on 44,000 individuals, was attributed by an FDIC executive to an inadvertent action by an employee who copied the data to a personal storage device on the employee’s last day with the agency. It turns out that the February incident was far from an isolated event; after being asked by the Chairman of the House Science, Space and Technology Committee to provide information about all major breaches at FDIC, the agency disclosed a similar incident that occurred in October 2015 and five other incidents since October, all of which involved outgoing employees copying FDIC data on customers to personal devices. Following a Congressional Subcommittee hearing on May 12, during which FDIC executives tried to explain why they had not previously notified Congress of seven breaches over a five-month period that potentially affected 160,000 individuals, members of Congress were so unimpressed with the agency’s response that they suggested FDIC may have lied to or misled the Committee at the hearing and requested revised testimony about the breaches and FDIC’s response to the incidents. Committee members seemed especially skeptical of FDIC’s claims that the employees who took the data acted inadvertently and without malicious intent, particularly in the case of an employee with a background in IT management who copied large amounts of customer records to a portable hard drive before leaving government employment to work in the private sector.

Media reports (and even some of the statements by members of Congress at hearings convened for the purpose of making FDIC executives explain the agency’s actions) focused to a large extent on the FDIC’s decision not to promptly (within seven days) report the incidents to Congress, as required under the Federal Information Security Modernization Act of 2014 (FISMA) and as directed by the Office of Management and Budget (OMB) in its Memorandum M-16-03, issued in October 2015 right around the time that one of the breaches occurred. It’s worth noting that under long-standing federal regulations and OMB guidance FDIC was already obligated to immediately (within one hour of discovery) report the PII breach to the Department of Homeland Security. It should also be pointed out that, despite the relative newness of the OMB guidance, the requirement to report major incidents to Congress within seven days is in the text of the FISMA law (codified at 44 USC §3554) so there is no reason to think that security officials didn’t know that the requirement existed. In testimony to Congress on May 12, FDIC CIO Lawrence Gross noted that FDIC does report all incidents (presumably including the ones that were not reported to Congress) to US-CERT, but Congressional committee members were upset that they were not notified. What should be even more troubling than the poor incident response (including reporting) is the apparently complete inability of the agency to prevent large-scale data exfiltration. The public description of several of the breach events by FDIC officials illustrates very well the difference between detection and prevention. Even though multiple FDIC statements and memos refer to DLP technology (typically taken to mean “data loss prevention” in the industry, although it could be construed to mean protection). Indeed, the FDIC cites its DLP as the mechanism that alerted it to the actions of its employees (copying PII to thumb drives or other removable media). Unfortunately, alerting seems to be all the DLP system did, as the employees were not prevented from copying data to removable media and, in the case of the February breach that received so much attention, FDIC was alerted to the act of copying sensitive data three days after it occurred; in an October incident, the lag was eight days.

The excuse posed by FDIC for not reporting the PII breaches to Congress hinges on the definition of “major,” which, to be fair, was not included in FISMA and was not formally published by OMB until M-16-03. In that Memorandum, OMB laid out a framework rather than an explicit definition, maintaining a level of subjectivity that should have been expected to result in differences of opinion about whether a specific incident is or is not a major incident. The framework includes four factors: information classification; recoverability; mission impact; and exfiltration, modification, deletion, unauthorized access, or lack of availability of 10,000 or more records or affected individuals. OMB’s framework strongly implies that the first three factors must all be present in combination, but not the fourth factor. Each of the breaches experienced by the FDIC involved personally identifiable information (considered a type of controlled unclassified information) of more than 10,000 individuals that was recoverable in a time period greater than eight hours. The only factor not in evidence was impact to a critical service at FDIC. It’s somewhat difficult to understand how anyone at FDIC could arrive at the conclusion that the incidents were not major – the FDIC’s Office of Inspector General reached the opposite (and correct) conclusion. Stranger still is the justification Gross gave for not categorizing these incidents as major:  decisions that the data exfiltration events were inadvertent, non-adversarial, and did not lead to subsequent dissemination to unauthorized parties. These are certainly mitigating factors in determining the risk of harm to individuals affected by the breaches (who were not notified), but they are irrelevant for the purposes of federal incident reporting requirements.

Epic Mossack Fonseca breach tied to basic patch management failures

Coverage of the widely reported disclosure of thousands of documents from law firm Mossack Fonseca has emphasized details the use of legal and financial structures that can and apparently have been used by many high-profile individuals to conceal assets or avoid taxes and the public identification of some of the firm’s more famous or noteworthy clients. Initial media reports characterized the disclosure as a “leak,” at least in part because the firm’s activities came to light when an anonymous individual approached a reporter at German newspaper Suddeutsche Zeitung and offered to provide a large volume of documentation (so large that the work of examining it required the involvement of hundreds of journalists coordinated through the International Consortium of Investigative Journalists). Although the identity of the source who provided this trove of documents has still not been made public, subsequent technical analysis of the situation and of Mossack Fonseca’s website and client portal strongly suggest the data was exfiltrated by an external hack, not by an insider acting as a whistleblower. More astonishing, at least from an information security perspective, is that the hack apparently exploited well-known vulnerabilities in open-source software tools that Mossack Fonseca used. If the results published by security investigators are accurate, then the Mossack Fonseca breach might have been avoided had the firm simply performed routine patching and updates on its website and portal technology.

Mossack Fonseca uses the popular WordPress platform for its website and the open-source Drupal content management system (CMS) for its client portal. Unpatched security vulnerabilities in both toolsets appear to have contributed to the hack, as an out-of-date WordPress plugin may have enabled the compromise of the Mossack Fonseca website and its email system, while exploits of an unpatched Drupal server appear to have left the MF client portal vulnerable to a flaw with a known exploit so critical that Drupal users were warned back in October 2014 to assume that any unpatched servers had been compromised. According to multiple security researchers, including some cited in reporting on the Drupal problem by Forbes, based on server information stored on (and publicly accessible from) the MF portal the site continues to run a version of Drupal rife with exploitable vulnerabilities.

The irony in all this is that law firms globally take client privacy very seriously, holding fast to attorney-client privilege protections in many countries and generally working to keep private transactions and business dealings, well, private. In the face of all the unfavorable press, Mossack Fonseca was quick to claim that many critics fail to understand the nature of its activities on behalf of clients, and even the journalists who worked long and hard to identify MF clients and their offshore holdings have not established that anything Mossack Fonseca did for those clients is actually illegal. More investigations on that front seem to be ongoing, as numerous media outlets reported just today that Mossack Fonseca’s Panama offices had been raided by local authorities, presumably seeking evidence of illegal activities. Cynical observers (and security analysts) might counter that Mossack Fonseca failed to understand even basic information security and privacy principles and lacked the IT management skills or oversight necessary to ensure that they were adequately protecting their own and their clients’ information.

MedStar attack apparently enabled by unpatched software

When news broke at the end of March that MedStar Health, a large hospital operator in the metropolitan Washington, DC area, had shut down its computer systems in response to a malware attack, initial speculation on the cause of the infection reflected a general assumption that one or more of the company’s 30,000 employees must have fallen victim to a phishing scam. Numerous reports by the Washington Post and other major media outlets cited information provided by unnamed hospital employees as evidence that the MedStar network had been hit with a ransomware attack, in which data files are encrypted by attackers who offer to provide a decryption key in return for payment. Neither MedStar nor law enforcement agencies investigating the attack have confirmed that ransomware was involved; instead, official MedStar statements emphasized the work being done to bring systems back on line and fully restore normal operations.

Hospitals and other health care organizations are often assumed to have relatively weak security awareness and training programs for their employees, raising the likelihood that a clinical or administrative staff member might fail to recognize a suspicious link or email attachment and unwittingly introduce malicious software. The HIPAA Security Rule requires security and awareness training for all personnel working for covered entities (and, thanks to provisions in the HITECH Act extending security and privacy rule requirements, to business associates too) but HIPAA regulations do not specify the content of that training so it is up to each organization to make sure their training covers relevant threats. The HIPAA security rule includes “procedures for guarding against, detecting, and reporting malicious software” within its standard for security awareness but here too offers no practical guidance on how organizations should protect themselves against malware.

About a week after the attack occurred, Associated Press reports published by the NBC affiliate serving Washington, DC attributed the MedStar attack to the successful exploitation of an unpatched vulnerability in a widely used application server technology. The vulnerability in JBoss software components incorporated in multiple products from Red Hat and other large vendors was disclosed in 2010 and has been fixed in versions of software products released since that time. Despite the widespread availability of patched versions of the software, systems in many organizations remain vulnerable. This exploit is targeted by a specific ransomware attack (known as Samas or samsam) that has been around for more than two years and, as recently as last week, has been seen with increasing frequency by security researchers. Unlike many other types of ransomware that rely on phishing to compromise systems and spread, attackers who find vulnerable JBoss servers can deploy Samas without any action on the part of users in the targeted organization. The implication of the Associated Press report is that the MedStar attack was in fact ransomware, although by all indications the organization chose to recover its systems and data from backups rather than pay to remove the encryption presumably put in place by the attack.