Thales Blog

What 'Should' Come From The Cybersecurity Sprint

July 21, 2015

Which way will the cybersecurity sprint goSo, in the wake of the OMB hack, the federal CIO (Tony Scott) has directed government agencies to get serious about cyber security. The “30-day sprint,” directs agencies to patch all known vulnerabilities; use information provided by Homeland Security to identify and mitigate known threats; limit the number of privileged users and tighten access controls; and "dramatically accelerate" the use of personal identity verification (PIV) cards and other forms of multifactor identification.

Yes, in 30 days.

ClickToTweet: Will the Cybersecurity sprint be a turning point? Or yet another failed initiative?

This directive reminds me of how back in January 2002 after numerous malware and worm incidents, Bill Gates declared that February 2002 (the shortest month on the calendar) would be the month that Microsoft becomes focused on cyber security. Software production was placed on-hold and over 7,000 programmers were trained in writing secure code. All products were reviewed for vulnerabilities (I’m not sure how) and the first steps of the Security Development Lifecycle (SDL) were implemented.

Yes, in 28 days.

We will never know the degree to which Microsoft’s 2002 cyber security revelation actually reduced exposures in future products, but most do believe that it did set a corporate direction that elevated the importance of cyber security within the company. Perhaps the most influential legacy was the introduction of the SDL that encouraged product teams to perform formal security risk modeling and apply code security testing.

So, this brings us back to the question of what impact will Tony Scott’s directive have on the future of U.S. Government cyber security. Will it be remembered as a watershed moment on the path to securing government computer resources and citizen sensitive data or will nobody even remember Mr. Scott and his 17 June pronouncement. While we all know that few of the security remedies will be completed (or even started) within 30 days, OMB and Congress (via the Federal Information Security Management Act) should leverage the OPM debacle and use the crises like Microsoft did in 2002. Specifically, the next step should be to demand government agencies establish a one-year cyber security plan that includes the following six enhancements:

  1. Implement a true Demilitarized Zone (DMZ) between the enterprise network and the Internet. As the diagram below describes, government agencies should isolate their enterprise network by terminating all incoming Internet sessions within the DMZ. The only way the enterprise network should access the DMZ is via a VDI thin client that does not allow for data to be stored in the enterprise network. While internal users can bring data into the enterprise network (via the one-way optical isolation system), it is almost impossible for hackers to “exfiltrate” data from the enterprise network.Secure Network Diagram
  2. Implement enhanced hardening of all operating clients and servers. Beyond applying industry best standards or the NSA/NIST “best practices,” all U.S. Government networked computers (including virtualized SaaS platforms) should be hardened with TPM boot protection (to establish a chain of trust through the boot-loader). Furthermore, all operating systems should be secured via microvirtualization security (where possible), white-listing technology and state-of-the-art anti-virus protection that leverages artificial intelligence and machine learning instead of virus definition databases and signatures.
  3. Implement a network segmentation strategy. This initiative includes identifying the agency's most sensitive data (e.g., SF-86 completed forms) and storing them on hosts that are not directly accessible from the Internet. Agencies should be required to use both layer 2 and 3 network isolation techniques (e.g., VLANs and firewalls) to build isolated subnets. The subnets should have a completely separate network management plane and not be “routable” even within the internal agency network. Access to the network should only be enabled via a VDI server that requires two-factor authentication and technical policies should be implemented that require all data to be stored on the sensitive domain servers.
  4. Encrypt all data within the sensitive data subnet. In addition to keeping data in an isolated subnet, the sensitive data should be DOUBLE encrypted. First, all storage volumes attached to the subnet systems should be encrypted at the media layer and access to decrypt the data should be managed by a separate appliance under the administrative control of administrators who do not also manage the subnet domains and applications. Second, all data stored in the subnet should be protected via a digital rights management system that includes encrypting the data and enforcing data flow/use policies (e.g., no cut/paste). Digital rights policies ensure that the sensitive data remains protected when it is used outside of the sensitive data subnet and provides a comprehensive record of all accesses and use.
  5. Enable a X.509 compliant Public Key Initiative (PKI) and require all user certificates to be stored on protected Personal Identity Verification (PIV) smart cards. PKI has become the accepted (and highly secure) method for user identification and authentication. However, keeping PKI certificates online in vulnerable certificate stores is a bad idea. Government agencies should take the next logical step and require all PKI certificates to be kept on encrypted hardware tokens, specifically PIV cards. This measure dramatically increases the protection of the employee's identity as hacking smart cards, while not impossible, is extremely difficult.
  6. Monitor critical security related files for unauthorized modification. Even the most sophisticated hackers will at some point need to modify/replace critical files (e.g., dlls) to install/activate their payloads. File integrity change checkers provide early insight into possible malware infections and the government should mandate that certain critical security related Windows and Linux O/S files and policy settings must be monitored. Furthermore, the government should require all agencies to participate in a continuous monitoring program that includes sending critical O/S file modification alerts to the Department of Homeland Security (DHS) where they can analyze this information across the government and obtain early insight into the scope and depth of attacks.

While implementing all six of the above recommendations does not guarantee any additional OPM-size hacks, it does dramatically reduce its likelihood. However, the window for responding thoughtfully to the OPM hack does not last forever. White house and congressional attention to these matters tend to last only as long as the media makes the issue topical. While the “30-day sprint” was clearly intended to shake up government agencies and require them to recognize the importance of protecting sensitive information, Mr. Scott would now be wise to use this incident, as did Microsoft in 2002, to make permanent changes (described above) in how our government agencies protect systems and data.

Robert Bigman