We Have Legal Requirements?
Yes, we have legal requirements!
I don’t know about you, but as a developer, it’s hard for me to parse legal documents. Programming languages are one thing. I don’t even need to know the language to get the gist of the source code. But show me even the most rudimentary legal document? Even the phrasing doesn’t fit in my brain.
Your customers, though, have certain expectations about how your code will operate and protect their data. In some cases, that expectation is a legal right. So, like it or not, we developers need to incorporate legal requirements into our systems. And that’s exactly what they are: they are requirements, just as much as functional requirements.
This post addresses the issue from the perspective of the United States. I don’t have the knowledge or experience to even comment on the requirements in other nations. But if you’re a developer in the United States, this should get you started.
Disclaimer: I am not a lawyer. I’m presenting a developer’s perspective to help you understand what this means from the perspective of application architecture, design, construction, deployment, and maintenance. Your company’s legal counsel should absolutely be involved in confirming your obligations, which could vary due to individual circumstance. And in any event, it’s a good idea to build a positive relationship with your legal team. You’ll be able to achieve a lot more working together. So, stop reading this post, seek out your legal team, and introduce yourself!
US Government Providers
Your obligations are very clear if you market your application (say, a cloud offering) to the United States government. The government lays out its expectations in a series of documents:
- Federal Information Processing Standard (FIPS)-199: This document explains how to look at your application and understand its potential impact: Low, Medium, and High. It seems like the document uses a lot of words to make its point, but like most government/legal documents, it’s highly precise. Read through it a couple of times and try to rate your application.
- Federal Information Processing Standard (FIPS)-200: Based on your application’s potential impact (that FIPS-199 helped you identify), FIPS-200 tells you what controls you need to apply. The controls, of course, are not in FIPS-200 — this is a government document, after all! But it does identity the document containing the controls, and that document is the next one in the list.
- National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 (rev4): I’m embarrassed to admit it, but I really like this document. Seriously! It appeals to the part of me that likes clear categorization and definition — and robust treatment of a topic. And this document has all three of those in abundance. You will eventually want to read this document in its entirety, but to see what controls you’ll need to implement in your system (yes, system — 800-53 goes beyond the application itself), start around page D-10. Appendix D lists the controls you’ll need to apply. Other sections in the document explain what each control means. Appendix D (and the whole document) groups controls by category (Access Controls, Awareness and Training Controls, Audit and Accountability Controls, etc.). For each control, it defines what potential impact applies. The fewest controls apply if you scored a Low; more if you scored Medium. Most apply if you scored High.
If your role focuses on development, categories like Configuration Management Controls, Contingency Planning Controls, Physical and Environmental Protection Controls, or Personnel Security Controls may not even be within your area of responsibility. Don’t ignore them! It’s important you still understand all of the requirements. That’s the best way for you to understand the context in which you’re developing code.
Note: Your legal team should be aware that if you market to a wide variety of US government entities, it’d be more economical (though hardly inexpensive!) to become certified through the Federal Risk and Authorization Management Program (FedRAMP). FedRAMP certification would let you do business with most US government entities without having to re-certify with each. Many of its requirements are based on the documents described above. FedRAMP’s beyond the scope of this post, but I wanted you to be aware of how it potentially relates to your efforts.
Selling Product to Consumers?
If your application sells anything to United States consumers, your life is in the process of getting more complicated. Techdirt ran a story last year about Watch Tower Records. The company was the victim of an attack that resulted in disclosed customer data. The Federal Trade Commission (FTC) contended that the company’s application security practices were so bad they qualified as negligent. So the FTC sued.
Tell me: what would news of the FTC suing your company do to your company’s reputation?
What would it do to your career if your code was at the center of the legal action?
The correct answer is: You never want to know, because you don’t want to ever be in that situation.
Consumers — and the US government, especially in the form of the FTC — require that applications take care of sensitive information. Social Security Numbers (SSNs), names/addresses, and account numbers are only some of the data elements we must to protect. The FTC publishes a web page that discusses data security from the perspective of kinds of applications: children’s applications, Internet of Things (IoT) applications, etc. I found the page easy to follow, and I thought the examples were clear and representative. Interestingly enough, if you decide to implement NIST SP 800-53 rev4, chances are, you’d be covered. Application security is, after all, ubiquitous, and protecting data through encryption is the same process regardless of the type of application. But some companies that balk at the perceived monolithic requirements of NIST SP 800-53 rev4 may find the FTC’s guidelines a little easier to approach — even if they are, at their heart, the same thing.
Your company only thrives if your customers trust you. Making sure your applications are secure is a foundation step in building that relationship. The FTC is on your side in this endeavor.
Dealing with Health Care Data?
If you think the FTC is concerned about consumers (and they are!), wait until you start learning about your requirements from the Department of Health and Human Services for the Health Insurance Portability and Accountability Act (HIPAA)!
Health records are among the most private and sensitive records our applications can handle. They therefore deserve all of the care we can bring to the table. HIPAA lays out the requirements for us. The best place for us developers to start is probably the HIPAA for Professionals page and the child page that summaries the HIPAA Security Rule. Though most of it is really common sense, it’s useful to delve into the definitions to be sure that you understand how the various data elements are classified.
But you know what? Just as following NIST SP 800-53 rev4 covers most of your efforts to conform to the FTC’s requirements, following NIST SP 800-53 rev4 can also take you most of the way to complying to HIPAA (assuming you understand how to classify your data). Security is security, after all! And NIST SP 800-53 rev4 does an outstanding job of laying everything out clearly.
Please don’t think of HIPAA compliance as “shackles” or an undue burden. Some businesses played fast and loose with their customer’s HIPAA data, so the government felt compelled to step in. I see nothing in HIPAA — or the FTC’s guidelines, or indeed in SP 800-53 rev4 — that isn’t common sense if you look at an automation system as a whole. Embrace it to earn your customer’s trust! HIPAA gives you a blueprint to begin to delight your customers! Embrace it!
It’s Your Career — and Reputation!
If you didn’t see your application’s audience described above, don’t think you’re off the hook! Niche markets may have their own legal requirements, but you should seriously consider reading and adopting NIST SP 800-53 rev4. I honestly think NIST SP800-53 rev4 presents a rational and comprehensive approach to building not only secure applications, but businesses that can consistently deploy secure applications over time. In other words, adopting that approach can help you success in the short term and in the long term.
One final note: if your company doesn’t embrace security, you should think seriously about the amount of risk you want to accept. Let’s say you want to abide by the FTC guidelines or HIPAA requirements, but your management says you don’t have the time and thwarts you. Ask yourself: if things go south and the FTC steps in, or HIPAA auditors show up at your company’s front door, how will that affect you? As a developer, you are ultimately responsible for your code, right? How will that play out in the worst case? Are you comfortable with that?
I hope that you’re not just working for a company that understands liability and the need to adhere to the minimum standards (or worse!). I hope you work for a company that embraces security as a means to build customer trust, retain loyal customers, and attract new customers. In that spirit, you can use the resources in this post to solidify your understanding of customer and government security requirements for your applications.
Have you had experience working with these tools? Have you have good luck advocating for additional security in your applications? I’d love to hear your comments!
by Terrance A. Crow
Terrance has been writing professionally since the late 1990s — yes, he’s been writing since the last century! Though he started writing about programming techniques and security for Lotus Notes Domino, he went on to write about Microsoft technologies like SQL Server, ActiveX Data Objects, and C#. He now focuses on application security for professional developers because… Well, you’ve watched the news. You know why!
