Predicting is easy. When it’s made, one prediction is as good as another. Only in hindsight can you pick the winners from the losers. Let’s look back at my 2013 predictions for cybersecurity and see how good they were.
I hedged my bets pretty well last year. The predictions for the most part covered areas that were so basic that they would be important security concerns regardless of what happened. But did they deserve to be singled out for 2013?
It turns out that reliability, not security, was the big issue in clouds.
An inspector general’s report found that NASA, a pioneer in cloud computing, suffered from a lack of proper security. “We found that weaknesses in NASA’s IT governance and risk management practices have impeded the agency from fully realizing the benefits of cloud computing and potentially put NASA systems and data stored in the cloud at risk.” But the report did not cite any serious breaches, and according to data from the Privacy Rights Clearinghouse most data losses still are occurring the old-fashioned way: Through lost, stolen or discarded devices and documents and from in-house breaches. Not from cloud breaches.
What caused problems in the cloud were a string of outages plaguing Amazon Web Services, Dropbox, Microsoft Office 365, Windows Azure cloud storage and CloudFlare. Data wasn’t lost, but it was unavailable. For the end user, an outage is as good as a denial-of-service attack.
Collateral damage and unintended consequences of cyberwar and espionage
This one was spot-on, especially for the NSA, which suffered from multiple self-inflicted foot wounds in 2013.
From June on, the nation’s eavesdropper in chief, Gen. Keith Alexander, found himself defending once-secret electronic surveillance programs in the wake of a never-ending stream of revelations stemming from Edward Snowden’s leaks of classified documents. Repeated lies, half-truths and evasions were exposed with each new release about wholesale collection of digital communications data at home and abroad, the tapping of international fiber-optic cables, cryptographic back doors and abuse of data.
NSA staffers, portrayed by Alexander as heroes, became the bad guys in many eyes. In December, the first of what will likely be multiple court decisions about the programs found wholesale collection of cellphone metadata likely to be unconstitutional.
Supply -chain security
This issue failed to rise to the level of a crisis in 2013.
Although lengthy and far-flung supply chains have possible weak links all over the world, China has been the primary concern for the U.S. government. There are appropriations laws in place prohibiting some agencies from dealing with Chinese contractors, and there have been anecdotal reports of NASA contractors with suspect Chinese ties.
In November, the Defense Department amended its acquisition rules allowing the DOD “to consider the impact of supply chain risk in specified types of procurements related to national security systems.”
But 2013 did not produce any serious cybersecurity incidents resulting from weaknesses or backdoors in IT products that were inserted in the supply chain (if you don’t count reports of NSA dabbling in commercial crypto systems). Of course, the beauty of supply-chain tampering is that if it is done right, no one will see it. We might not know for years if we’ve already been had.
With the popular Windows XP approaching end-of-life in April 2014, the security of Windows 8 is a concern. But there has not been much bad news here. The latest Windows OS generally is seen as the most secure version to date.
Windows 8 includes its own antivirus features with Windows Defender, which starts early in the boot-up process to help protect against rootkits. Downloaded files are scanned for executables and applications are sandboxed. Version 8.1 includes data classification for remote wiping, improved fingerprint biometrics and better encryption. Overall, this one was a miss.
Posted by William Jackson on Dec 20, 2013 at 8:27 AM0 comments
Cloud computing is useful because it offers a new approach to IT, leveraging shared resources to maximize productivity and cut overhead. But with new approaches come new threats. How can agencies minimize risk in this environment?
The Cloud Security Alliance and the Software Assurance Forum for Excellence in Code (SAFECode) have collaborated to identify a set of best practices for developing applications that meet the unique security requirements of cloud computing. The resulting paper, Practices for Secure Development of Cloud Applications, applies established methods of producing secure code to the architectural requirements of the cloud.
“For cloud computing to reach its true potential, all parties involved – both consumers and providers – will need new ways of thinking about security needs and related standards,” the paper says.
Eric Baize, senior director of the product security office at EMC Corp. who participated in the study for SAFECode, says the new guidelines are an addendum to the existing security practices identified in SAFECode’s Fundamental Practices for Secure Software Development.
About 70 percent of cloud development work is common with other application environments, Baize said. The difference in the remaining 30 percent lies primarily in the fact that the cloud is a multitenant environment in which trust boundaries are required because software running in one entity can be used by another.
The CSA and SAFECode working group spent about six months reviewing existing development practices to identify gaps that should be filled for the cloud environment. Representatives from member companies shared their experiences and lessons learned to identify a consistent set of practices that address issues in the cloud. The working group focused on the platform-as-a-service model and identified a basic set of threat areas that needed to be addressed differently in the cloud:
- Data breaches: Compromises in the virtual infrastructure can pose threats to co-tenants in the cloud, and techniques such as SQL injection threaten more serious consequences with multiple applications sharing an underlying database system. A flaw in one application could expose all.
- Data leakage and data loss: When data is kept in the cloud, the system needs to be designed, implemented and deployed so that it can withstand attacks on various levels in the multitier architecture. Changes to data should be detectable and traceable, and the data should be able to be restored. If encryption is used to protect data, at what layer is it performed and how are keys managed?
- Insecure interfaces and APIs: Improperly designed application programming interfaces can create vulnerabilities when used by third parties.
- Denial of service: This can occur at several layers, expanding the attack surface in a cloud environment.
The paper describes the security practices in the context of the unique requirements of the cloud. Recommendations are mapped to specific threats to provide detailed illustrations of the security issues they resolve, with specific action items for development and security teams.
Like many best practices, those identified for secure development of cloud applications are often common sense. “For us, it’s not a surprise,” Baize said of the recommendations. “I don’t expect this to be a surprise to anybody.”
Posted by William Jackson on Dec 13, 2013 at 8:14 AM0 comments
The Homeland Security Department is the lead agency in the government’s effort to protect the nation’s privately owned critical infrastructure, but the department still is struggling to define its relationship with entities over which it has little or no authority. This is not all DHS’ fault; Congress and the National Security Agency have hampered DHS efforts and sown distrust of government in industry.
Essential to the job of protecting the privately owned networks and utilities vital to the nation’s security is information sharing. This always has been a touchy subject. Government is unwilling to share what it sees as sensitive information with the private sector without security clearances, and industry is leery of exposing confidential information to government. Reports that the NSA has been helping itself to information from private networks haven’t helped the situation. On top of that, inadequate funding and day-to-day budgeting make it difficult for DHS to develop and execute a coherent program.
Technical guidance for baseline cybersecurity in critical infrastructure networks is being developed by the National Institute of Standards and Technology, but NIST is not a regulatory agency and cannot create the necessary relationship between government and industry.
Congress, in its 2012 DHS appropriation, ordered the department’s National Protection and Programs Directorate to provide a report on efforts to streamline information sharing. But this was not addressed in the department’s annual report to Congress.
“The department has reorganized divisions, altered programmatic activities, and reviewed current and past NPPD Office of Infrastructure Protection outreach efforts to federal, state, and local governments and private-sector partners ... ,” DHS wrote by way of explanation in its reply to a Government Accountability Office assessment of the report.
DHS is in the middle of developing a new National Infrastructure Protection Plan (NIPP) under Presidential Policy Directive 21 on Critical Infrastructure Security and Resilience. This will replace the original NIPP created in 2006 and supply a framework for streamlining the sharing of information between government and industry.
“Additional progress will be made during calendar year 2014,” with the creation of a formal communications program, DHS said.
Let’s hope so. To date there has been too little coordinated effort between industry and DHS. Under the current structure, DHS can only offer its help to privately owned systems. While this help has sometimes been accepted, too often it has been after the fact, when an organization is responding to or recovering from a breach. The president can go only so far in correcting this situation. Executive Office policy can set out goals, but it cannot replace legislation.
There is nothing wrong with voluntary cooperation, as far as it goes. But if the networks supporting the nation’s power systems and other critical infrastructure are to be protected there needs to be a clear legal framework laying out the authorities, responsibilities and liabilities of both government and industry to enable − and require − cooperation and information sharing. This is something Congress has failed to provide.
Posted by William Jackson on Dec 06, 2013 at 12:05 PM0 comments
Another year is drawing to a close, and Congress — locked in partisan gridlock and unable to fulfill its most basic responsibilities — again has failed to update any of the nation’s cybersecurity laws.
The need for cybersecurity reform is cited repeatedly by lawmakers, IT professionals and privacy advocates, but nothing is done. According to a recent report from the Congressional Research Service, “More than 50 statutes address various aspects of cybersecurity either directly or indirectly, but there is no overarching framework legislation in place. While revisions to most of those laws have been proposed over the past few years, no major cybersecurity legislation has been enacted since 2002.”
Fortunately, you don’t have to depend on Congress to secure your systems. The National Institute of Standards and Technology, which can’t tell you what to do, can tell you how to do it. Under the Federal Information Security Management Act, NIST continues to update and expand security guidance for government and for private sector IT systems that choose to use it.
So far this year, NIST has published 10 new or updated special reports in its 800 series of computer security documents, released drafts of nine special pubs, and issued five Interagency Reports on cybersecurity.
These publications contain specs, guidelines and requirements for securing government systems and offer flexible and frequently updated information on technology-agnostic standards and best practices. Each agency must decide for itself what security features and controls to implement and how to do it, but NIST makes the information needed to do this available.
Highlights of this year’s work include:
The fourth revision of SP 800-53, the foundational catalog of security and privacy controls for federal IT systems. First published in 2005 and last updated in 2009, the latest revision is the most comprehensive to date and focuses on designing and acquiring trustworthy systems that have security built in.
The revised SP 800-124 guidelines for management of mobile device security. These sharpen the focus of the original 2008 publication, excluding laptops and low-end cell phones, to zero-in on high-end phones and tablets. It also explains security concerns inherent in mobile devices, with recommendations for centralized management technologies to address these risks.
A draft of the new guidelines for supply chain risk management in SP 800-61. With increasing government reliance on off-the-shelf hardware and software produced through a global supply chain, agencies need better understanding of possible risks. The publication gives guidance for identifying, assessing and mitigating these threats.
A new version of SP 800-40, with revised guidelines for enterprise patch management. Patching vulnerabilities is critical to maintaining security, but managing the process at the enterprise level is complex. This document describes the challenges as well as the technology available for meeting them.
Production of these documents does not ensure adequate security for government IT systems. But any agency with the will to assess and manage the risks in its systems can get the up-to-date information it needs to do its job. That’s not necessarily an easy job, but help is available.
Posted by William Jackson on Nov 22, 2013 at 11:50 AM1 comments