Contracting for Security in Your Mobile App

All sorts of businesses are being told that they need to write an “app”. Unfortunately, mobile apps constitute a new frontier in contracting that most companies and their attorneys don’t yet have a firm grip on. When it comes to ensuring the software you license or have built for you has taken appropriate steps to ensure the confidentiality, integrity and availability (CIA) of data as well as the appropriate levels of authentication, authorization, and accounting (AAA) is employed, your main tool is going to be contractual.

While I am not an attorney, and you should consult your attorney for actual legal advice toward constructing any agreement, I understand both the business end and technical part of software development. And while some attorneys might be satisfied to use a phrase like, “Developer will take reasonable care to ensure the confidentiality of the data,” or “Developer will follow information security best practices,” I far prefer to also see specific auditable practices described, such that a security auditor and/or judge can understand the specific business requirements and practices that were required and expected to be fulfilled by the vendor or developers. It sure beats paying attorneys to have the court hash out what “reasonable care” meant in this situation later.

So, I look for at least the following:

The app must:

  • provide appropriate strength authentication – to be specifically defined based on the application data level of sensitivity and confidentiality. (Some applications also require timeouts and re-authentication after periods of inactivity.)
  • use transport encryption using a valid TLS (which replaces SSL) certificate to protect the information (including login credentials) in transit, avoid man-in-the-middle-attacks and protect against session hijacks.
  • only request and use application permissions required to fulfill the app’s function, including but not limited to location, Internet use, and SMS. This information must be documented for use in the privacy policy.
  • only store data needed to fulfill the app’s function (storing and caching as little as needed, retained as short a time as possible). An inventory of this information and its retention must be documented for use in the privacy policy.
  • store personally identifiable information (PII) in an encrypted format and protect against data leakage to other applications.
  • not hardcode passwords or keys.
  • provide appropriate error handling such that sensitive information is never shown to the end-user and recovers to a known good state.
  • support a secure method of providing software updates.
  • provide a way to remotely wipe data from a lost or stolen device (depending on level of sensitivity of data).
  • log activity and data at a secure location, if required by the application.

There may be other requirements based on the application, for example to support PCI requirements, specific state laws, or other security business rule requirements. Once your contract addresses standards for auditing, you can also contractually require specific audit activities, both internal and third party, for monitoring and enforcement.

If you take the time in advance to ensure that good expectations are contractually set with app developers and vendors it will help ensure that appropriate information security measures are implemented and that there is a means to monitor for compliance. If you don’t add security expectations to your contracts, who knows what you will get?

About the author: Matt Cohen is Clareity Consulting’s Chief Technologist and leads its security assessment practice. Matt has spoken at many conferences, workshops, and leadership retreats around the country on security-related topics, and is a well-regarded real estate industry expert on real estate technology and information security. Clareity Consulting (www.callclareity.com) was founded in 1996 to provide management and information technology consulting to the real estate industry.