Derived credentials for mobile on the horizon?

Derived credentials for mobile on the horizon?

All government employees are familiar with using a smart card to access buildings, their desktop computers or just about anything that requires a so-called hard-token passport. That’s not such a good thing for employees who want to access government information from their mobile devices, however, which is where derived credentials come in.

For one thing, supplying all government users of mobile devices with a card reader is a very expensive proposition. Using that reader every time employees want to use their device to get into a government network or website is also cumbersome, to say the least, and potentially life-threatening when responders want network access during an emergency.

The dangers of using a single password for mobile access have been obvious for a while, so government has been on the lookout for a better and more convenient solution. Just over two years ago, the National Institute of Standards and Technology issued the first draft of guidelines for implementing derived personal identity verification (PIV) credentials on mobile devices.

Essentially, it’s a software version of the PIV credentials stored on the government smart cards. It’s directly related to NIST SP 800-57 guidelines on cryptographic key management, which is the basis for government security policies such as Homeland Security Presidential Directive 12 and those governing public-key infrastructures (PKIs).

So far, however, derived credentials have rarely been implemented in government. That might change with the recent announcement by MobileIron, an enterprise mobility management provider, and Entrust Datacard that they are partnering on a derived credential product that could be available for government mobile users by the end of the year.

It’s the result of a long process, said Sean Frazier, chief federal technical evangelist at MobileIron. NIST had to spend time developing the final SP 800-157 guidelines on derived credentials, and at the same time, Entrust and other organizations that control the government’s backend certificate management systems that enable the use of PIVs, had to amend and adapt those systems to allow for derived credentials.

MobileIron’s job was to develop the software that would manage the credentials on the device and make sure they could be seen by various applications.

“We didn’t start seeing pilots or testing for this until the NIST guidelines went into draft mode in 2014,” Frazier said, “and it’s taken the two years since then to wind our way through the final policy pronouncements and product development.”

The first users of the product will likely be civilian agencies, which have been looking for a solution that would also allow them to extend their current investments in hard-token PIV and smart cards instead of having to develop a different authentication system for mobile users.

It’s unclear so far whether the Defense Department would use this type of mobile soft token. DOD went its own way on PKI and Common Access Card implementation, and a few months ago, it said it would be eliminating CACs in favor of a new, multifactor authentication system. Meanwhile, last year DOD approved the use of derived credentials for some of its BlackBerry users.

Frazier said the new derived credential product could spell the end for legacy BlackBerry devices still in use at various civilian agencies. The devices had been pervasive in government because of the secure connectivity they brought with them. For that reason, agencies have been reluctant to get rid of them until they had other viable systems in place, Frazier said, adding that the derived credential could be a big incentive for making the switch.

“This allows [agencies] to provide the kind of seamless mobile experience they’ve always talked about wanting to deliver for their users,” he said. “It gives them that experience while tying the security to that existing hardware token, so they have a higher level of security and better usability.”

Posted by Brian Robinson on Aug 26, 2016 at 1:07 PM0 comments


Can users help solve the mobile security disconnect?

Can users help solve the mobile security disconnect?

Read any story about cybersecurity these days, and chances are you’ll see at least some mention of the importance of mobile security. That’s for good reason, because mobile is considered one of the greatest, if not the greatest, risk to overall enterprise IT security. Despite this acknowledgement, enterprises are still not doing enough to protect again mobile threats.

At least, that’s the conclusion of MobileIron’s latest quarterly Mobile Security and Risk Review, which details a fairly stark disconnect between the threats faced by both private and government organizations and the protections they’ve implemented.

Despite the noted rise in the number and sophistication of mobile threats, MobileIron found, only 8 percent of organizations are enforcing operating system updates, and less than 5 percent are using the most modern mobile security applications, such as app reputation or mobile threat detection software.

All of this shows that, while the speed at which attacks are developed and implemented is increasing, enterprises are still not doing what they should to protect themselves. This “lack of security hygiene demonstrates that enterprises are alarmingly complacent, even when many solutions are available,” according to James Plouffe, MobileIron’s lead architect.

Other surveys have come to the same conclusion. A recent Ponemon Institute study, for example, found that a large majority of respondents saw mobile devices as both susceptible to hacking and the probable cause of data breaches in their organizations, but only a third were “vigilant” in protecting their data. Just under 40 percent didn’t even see a pressing reason to protect data on their mobile devices.

Sean Frazier, the chief technology evangelist for MobileIron’s Public Sector Practice and someone who has years of experience working with government, said that while agencies are certainly thinking about doing right by mobile overall, they still don’t have a concept beyond those of basic mobile capabilities.

They’re “struggling to get their arms around the whole mobile app concept,” he said. They are not yet as capable as many other organizations around the world, and they either don’t fully understand the dangers, “or they do, but find they can’t respond as quickly or as well.”

There’s a disconnect with this, he believes. Government overall responds well to most IT security incidents, but it doesn’t seem to understand how to transfer that insight to mobile. When MobileIron goes into agencies and asks to talk to the folks in charge of mobile, he said, they’ll often get shunted over to those in charge of email or other functions -- not to the security people.

Disconnects show up in other areas of government as well. The Obama administration, for example, has been pushing for the increased use of encryption to safeguard at least some part of the IT traffic chain. The Office of Management and Budget last year issued a memo  requiring agencies to use HTTPS for all website and services connections by the end of 2016.

At the same time, however, national security officials have been making a concerted pitch  to get some kind of back door inserted into operating systems, messaging services, etc. to help them tap into encrypted communications from suspected terrorists.  Experience has shown that, if those kinds of workarounds exist, at some point the bad guys will find them and use them to get into government networks and systems.

A basic problem, according to Frazier, is that government hasn’t caught on to the fact that mobile has fundamentally changed how IT should be viewed and managed, with users now much more involved at a higher level. That’s a radical departure from traditional views of mobile where, say, agency IT departments hand out sanctioned BlackBerrys -- with just IT-approved apps and data on them -- to their employees.

Today’s mobile IT environment -- with all of the issues bring-your-own-device policies and shadow IT  bring with it -- presents a starkly different ecosystem to manage. Mobile devices today are mobile computers, not just communications devices. And it’s the users themselves, many of whom have been using mobile for their own needs for years, who have the knowledge about how to securely manage the apps and data on their devices.

Frazier said he thinks government will eventually see the utility of users managing mobile security, particularly since major manufacturers such as Apple and Samsung have built sophisticated security management into their devices.

“It’s about time that the user was brought more directly into the conversation,” he said.

Posted by Brian Robinson on Aug 16, 2016 at 11:22 AM0 comments


NIST drafts mobile security guidelines for responder tech

NIST drafts mobile security guidelines for responder tech

There’s arguably been no corner of government that’s profited more from the mobile revolution than the first responder community. The ability to quickly access public safety data in the field is critical to first responders’ performance during emergencies.

With those benefits, however, come concerns over how to secure that access. At any one emergency site, there are likely to be a number of public safety personnel from several departments or jurisdictions, all working in different operational environments, using an array of applications on various devices and separate operating systems. That’s a nightmare for sharing, and for securing the highly sensitive information to which responders must all have access.

The National Institute of Standards and Technology is trying to overcome this concern with a proposed reference design for both multifactor authentication and mobile single sign-on.  The standards are aimed directly at this public safety/first responder community.

Developed by NIST’s National Cybersecurity Center of Excellence (NCCoE), in collaboration with the responder community, the draft discusses all the standards-based technical options and trade-offs that public safety organizations will need to build out a range of mobile security services for their users.

Based on commercially available and open source products, the reference design should also “improve interoperability between mobile platforms, applications and identity platforms regardless of the application development platform used in their construction,” the NCCoE said.

That approach fits exactly with the kind of concerns organizations such as the National Association of State Chief Information Officers have expressed about cybersecurity, particularly in the age of the Internet of Things.

Public safety agencies must have a better understanding of the risks of the Internet of Everything, as well as a way to mitigate those risks. “Success will be predicated on an open platform that allows partners working together to use the same baseline technologies,” according to a NASCIO study.

The NCCoE project draft lays out a number of scenarios in which its framework would apply and describes a high-level architecture that could be used for mobile devices. It stresses that the reference design and implementation use a standards-based approach that uses the “native capabilities” of the mobile OS of the device.

The NCCoE wants comments on the proposed Mobile Application Single Sign-On project by Sept. 16.

Separately, NIST has produced the first draft of a new Digital Authentication Guideline, a part of its SP 800-63 line of electronic authentication technical and procedural guidelines that began in 2004. Given the increasing attention to cybersecurity over the past few years, the new publication is a fairly extensive overhaul of the authentication requirements government agencies are expected to follow.

Much of the public attention on the draft guidelines has landed on the fact that NIST is recommending phasing out -- “deprecating” in NIST jargon -- the use of out-of-band secure message service (SMS) for authentication. That refers to situations when a bank, for example, will send a one-time code to a customer’s mobile phone that is used along with a password to gain access to accounts.

As NIST points out, there is a substantial risk that such an SMS message could be intercepted or redirected, particularly if the message is sent on a public network. Because of the risks involved, “implementers of new systems SHOULD carefully consider alternative authenticators,” NIST said. Out-of-band use of SMS in future releases of SP 800-63B likely won’t be allowed.

However, the guidelines offer far more, taking apart and putting back together again many different scenarios of multifactor authentication, as well as single-factor hardware and one-time password solutions. Many people have speculated on the end of the password for authentication purposes, but the guidelines stress its continuing value, albeit in very controlled circumstances.

The draft document also limits the value of previously accepted authentication methods, such as biometrics. At one time, biometrics were considered the best answer to access and security verification because of their supposed imperviousness to being copied or misused. Now, however, the NIST guidelines support “only limited use of biometrics for authentication,” and only when they are used with another authentication method.

Posted by Brian Robinson on Jul 29, 2016 at 12:47 PM1 comments


Critical infrastructure in the crosshairs

Critical infrastructure in the crosshairs

The security threat faced by government networks and computer systems should now be obvious to everyone, even if some of the efforts to protect against those threats have been tardy. Threats against critical infrastructure systems, which are just as important to all levels of government, are less well known.

Security vendor Kaspersky Labs has taken a deep dive into the world of industrial control systems (ICS), which form the digital backbone of critical infrastructure systems, and found that it’s a very scary place. Even though the 189 ICS vulnerabilities it found in 2015 are at the same level of the past few years, the report said, that’s 10 times more than were discovered in 2010.

The higher numbers can likely be put down to increased attention on ICS security. However, as Kaspersky pointed out, that also means those vulnerabilities likely have been present for years before they were discovered and, presumably, open to exploit that whole time.

Just under half of the vulnerabilities in 2015 were considered critical by Kaspersky, and most of the rest were of “medium severity.” However, exploits for 26 of the vulnerabilities are already available, it said, while for many of the others no exploit code was necessary to get unauthorized access to the vulnerable systems. Kaspersky also found that only 85 percent of the published vulnerabilities had been completely fixed.

As with other types of cyberattacks, the threats against critical infrastructure systems seem to be getting more sophisticated. The hairs on the back of many peoples’ necks stood to attention when a likely state-sponsored attack on Ukraine’s power grid in December last year was discovered. An analysis said it was the first time such an attack had been made against a nation’s critical infrastructure systems.

Fearful that a similar attack could be leveled against U.S. systems, several senators recently proposed legislation that seeks to guard against that by replacing some of the digital components in the U.S. power grid with analog versions as a first attempt to stiffen the country’s critical infrastructure defenses.

The bad news continues. SentinelOne, another security firm, has found other sophisticated malware targeting at least one energy company. It’s likely a dropper tool used to gain access to carefully targeted network users, and it “exhibits traits seen in previous nation-state Rootlets and appears to have been designed by multiple developers with high-level skills and access to considerable resources,” the company said.

In other words, this is another piece of government-sponsored malware aimed at critical infrastructure. What’s more concerning is that the malware, called Furtim, was found on a dark web hacking forum, where such government-sponsored stuff isn’t usually found.

The potential danger of these kinds of attacks has been recognized by the U.S. government for some time, with outfits such as the National Institute of Standards and Technology and the Department of Homeland Security describing various security frameworks and monitoring practices that companies and infrastructure organizations should adopt to boost their cyber defenses.

More specific tools could be on the way. The Defense Advanced Research Projects Agency, for example, will soon kick off its Rapid Attack Detection, Isolation and Characterizations Systems (RADICS) program, which is aimed at developing automated systems that will help utilities restore power within seven days of a cyberattack. Part of that program is intended to produce tools that “can localize and characterize malicious software that has gained access to critical utility systems,” according to the broad agency announcement.

The problems posed by the growing, and increasingly sophisticated, attacks on critical infrastructure expand when the Internet of Things is taken into account. With many systems linked through the IoT, new vulnerabilities may be created by the “expanded” critical infrastructure. As Kaspersky Labs points out, business requirements now often dictate that ICS link with external systems and networks.

Protecting the infrastructure from attack will require a new way of thinking about critical systems cybersecurity. The old ways of isolating critical environment and “security through obscurity” can no longer be considered a sufficient security control for ICS, Kaspersky said.

Posted by Brian Robinson on Jul 18, 2016 at 2:25 PM0 comments