Almost every device and application needs to account for government regulations and standards. In part, that's because federal spending exceeds 20% of GDP. No matter what you're building, it's likely that the U.S. government is a potential customer. And if you work in an heavily regulated industry-such as financial, healthcare, or communications-your customers care deeply about compliance.
Over the years, engineers have had to familiarize themselves with FISMA, FIPS, HIPPA, HSPD-12, Public Law 108-458, and DoD 8500. It's alphabet soup, and each standard has its own set of unique requirements. But all of these standards aim to ensure the secure exchange of information. And the National Security Agency, the leading agency tasked with securing the nation's information systems, introduced a new government standard for secure communications just last year.
Presented to the security industry at the RSA Conference in 2005, this new standard is an additional level of security beyond the standards set out in FIPS, HIPPA, and other standards. It establishes requirements relating to cryptographic algorithms for hashing, digital signatures, and the key exchange that should be used when building products for the government. Known as Suite B, it's not just relegated to helping secure the government's top secrets.
When Daniel Wolf, the NSA's information assurance director, presented Suite B, he made a point of how a common set of algorithms enables the sharing of information between organizations. Achieving interoperability is critical to government, because it enables agencies to work together more effectively.
The same can be said for the private sector. By standardizing on the set of algorithms recommended by the NSA, companies will be better able to communicate securely with remote workers and partners. At the same time, they can provide customers with harder-to-crack devices and applications that have a much longer lifespan than those using aging algorithms.
Interestingly, the NSA recommended that Suite B be used for non-classified documents, too. This shouldn't be surprising. As a result of the ever-expanding network infrastructure, security must now reach further and deeper within devices and applications to deny malicious individuals the opportunity to enter and disrupt systems.
Stringent security requirements are becoming the norm, even for applications and devices on the network edge. This is because Voice over Internet Protocol (VoIP), PDAs, mobile phones, sensors, and Web portals--which are becoming increasingly mission-critical--integrate tightly with the enterprise. As a result, new vulnerabilities rise to the surface, and they need to be secured.
Making security native to vulnerable software and hardware components presents engineers with a number of interesting technical challenges:
- How do you optimize secure authentication without impairing performance for compact wireless devices-PDAs, handsets, RFID tracking devices, and sensors-when power consumption is a concern?
- How do you reduce bandwidth and processor demands required by the multiple steps taken to establish a secure environment through a conventional virtual private network?
- How do you work around the problem of having to add a coprocessor to support the large key size of aging but widely used algorithms for smart cards?
- How do you meet the low-bandwidth, high-reliability demands of devices and applications when interference and data corruption is a concern?
- How can you be sure that the applications and devices you build won't become a weak link that enables malicious individuals to infiltrate a network?
Fortunately, there's a clear path that enables you to easily incorporate Suite B into your roadmap, ensuring the longevity and interoperability of the products you build. Plus, companies are out there to help you work through the challenges.
As engineers overcome these challenges, they will find that integrating strong security within their devices and applications creates significant opportunities to increase market share through product differentiation and performance optimization.
In addition, the growing need for improved security across government and commercial enterprises is generating demand for new products, applications, and services-such as Personal Identity Verification (PIV) smart cards, e-passports, and devices that increase border security-that enable customers to meet critical mandates.
Among the new opportunities will be utilization of leading-edge security to defend against the cloning of manufactured products, improve devices that track assets, and eliminate counterfeit tickets for public transportation or entertainment.
As you begin the process of identifying the type and level of security you need, it helps to ask yourself the following questions:
- What security services are required to deliver the necessary protection?
- Where should the security reside?
- The application-layer is the default choice for transaction-based applications, particularly where digitally-signed or strongly-authenticated transactions are required for non-repudiation. If end-to-end or user-to-user security is required--especially in the wireless space--application-layer security may be the necessary security model even though the application fits the mold for transport-layer security.
- Transport-layer security is the default choice for browser-based applications and for those requiring confidentiality and data integrity (message authentication).
- Network-layer security is the default choice for securing remote access to many enterprise applications.
- If an application requires non-repudiation, public-key cryptography must be used.
- If more than a handful of users must transmit encrypted data to each other, public-key encryption is the logical choice.
- The choice of algorithm is driven by interoperability concerns and computational resources. Web browsers, for example, must implement SSL with RSA cipher suites because all Web servers do so. However, for constrained devices, ECC is the most compact and practical asymmetric algorithm for security.