NIST

I recently read that HIPAA regulations require organizations to follow NIST guidelines and standards. Is this true?...

How does HIPAA incorporate NIST guidelines? Should healthcare organizations follow the NIST regardless?

Although HIPAA does not directly require that covered entities follow NIST guidelines and standards, it references many of them as strong practices. NIST guidelines provide technical information and advice to organizations trying to meet common security objectives that overlap with those of HIPAA. NIST publications can therefore be valuable resources for organizations that must comply with HIPAA, helping them better understand their HIPAA obligations and how to meet them.

In particular, NIST offers its Special Publication 800-66, a document of over 50 pages entitled "An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule." Describing each HIPAA requirement in turn, this guide provides details on the administrative and technical safeguards that a HIPAA covered entity can put in place for compliance.

As NIST indicates, SP 800-66 was prepared for use by government agencies, and may be used by nongovernment agencies on a voluntary basis. The document contains a disclaimer stating that it is intended for federal organizations, and that it is not intended to be, nor should it be, construed or relied on as legal advice for any other organization or person. In other words, HIPAA is the still the law. The NIST publication is a helpful guide, but is one interpretation of the law, not the law itself. Consequently, it cannot be used as legal validation of a position or actions undertaken to comply with HIPAA.

Ask the Expert:
Got a vexing problem for Mike Chapple or any of our other experts? Ask your enterprise-specific questions today. (All questions are anonymous.)

Next Steps

Find out why HIPAA controls don't do enough for privacy and security

Learn how NIST standards can help with penetration testing

Find out how well the NIST Cybersecurity Framework is being received

This was last published in November 2016

Dig Deeper on HIPAA

  • All
  • News
  • Get Started
  • Evaluate
  • Manage
  • Problem Solve

PRO+

Content

Find more PRO+ content and other member only offers, here.

Related Q&A from Mike Chapple

Is a no-SMS 2FA policy a good idea for enterprises?

Now that NIST has deprecated the use of SMS 2FA, should nongovernment organizations follow suit? Expert Mike Chapple discusses the risks of SMS-based...continue reading

How does the Safeguards Rule pertain to SEC cybersecurity regulations?

The SEC claimed Morgan Stanley violated the Safeguards Rule, but what does that mean? Expert Mike Chapple discusses the federal regulation and what ...continue reading

Is destroying a decryption key a strong enough security practice?

Destroying a decryption key isn't the same as destroying the data, but which method is more secure? Expert Mike Chapple explains the best way to ...continue reading

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.


SearchSecurity: Security Wire Daily News

Security experts have long said that internet-connected systems and software need security controls and features built in by design, in the same manner they’re built into physical infrastructure. The National Institute of Standards and Technology agrees and has issued guidance to help software engineers build secure products.

Titled “Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems,” the guideline emphasizes incorporating “well-defined engineering-based security design principles at every level, from the physical to the virtual,” NIST Fellow Ron Ross wrote on the Taking Measure blog. A holistic approach does more than make systems penetration-resistant; even after a compromise, they’re still capable enough to contain the damage and resilient enough to keep supporting critical missions and business functions.

[ An InfoWorld exclusive: Go inside a security operations center. | Discover how to secure your systems with InfoWorld’s Security Report newsletter. ]

NIST’s guidance uses the international standard ISO/IEC/IEEE 15288 for systems and software engineering as a framework, and it maps out “every security activity that would help the engineers make a more trustworthy system” for each of the 30-plus processes defined by the standard. The activities cover the entire system lifecycle, from the initial business or mission analysis to requirements definition to the design and architecture phases, and they’re applicable for new, upgraded, or repurposed systems.

“We have a high degree of confidence our bridges and airplanes are safe and structurally sound. We trust those technologies because we know that they were designed and built by applying the basic laws of physics, principles of mathematics, and concepts of engineering,” Ross wrote. Similarly, applying fundamental principles in mathematics, computer science, and systems/software engineering can give us the same level of confidence in our software and hardware.

Taking a holistic approach

A holistic approach requires coordinating across different specialties, such as information, software and hardware assurance, physical security, antitamper protection, communications security, and cryptography. It also demands addressing multiple focus areas, such as privacy, verification, penetration resistance, architecture, performance, validation, and vulnerability.

The guidance addressed the dependencies and  subspecialties by grouping the processes in the system lifecycle into four families:

  • Agreement Process: Tasks related to acquiring products and services, as well as providing services as a supplier.
  • Organizational Project-Enabling Process: Lifecycle model management, infrastructure management, portfolio management, human resource management, quality management, and knowledge management.
  • Technical Management Process: Project planning, project assessment and control, decision management, risk management, configuration management, information management, and quality assurance.
  • Technical Process: All the activities related to business or mission analysis, defining stakeholder needs and requirements, defining system requirements, defining the architecture, defining the design, system analysis, implementation, integration, verification, transition, validation, operations, maintenance, and disposal.

The processes outlined in the publication do not prescribe a mandatory set of activities and do not explicitly map to specific stages in the lifecycle, NIST warned. Engineers should rely on their experience and their understanding of the organization’s objectives to tailor the processes to meet the stakeholder’s requirements for a trustworthy system.

The publication also did not attempt to formally define systems security engineering. There is something for everyone involved in the process, from business stakeholders to developers, administrators, and security analysts.

Calling on engineers

When civil engineers build a bridge, they have to consider the weight of vehicles and people crossing the bridge, the stress caused by wind and other natural elements, and the materials used to build the bridge itself. Buildings have to meet specific structural and fire codes to make sure they are safe and will not collapse. Similarly, software engineers need to build systems with security controls already included in the design and not added afterward as a separate component.

If bridges were routinely collapsing, scientists and engineers would be immediately on the scene to figure out what went wrong and identify how to fix it for future projects. Currently, instead of asking engineers and scientists to perform root-cause failure analysis to find and fix the problem, cybersecurity focuses on add-ons. Changing how technology is designed and built—by strengthening underlying systems and system components, and developing with well-defined security requirements—would help reduce the number of known, unknown, and adversary-created vulnerabilities, Ross said.

NIST’s approach echoes what Dan Kaminsky, chief scientist and co-founder of White Ops, said in his keynote speech at the Black Hat security conference earlier this year. Kaminsky called for an “NIH [National Institutes of Health] for Cyber” to study the security challenges and come up with engineering solutions addressing them. While Kaminsky was using the name of a different federal agency, his message was the same: Cybersecurity needs to be treated as an engineering discipline with tools and principles that can be used to build secure systems.

“We didn’t stop our cities from burning by making fire illegal or heal the ill by making sickness a crime. We actually studied the problems and learned to deliver safety,” Kaminsky said in his speech. “If we want to make security better, give people environments that are easy to work with and still secure.”

Addressing the IoT problem

While NIST focused the language on systems and software, the guidance provides a welcome direction for the internet of things, most of which hit the market with little to no security controls.

NIST’s authority extends to only government agencies and contractors, so the guidance is not binding for engineers working in the private sector. Even so, these recommendations can raise expectations on what features must be included to be acceptable for the marketplace.

This NIST publication is the culmination of nearly four years of work, Ross said. The final draft was originally expected in December, but the release date was moved up after a crippling distributed denial-of-service attack against Dyn temporarily cut off access to large parts of the internet. The attack also revived discussions on whether the government should try to regulate the security of IoT, especially since there are currently no consequences for manufacturers selling subpar devices to consumers.

Regulation would be difficult, as many of the embedded devices aren’t manufactured in the United States. “While I’m not taking a certain level of regulation off the board, the United States can’t regulate the world,” Rep. Greg Walden (R-Ore.), chairman of the Subcommittee on Communications and Technology said during a recent Congressional hearing on IoT security.

Building trustworthy systems

The rapid pace of technological innovation, the dramatic growth in consumer demand for new technology, and the boom in IoT have made it difficult to understand, let alone protect, the global information technology infrastructure. There are too many areas to cover—software, firmware, hardware components—and cyberhygiene efforts, such as patching, asset management, and vulnerability scanning, are not enough.

“Our fundamental cybersecurity problem can be summed up in three words—too much complexity,” Ross wrote. “Creating more trustworthy, secure systems requires a holistic view of the problems, the application of concepts, principles, and best practices of science and engineering to solve those problems, and the leadership and will to do the right thing—even when such actions may not be popular.”

To comment on this article and other InfoWorld content, visit InfoWorld's LinkedIn page, Facebook page and Twitter stream.


InfoWorld Security

Two U.S. government agencies have released security guidance documents focusing heavily on IoT security following a series of massive DDoS attacks that leveraged IoT devices using default security settings.

Both the Department of Homeland Security (DHS) and the National Institute of Standards and Technology (NIST) have released recommendations for how to approach security for the Internet of Things (IoT). Experts said the IoT security guidance from DHS focuses on the basics while NIST had offers more of a "how-to" for businesses.

The DHS IoT security guidance put forth six strategic principles intended to equip IoT developers, manufacturers, service providers and consumers "with tools to comprehensively account for security as they develop, manufacture, implement or use network-connected devices." The DHS recommends: incorporating IoT security in the design phase, pushing security updates, building upon proven security practices, prioritizing higher risk issues, promoting transparency and being deliberate in the use of IoT devices.

Derek Manky, global security strategist at Fortinet, told SearchSecurity that the focus on the basics from the DHS was the best strategy for IoT security guidance.

"There's a lot of groups that should have focused on [the basics], but unfortunately nobody saw the problem until there were millions of devices deployed across the world," Manky said via email. "I think the best option is to focus on the basics right now. There aren't any best practices out there from an IoT perspective -- for security and development alike. The first step is to develop the right framework and then start changing the mindset of the IoT developers."

Art Swift, president of prpl Foundation, said the DHS offered "a good baseline for IoT security practices." 

"While it may seem basic, these are exactly the things manufacturers and developers need to be doing to improve security in the Internet of Things, Swift said. "The part that is not addressed by the DHS is to provide any practical guidelines on how to implement its recommendations."

Jamison Utter, vice president at IoT cybersecurity firm Senrio, said "it's important at this phase for any governing body to set for things that are high impact, but very achievable."

"For example in the 'Incorporate Security at the Design Phase' section is to enable security by default," Utter told SearchSecurity via email. "This single recommendation of changing default passwords would have a profound impact on simple compromises -- and 90% are simple. Mirai, for example, uses default passwords."

Manky agreed that the Mirai botnet attack was proof that security from the start is one of the most important issues in IoT security.

"Mirai was shown to have accumulated its great power through something incredibly simple -- trying to log-in to devices using their default usernames and passwords. If developers just eliminated default usernames and passwords it would have completely dismantled this botnet before it got off the ground," Many said. "Security from the start means incorporating things like the Common Weakness Enumeration to evaluate the security posture of your product, where things like hardcoded and default passwords would be fleshed out before they ever make it out the door."

However, Utter said the DHS IoT security guidance left out more technical details.

"The document seems to have some overtones (ok, strong ones) of recycled ideology. Things like 'patch management' is really not something the IoT has the ability to scale right now," Utter said. "It also has some traditional thinking and assumptions -- like that the IoT is still an 'on network' issue, where we rather think of the IoT as an always connected and always on issue. So the guidance is good, the vision of how to apply this frame work to the reality of IoT falls a bit short."

Manky said "the DHS release explains the what and why, and if you want to security seriously, the NIST Special Publication gives you a how-to."

According to the new NIST Special Publication 800-160, " Engineering-based solutions are essential to managing the growing complexity, dynamicity, and interconnectedness of today's systems, as exemplified by cyber-physical systems and systems-of-systems, including the Internet of Things. This publication addresses the engineering-driven perspective and actions necessary to develop more defensible and survivable systems, inclusive of the machine, physical, and human components that compose the systems and the capabilities and services delivered by those systems."

Swift said "it's time to get the industry at large involved and effecting the change needed to make IoT safer and more secure."

"Securing devices at the hardware layer is one of the most important ways the IoT is going to become more secure, but using open source software is also a key area. Manufacturers and developers should no longer rely on proprietary code that can be reverse engineered as it has been proven time and time again that this 'security by obscurity' approach is broken," Swift said. "By using open source implementations, which are open to review and hence inherently more secure, developers can agree to get basics right on security first and then compete on value-add market differentiators."

Manky praised the two new IoT security guidances for promoting the need for more discussion on the topic.

"This needs to be collaborative, and it's not just Silicon Valley they need on board. They need manufacturers of practically every vertical to adopt this mindset, and a surefire way to lose your voice is to demand too much too soon," Manky said. "These are things we've been saying within the tech world for years, but the IoT reaches so many new people. So many things that weren't done over IP are quickly moving that direction. It's the next wave of digitalization, and continual outreach is important."

Next Steps

Learn more about the risks to consider with IoT systems.

Find out if passwords are destined for obscurity.

Get info on why the IoT security window is closing.


SearchSecurity: Security Wire Daily News

Relying on passwords is no longer enough, and two-factor authentication is a necessary component to secure applications, networks, and systems. However, the most common kind of two-factor authentication -- sending special codes via SMS messages -- may no longer be an acceptable form.

In the latest draft version of its Digital Authentication Guideline, the United States National Institute of Standards and Technology (NIST) is discouraging companies from using SMS-based authentication in their two-factor authentication schemes.

[ Also on InfoWorld: 19 open source GitHub projects for security pros. | Discover how to secure your systems with InfoWorld's Security newsletter. ]

Many services offer two-factor authentication by asking users to enter into the app or site one-time passcodes sent via SMS to verify the transaction. Concerned about the weaknesses in the SMS mechanism, NIST is now recommending that developers use tokens and software cryptographic authenticators instead.

 "OOB [out of band] using SMS is deprecated and will no longer be allowed in future releases of this guidance," NIST wrote in a draft version of the DAG.

Software companies follow the guidelines set by NIST in their applications since federal agencies aren't allowed to use applications that don't conform to NIST guidelines. This is especially relevant for secure electronic communications.

SMS-based two-factor authentication is considered an insecure process because someone other than the user may be in possession of the phone and would be able to trigger the login request. In some cases, the contents of the text message appear on the lock screen, which means the code is exposed to anyone who glances at the screen.

NIST isn't deprecating SMS-based methods simply because someone may be able to intercept the codes by taking control of the handset -- that risk also exists with tokens and software authenticators. The main reason NIST appears to be down on SMS is because it is insecure over VoIP.

There has been a significant increase in attacks targeting SMS-based two-factor authentication recently. SMS messages can be hijacked over some VoIP services. Security researchers have used weaknesses in the SMS protocol to remotely interact with applications on the target phone and compromising users.

A recent attack used social engineering to bypass Google's two-factor authentication. Criminals sent users text messages informing them that someone was trying to break into their Gmail accounts and that they should enter the passcode to temporarily lock the account. The passcode -- which was a real code generated by Google when the attackers tried to log in -- arrived in a separate text message, and users who didn't realize the first message was not legitimate would pass the unique code on to the criminals.

"NIST's decision to deprecate SMS two-factor authentication is a smart one," said Keith Graham, CTO of authentication provider SecureAuth. "The days of vanilla two-factor approaches are no longer enough for security."

NIST outlines the future of SMS-based authentication in the DAG. If the out-of-band verification is to be made via SMS message on a public mobile phone network, the verifier has to verify the phone number is on an actual mobile network and not associated to a VoIP or other software-based phone services. It should also not be possible to change the phone number receiving the SMS message without using two-factor authentication.

For now, applications and services using SMS-based authentication can continue to do so as long as it isn't a service that virtualizes phone numbers. Developers and application owners should explore other options, including dedicated two-factor app such as Google Authenticator, which uses a secret key and time to generate a unique code locally on the device for the user to enter into the application.

Hardware tokens such as RSA's SecurID display a new code every few seconds. A hardware security dongle such as YubiKey, used by many companies including Google and GitHub, supports one-time passwords, public key encryption, and authentication. Knowing that NIST is not very happy with SMS will push the authentication industry towards more secure options.

Many popular services and applications offer only SMS-based authentication, including Twitter and online banking services from major banks. Once the NIST guidelines are final, these services will have to make some changes.

Many developers are increasingly looking at fingerprint recognition, especially since the latest mobile devices have fingerprint sensors. Organizations can also employ adaptive authentication techniques, such as layering device recognition, geo-location, login history, or even behavioral biometrics to continually verify the true identity of the user, Graham said.

NIST acknowledged that biometrics is gaining steam as a method for authentication, but refrained from issuing a full recommendation because biometrics aren't considered secret and can be obtained and forged by attackers through various methods. Biometric methods are acceptable only if they are used with another authentication factor, according to the draft guidelines.

"[Biometrics] can be obtained online or by taking a picture of someone with a camera phone (e.g. facial images) with or without their knowledge, lifted from objects someone touches (e.g., latent fingerprints), or captured with high resolution images (e.g., iris patterns for blue eyes)," NIST wrote in the DAG.

The current version of the DAG is in public preview, which means the guidelines are still under discussion and NIST is soliciting feedback from partners and NIST stakeholders. At this point, it appears NIST is moving away from recommending SMS-based authentication as a secure method for out-of-band verification. If it doesn't happen in this version, it will likely happen in future versions. Anyone who wants to review and comment can use GitHub to do so.

"It only seemed appropriate for us to engage where so much of our community already congregates and collaborates," NIST wrote.

SMS was an easy way to get developers, application owners, and users started on the two-factor authentication journey, because it was also the simplest. SMS is better than no two-factor at all, but the never-ending stream of data breaches indicates that better and stronger authentication methods are needed.


InfoWorld Security