Government slow to mount defense against APTs

Government slow to mount defense against APTs

That advanced persistent threats are now the biggest cybersecurity problem government agencies face will not be news to many people. What may still be surprising, however, is just how long this problem has existed. The FBI believes at least one group of hackers has been using APTs against government agencies for at least the past five years -- and possibly much longer.

An alert posted online warned that the FBI “has obtained and validated information regarding a group of malicious cyber actors who have compromised and stolen sensitive information from various government and commercial networks,” and posted a list of domains the group had used to infiltrate networks and systems in the United States and abroad “since at least 2011.”

The domains have also been used to host malicious files, the FBI said, often through embedded links in spearphishing emails, and any activity related to the listed domains should be considered an indication of a compromise that needs mitigation.

The group identified by the FBI is thought to be a hacking unit called APT6, which various sources think is likely a nation-state-sponsored group based in China. It was a Chinese-sponsored group that was thought to have breached the systems at the Office of Personnel Management last year and compromised millions of government worker records.

The FBI alert highlights the still-yawning gap between the sophistication of those who want to get into government systems, and the government’s ability to defend against these APT attacks. The Department of Homeland Security’s Einstein and Continuous Diagnosis and Mitigation (CDM) programs, for example, have been touted as government’s main efforts to get effective security tools into agencies, but until now they’ve been based on known-signature detection, which is useless against APTs.

It was only this year that the DHS said Einstein would soon include tools that could track unknown threats, while the still-deploying CDM contract also only recently added behavior-based, non-signature tools to its product list.

Meanwhile, major government agencies continue to struggle to harden their network protection, even in the face of fallout from breaches. A recent internal review at the State Department, for example, found that the U.S. passport and visa Consular Consolidated Database was vulnerable to cyberattacks. That’s ranked as an unclassified but sensitive system that contains hundreds of millions of U.S. citizen passport and visa records that, if compromised, could threaten national security.

The potential danger of APTs is even greater considering the expansion of enterprise network boundaries. It used to be those were fairly well known and could therefore be well protected, but with the advent of mobile technology it’s become increasingly difficult to know just what network endpoints, and potential points of attack, exist at any time.

Now add the fact that organizations, particularly government agencies, are expanding the use of outside contractors, who themselves sub-contract to other companies, all of whom at some point might have access to agency networks. If that access is not well tracked, hackers could steal contractors’ access credentials and get access to agency networks.

The security company Bomgar has looked at the risk posed by third-party suppliers and found it to be quite high. While organizations tend to have a fairly high level of trust in their vendors, Bomgar said, only a third of those surveyed knew the number of logins to their networks made by third parties. Two-thirds admitted to having been breached in the past year because that vendor access was somehow compromised.

The inability to ’trust-but-verify’ is caused by the fact that so few organizations have the right technology in place. As Bomgar’s chief executive Matt Dircks pointed out, without the capacity to “granularly control access and establish an audit trail of who is doing what on your network,” you can’t protect yourself from those third-party security holes.

The APT threat, already large, will only grow. A recent report by the Institute for Critical Infrastructure Technology, a security think tank, pointed out that “at least” 100 APT groups are currently operational worldwide -- some state sponsored like APT6, but others run by criminals and mercenaries. It lists many of those groups, along with their histories, targets and methods of operation.

The conglomeration of hacktivists, state-sponsored hackers and for-hire cyber attackers are continuously targeting American corporations, organizations, universities and government networks, ICIT said, and are winning “because the United States lacks proper cyber hygiene and has yet to expedite a path to a cybersecurity-centric culture.”

That mindset could change, with the Obama Administration’s long-term strategy laid out earlier this year in its comprehensive Cybersecurity National Action Plan. How quickly that and other efforts will actually make a difference isn’t clear, however. Meanwhile, as the FBI APT6 alert shows, bad stuff has been (and probably still is) working away inside government networks, and there’s more on the way.

Posted by Brian Robinson on Apr 11, 2016 at 11:49 AM2 comments


Secure code before or after sharing?

Secure code before or after sharing?

The White House wants federal agencies to share more of their custom code with each other, and also to provide more of it to the open source community. That kind of reuse and open source development of software could certainly cut costs and provide more able software in the future, but is this also an opening for more bugs and insecure code?

The new draft policy, issued in support of the administration’s 2014 Open Government Partnership, is aimed at improving the way custom-developed code is acquired and distributed in the future. Before moving forward with this new policy, the government  wants to know just how it would “fuel innovation, lower costs, benefit the public and meet operational and mission needs of covered agencies” as well as what effect it could have on the software development market.

One thing the draft policy doesn’t address directly is what impact government code could have on the security of any open source software that results.  John Pescatore, director of emerging security trends at the SANS Institute, is one of those who has expressed concerns. In comments about the draft, he points out that government’s testing of its own code for vulnerabilities “has been minimal and inconsistent.”

That’s sparked an interesting back and forth about the government’s role regarding code released to the open source community. Pescatore believes scanning for vulnerabilities before code is released wouldn’t be that big of a deal. Others, however, think that responsibility belongs to the open source community, which has long maintained that “the more eyes, the more secure” open source code is.

Well, yes and no. That was the argument behind OpenSSL, for example, and yet a vulnerability that went unnoticed for years led to the global Heartbleed scare and fears of widespread data leaks and breaches.

However, it’s also true that open source code has consistently been found to be more secure than most proprietary code, though it’s not infallible by any means. In the case of government code released to open source, it will be interesting to see which would be the best way to go -- especially considering that some of that code may find its way back into government use at other agencies. So, sanitize before release, or trust to the community to eventually secure it?

Pescatore, at least, has doubts. Software is software, he believes, whether open source or proprietary. And if simple vulnerabilities are not removed before releasing it, “it is bad software.”

Posted by Brian Robinson on Mar 24, 2016 at 8:24 AM0 comments


quantum encryption

Can we build quantum-resistant encryption?

The possibilities and problems of quantum computing have figured more in science fiction than they have in government security, but that is gradually starting to change. The impact of quantum computing on cracking encryption schemes has long been debated, at least in concept, but now some are calling for government to take a more active role in mitigating that possibility.

The push for some action may get stronger after a recent announcement that computer scientists at the Massachusetts Institute of Technology and the University of Innsbruck had assembled a quantum computer that could eventually break RSA (Rivest-Shamir-Adleman) public key encryption, the most popular form of encryption in the world. What’s more, they did it with a calculation that used just five quantum bits (qubits), far fewer than had been thought necessary.

A qubit is a unit of quantum information, analogous to the on/off bit used in classical computing, although in the “spooky” universe of quantum mechanics (as Einstein put it) a qubit can be in both states at the same time. It’s by manipulating that property that quantum computers can do some kinds of computation very efficiently, such as factoring very large numbers.

Current encryption methods, such as RSA, depend on the difficulty of doing all that number crunching. A public key is the product of two very large prime numbers, known only to the key provider, and cracking the encryption requires factoring, or breaking down, the key to reveal those two numbers. That’s very hard and would require years’ worth of computations with classical computing, even with the help of a large parallel computer.

It’s not as if quantum computers that can break public key encryption will here tomorrow. The MIT/Innsbruck effort was aimed at developing a method to factor the number 15, which was thought to require 12 qubits. That was considered the smallest number needed to meaningfully demonstrate Peter Shor’s quantum factoring algorithm, which was developed several decades ago.

And building the quantum computer, which requires a complicated setup of lasers, gases and such things as ion traps, was not simple. However, the MIT/Innsbruck team built their system to scale so that it can eventually handle much larger prime numbers. The fact that they reduced the resources required for that work by a factor of three should make that easier.

A quantum computer capable of factoring the numbers behind RSA and other encryption methods may still be another decade away, but that’s substantially less than the 20 to 30 years many had figured it would take. Some experts are already concerned that there may not be enough time to prepare adequately for the arrival of those large-enough quantum computers.

At a meeting last year, for example, computer security specialists discussed what cryptographic schemes would be required to resist quantum computers. Some openly worried that there wasn’t enough time --  given all the detailed discussion between governments and industry that will be needed --  to develop the proper protections.

At the meeting, Stephen Jordan, a physicist at the National Institute of Standards and Technology, stressed that you need a lot of people to scrutinize and test any cryptosystem for flaws if it is to be trusted, which “takes a long time.”

Some parts of government are not waiting, at least to set things in motion. At the beginning of this year, the National Security Agency’s Information Assurance Directorate published a FAQ aimed at giving national security system (NSS) developers the information they’ll need to begin planning and budgeting for new cryptography that is quantum resistant.

The IAD warned that, especially in cases where government information needs to be protected for many decades, “the potential impact of adversarial use of a quantum computer is known and without effective mitigation is devastating to NSS.”

One thing the MIT/Innsbruck team proved is that the development of quantum computers that can break very complex encryption is no longer theoretical.

“It might still cost an enormous amount of money to build, [and] you won’t be building a quantum computer and putting it on your desktop anytime soon,” Isaac Chuang, professor of physics and professor of electrical engineering and computer science at MIT, said in announcing the team’s  accomplishment. “But now it’s much more an engineering effort and not a basic physics question.”

Posted by Brian Robinson on Mar 11, 2016 at 6:52 AM3 comments


Feds want mobile security, except when they don’t

Feds want mobile security, except when they don’t

Mobile security is assumed to critical to an agency’s overall IT security, but details on the effectiveness of such programs are scarce, making it hard to assess the overall risk from mobile devices.

A study by the Ponemon Institute and cybersecurity company Lookout of nearly 600 IT and security executives at major organizations, including those in the public sector, shows the risk from mobile devices is great and increasing. In fact, the majority of the study respondents believe mobile is a root cause of breaches.

Some 83 percent say mobile devices are susceptible to hacking, and over two-thirds said it was certain or likely that their organization had a data breach caused by employees accessing sensitive and confidential information using mobile devices.

At the same time, only 33 percent of the respondents said their organization was vigilant in protecting data from unauthorized access. Even more startling, nearly 40 percent didn’t even consider protection of that data on mobile devices to be a priority.

Perhaps that’s not surprising when, according to the study, most of these IT security professionals didn’t know what their employees were really accessing on their devices. Those who said they did know thought the data was mostly email and text, when, in fact, personally identifiable information, customer records and confidential and classified documents made up a large part of it.

One of the biggest problems for security pros is translating this kind of information into the hard dollar damage that executive leaders look for to put a price on breaches. Ponemon takes a tilt at that figure, concluding that dealing with mobile devices with malware on them could cost over $26 million for the organizations in the study.

The inconsistent thinking over the utility of mobile devices and the security problems they pose is not new. A survey in 2014 by the Government Business Council  found that 72 percent of federal government employees back then said they used mobile devices for work, and over half saw mobile security as one of the major challenges to expanding use of mobile. Yet less than one-third used any kind of mobile security app.

Despite all of this seeming inattention to mobile security, things seem to be improving. Last year, the Office of Management and Budget put out a cybersecurity memo that directly addressed mobile security, and the National Institute of Standards and Technology came out with a draft guide for securing mobile devices -- both moves indicating the importance of keeping mobile devices and the data they hold secure.

What, then, to make of the recent kerfuffle over the FBI getting a court order requiring Apple to break the strong encryption on an iPhone used by one of the terrorists who gunned down government workers in San Bernardino, Calif., in December?

The merits of the FBI’s argument (or of Apple’s pushback against that order) aside, this argument has implications for overall mobile security. If the FBI wins the debate and Apple must write iOS code that allows the FBI and other law enforcement and intelligence agencies to break into phones, that weaker security could compromise every other mobile user.

Strong encryption has been proposed as a universal solution for protecting data on mobile devices. It might not stop the most determined attacker, but it will prevent most of the bad actors from stealing whatever data is on a device. The Obama Administration itself has pushed for encryption, and the Ponemon report in its study found it was the most preferred means of securing data.

Recently, however, Bloomberg reported on what it called a “secret meeting” at the White House around Thanksgiving last year, where senior national security officials ordered government agencies to develop encryption workarounds so that investigators could get to user data as they needed.

All of this seems to throw the issue of mobile security risk -- one of the most important government IT issues -- into doubt, once again. With malware and the attackers who use it becoming ever more sophisticated and capable, any weaknesses will be found out and exploited. For agencies and mobile users, conflicting messages over security sow doubt and confusion.

So, where to now?

This blog was changed Feb. 29 to include Lookout, Ponemon Institute's partner in the mobile risk study.

Posted by Brian Robinson on Feb 26, 2016 at 10:46 AM0 comments