Certain commercial entities, equipment, or material may be identified in the document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that these entities, materials, or equipment are necessarily the best available for the purpose.

This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate Federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections.

In 1997, the National Institute of Standards and Technology (NIST) initiated a process to select a symmetric-key encryption algorithm to be used to protect sensitive (unclassified) Federal information in furtherance of NIST’s statutory responsibilities. In 1998, NIST announced the acceptance of 15 candidate algorithms and requested the assistance of the cryptographic research community in analyzing the candidates. This analysis included an initial examination of the security and efficiency characteristics for each algorithm. NIST has reviewed the results of this research and selected five algorithms (MARS, RC6™, Rijndael, Serpent and Twofish) as finalists. The research results and rationale for the selection of the finalists are documented in this report. The five finalists will be the subject of further study before the selection of one or more of these algorithms for inclusion in the Advanced Encryption Standard.

Few software development life cycle (SDLC) models explicitly address software security in detail, so secure software development practices usually need to be added to each SDLC model to ensure the software being developed is well secured. This white paper recommends a core set of highlevel secure software development practices called a secure software development framework (SSDF) to be integrated within each SDLC implementation. The paper facilitates communications about secure software development practices among business owners, software developers, project managers and leads, and cybersecurity professionals within an organization. Following these practices should help software producers reduce the number of vulnerabilities in released software, mitigate the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences. Also, because the framework provides a common vocabulary for secure software development, software consumers can use it to foster communications with suppliers in acquisition processes and other management activities.

The rapid growth of IoT devices has the potential to provide many benefits. It is also a cause for concern because IoT devices are tempting targets for attackers. State-of-the-art security software protects fullfeatured devices, such as laptops and phones, from most known threats, but many IoT devices, such as connected thermostats, security cameras, and lighting control systems, have minimal security or are unprotected. Because they are designed to be inexpensive and limited purpose, IoT devices may have unpatched software flaws. They also often have processing, timing, memory, and power constraints that make them challenging to secure. Users often do not know what IoT devices are on their networks and lack means for controlling access to them over their life cycles.The consequences of not addressing the security of IoT devices can be catastrophic. For instance, in typical networking environments, malicious actors can detect and attack an IoT device within minutes of it connecting to the internet. If it has a known vulnerability, this weakness can be exploited at scale, enabling an attacker to commandeer sets of compromised devices, called botnets, to launch large-scale distributed denial of service (DDoS) attacks, such as Mirai, as well as other network-based attacks. DDoS attacks can significantly harm an organization, rendering it impossible for the organization's customers to reach it and thereby resulting in revenue loss, potential liability exposure, reputation damage, and eroded customer trust. CHALLENGEBecause IoT devices are designed to be low in cost, with limited functionality using constrained hardware, and for limited purposes, it is not realistic to try to solve the problem of IoT device vulnerability by requiring that all IoT devices be equipped with robust and state-of-the-art security mechanisms. Instead, we are challenged to develop ways to improve IoT device security without requiring costly or complicated improvements to the devices themselves.A second challenge lies in the need to develop security mechanisms that will be effective even though IoT devices will, by their very nature, remain vulnerable to attack, and some will inevitably be compromised. These security mechanisms should protect the rest of the network from any devices that become compromised.Given the widespread use of IoT devices by consumers who may not even be aware that the devices are accessing their network, a third challenge is the practical need for IoT security mechanisms to be easy to use. Ideally, security features should be so transparent that a user need not even be aware of their operation.To address these challenges, the National Cybersecurity Center of Excellence (NCCoE) and its collaborators have demonstrated the practicality and effectiveness of using the Internet Engineering Task Force's Manufacturer Usage Description (MUD) standard to reduce both the vulnerability of IoT devices to network-based attacks and the potential for harm from any IoT devices that become compromised.