Application security failures ought to have been reduced to virtually nil by now. After all, the Open Web Application Security Project is 16 years old and still going strong; the Web Application Security Consortium had a great run from 2004 to 2011; and dynamic application security testing tools have been a commodity for nearly a decade.
Yet, here we are in 2018 cooling off from the latest buzz surrounding a serious application security blunder. Thousands of military and government employees, and the bases and buildings from which they operate, were identified from GPS system data shared via integration between their fitness trackers and the well-known fitness application, Strava.
With the volume and ubiquity of bugs and flaws, application security is not a luxury item meant to be practiced only by regulated industries, such as financial services.
The responsibility for application security falls upon multiple parties: developers — regardless of the industry they work in — and the implementers and users of applications.
Developers have a responsibility to design and build secure software. Implementers have a responsibility to select applications that have met appropriate security requirements and validate that they work as intended. In their personal lives, users have a responsibility to defend their right to privacy and to choose not to use applications that violate that right.
What Went Wrong in the Strava Heat Map Case
In the case of the Strava debacle, we saw a complete breakdown in all three areas of responsibility. To start, Strava made at least a couple of mistakes: The so-called anonymous sharing of a user’s GPS data was on by default and opting out was not a simple exercise. This privacy-impacting feature should have required opting in and been off by default. Strava also failed to redact military bases from their maps and images like Google Maps does, for example.
In this case, the military played the role of the enterprise, and it failed in its responsibility to protect its users from themselves by omitting critical security education and guardrails for the safe use of fitness trackers when they handed them out in 2013 and 2015. The Chinese military observed the threat of fitness trackers and mobile GPS data and banned them in 2015. This was reported around the world at the time.
Lastly, we must consider the users: soldiers. Their profession is based on preserving the security of our nation and allies, yet they are just as willing as you and I are to ignore threats to their own security and privacy in the name of social networking. At a minimum, one would think some of the joggers and cyclists in the military who use Strava have IT security jobs that involve assessing apps used by soldiers for threats.
Let’s break down some things to watch out for in each area of responsibility.
How Developers Can Design More Secure Apps
There are several things developers can do to enhance applications security.
Practice security by design. Use capabilities such as threat modeling to help ensure you’re designing secure software from inception. Ask yourself, if I were an attacker, how could I abuse this data-sharing application programming interface (API)? If I were a user, how might I erode my privacy by sharing my location with third-party applications and services? One way to see early success with threat modeling is to partner with your security team, particularly if they have experienced offensive security staff. These folks live to break things, so use their talents to improve your own applications.
Never hardcode passwords or other secrets into your application. Passwords, API tokens, access and secret keys, transport layer security (TLS) keys for certificate pinning, and the like should never be stored in plaintext within source code or configuration files. Support single sign-on and multifactor authentication. Encrypt secrets and other sensitive data using industry-standard, strong encryption and limit access to back-end systems based on the principle of least privilege.
Make security part of the user’s experience. The National Institute of Standards and Technology released Digital Identity Guidelines in 2017 that suggested disposing of password complexity, rotation and history rules. Comprehensive planning is required to successfully make this shift. For instance, user interface improvements that visually guide users into creating an appropriately long and conceived password should be included, such as directions to use a minimum of 20 or so characters and at least four sections of at least five characters with no more than two repeating characters. Password manager-friendly coding, or integration, is also advised. Make it simple to use a password manager to help eliminate password reuse and encourage the use of more complex passwords as an option.
What Implementers Can Do to Boost App Security
Implementers also have some core responsibilities related to enterprise app security:
Select and implement solutions with features that protect users and data. If the solution doesn’t support features such as multifactor authentication out of the box, make sure it supports Security Assertion Markup Language, so it can be integrated with an identity platform that integrates with or supports multifactor authentication.
Don’t choose solutions that fail to demonstrate a commitment to application security. Perform penetration testing on applications prior to purchasing if possible; otherwise, request an attestation, test results or other evidence that application security testing has been performed.
Securely implement applications and monitor them for potential attacks and misuse. Just monitoring for performance and availability is not enough. Educate users on the safe use of applications as well.
Users Play a Key Role in Keeping Data Secure
App users also must take steps to ensure that their data is as secure as possible.
Vigorously defend your privacy when you’re outside of the enterprise. Review application security and privacy settings regularly. In the office, utilize the available security features, like multifactor authentication. Alert technical staff when security concerns arise.
Choose secure passwords. Do not reuse passwords online. Use a password manager to manage passwords and other secrets. Use multifactor authentication whenever possible.
Use caution when utilizing applications on open, unencrypted wireless networks. If the application does not provide secure transport of its own, your information may be sent over the air in cleartext.
In today’s information security climate, everyone shares some responsibility for application security. The greatest responsibilities lie with the people who should have learned tough security lessons by now — if not in their own experiences, through reading about the misdeeds of others in the media.
Following some of the guidance is a step in the right direction, but many more resources are only a search engine query away. Regardless of the roles we play, please join me in making applications more secure for everyone, starting today.