When you develop software, are security regulations front of mind? They probably are if you are developing software for highly regulated industries, such as Health Insurance Portability and Accountability Act (HIPAA)-compliant software for the healthcare industry or Payment Card Industry (PCI)-compliant solutions for electronic payments. But as more regulations and standards address the challenge of data security, it’s becoming apparent that virtually all businesses will be required to meet at least basic security standards. This year, the EU began enforcing its General Data Protection Regulation (GDPR) and the California Consumer Privacy Act became law, each requiring businesses that collect or store consumer data to meet security standards. And 2018 also marked enforcement of NIST Special Publication SP 800-171 Rev. 1, which sets security requirements for protecting Controlled Unclassified Information (CUI).
What is Controlled Unclassified Information?
CUI is defined as government data that “requires safeguarding or dissemination controls” under law, regulation or government policies. As of December 31, 2017, when CUI is stored or processed in nonfederal systems, NIST SP 800- 171 requirements apply. The regulation is enforced by the Department of Defense (DOD), and those who do not comply risk losing their DOD contracts, but it’s not limited to DOD contractors and subcontractors. The security requirements apply to any business or organization that uses this government data.
CUI is divided into more than 100 categories, such as:
- Critical Energy Infrastructure Information
- Emergency Management
- Information Systems Vulnerability Information
- Electronic Funds Transfer
- Mergers
- Net Worth
- Retirement
- Campaign Funds
- Law Enforcement Financial Records
- Collective Bargaining
- National Park System Resources
- Patent Applications
- Health Information
- Military Personnel Records
- General Procurement and Acquisition
- Proprietary Manufacturer
- Statistical Information
- Federal Taxpayer Information
The spectrum of data that NIST SP 800-171 covers reflects the wide range of businesses and organizations that must comply with the security requirements – from energy companies, payment processors, legal firms, financial organizations, manufacturers, accounting firms, and healthcare providers.
NIST SP 800-171 Requirements, a Partial List
NIST SP 800-171’s hundreds of administrative and technical requirements are found on pages 9-15 of the document, and they include:
- Limiting access to only authorized people
- Limiting unsuccessful login attempts
- Maintaining audit logs and records and protecting them from unauthorized access
- Monitoring and controlling communications within the organization
- Setting expiration dates on files to prevent access after a project is closed
- Monitoring and controlling remote access sessions
- Controlling connection of mobile devices
- Encrypting data in transit and at rest
- Monitoring systems for threats and intrusion
- Limiting the use of portable storage devices
- Controlling processing on publicly accessible systems
- Restricting or disabling the use of nonessential functions or ports
- Blacklisting or whitelisting software
- Requiring multifactor identification
NIST SP 800-171 – and Other Regulations – as Best Practices
With the growing number of regulations enforcing security measures across a wide range of industries — many that echo similar standards — does your software support them? Are you aware of the security standards and best practices your customers must comply with? And are you aware of the requirements the new markets you are targeting must meet?
As time goes on, security risks continue to escalate, and government and industry agencies more vigorously enforce security standards, compliant software will be the most valuable to your market. It’s time to take a big picture view of your application, the types of businesses that are using it (or could use it), and whether companies aren’t choosing it because it doesn’t align with the security requirements they must meet.
Of course, depending on your application, not all security standards would be relevant, but ISVs may be at the tipping point where if a security standard can addressed in a software application, it should be. 
