Stick with Security: Apply sound security practices when developing new products

Your company has a killer concept for an innovative app or a connected product and you’re in that initial blue-sky-and-whiteboard stage. You’ll have lots of opportunities to develop your distribution chain, create eye-catching ads, and start the social media buzz. But there’s one task that can’t wait. Now is the time to start with security – and that includes applying sound security practices when developing new products.

Tech experts will tell you it’s tough to graft security on after the fact. The sounder strategy – and the one more likely to win consumer confidence – is to build security in from the start. A look at FTC investigations, law enforcement actions, and the experiences that businesses have shared with us suggest the importance of starting with security in product development. Here are examples gleaned from those sources.

Train your engineers in secure coding.

The premium your company places on sound data security can’t be an “It goes without saying . . .” kind of thing. Say it clearly, sincerely, and frequently. Create a work environment where your staff is encouraged at every stage to factor security into product development. From concept to marketplace and beyond, articulate your expectation that employees keep security at the forefront of their decisionmaking. Ultimately, it’s the best strategy for your customers, your corporate reputation, and your profitability.

Example: A company launching a new software product emphasizes to its software engineers the importance of coding quickly to ensure that the product reaches the market as soon as possible – and the engineers meet in-house coding deadlines. But only after the product is in consumers’ hands does the company discover that the engineers have repeatedly created code that is susceptible to common, well-known security vulnerabilities for which there are available solutions. To correct the problem, the company has to implement an expensive after-the-fact fix. The more efficient – and ultimately, more cost-effective – practice would have been for the company to emphasize to its software engineers the importance of secure coding throughout the development process and to provide them with the training necessary to meet that expectation.

Follow platform guidelines for security.

Starting with security doesn’t necessarily mean starting from scratch. Every major platform has guidelines for developers to help keep sensitive data secure. Wise companies take that advice into account in designing new products.

Example: A company creates a mobile app for two different app platforms. Both platforms require data to be encrypted in transit and both have Application Programming Interfaces (APIs) that provide industry-standard encryption. By using the platforms’ APIs correctly, the company’s engineers can help keep data secure.

Verify that security features work.

Keeping an umbrella in your car is a prudent idea, but test it while the sun is shining. Don’t wait until a torrential downpour to find out that the ribs are bent or the handle is broken. In a similar vein, it’s wise to build security features into your products, but before you head to the marketplace, verify that they’re enabled and operating properly.

Furthermore, if you make any claims to consumers about the nature of the security your product provides, those representations must be truthful and supported by proof you have in hand before you start selling. “But we don’t make any security-related claims.” Maybe so, but are you sure? Under the FTC Act, companies are responsible for all representations – express and implied – that consumers acting reasonably under the circumstances take from a company’s marketing materials. That includes statements or depictions conveyed on TV or radio, in print, on your website, in online ads, on packaging, through social media, in privacy policies, or in an app store. Businesses are free to put security features front and center in their marketing materials as long as they honor established truth-in-advertising standards. So before you tout the security benefits of your product, verify that they live up to your advertised promises.

Example: A company that sells a household budgeting app runs an ad claiming that its product has “bank grade security.” But the company doesn’t have a written security program, doesn’t conduct risk assessments, doesn’t train its employees in secure information practices, and fails to implement other practices commonly associated with “bank grade security.” By making representations that are false or unsubstantiated, the company has likely violated established truth-in-advertising standards.

Test for common vulnerabilities.

Is there any way to make your product 100% hack-proof? Without reverting to the days of tin cans connected with string, the answer is no. But there are steps you can take to protect your customers from well-known vulnerabilities that are preventable with tried-and-true security tools. The good news is that many of those tools are free or available at low cost. Before you release your product, make sure it’s ready for prime time. Test it to ensure that you’ve built in defenses against known risks.

Of course, new threats emerge periodically, which is why security should be a dynamic process at your business. The security protocols you put in place for last year’s product may not be sufficient for Version 2.0. How can you keep your ear to the ground about defending against the latest threats? There is robust public cross-talk among researchers, tech experts, industry members, government agencies, and others committed to sticking with security. Follow their discussions on trusted websites, heed their warnings about new risks, and revise your design decisions accordingly.

Example: A 10K race application requires registrants to enter their name, address, date of birth, credit card number, and fastest 10K time. The data is stored in a SQL database that combines data from race events all over the country. The event organizers didn’t consult free resources to stay current on security risks, and never performed any code analysis or penetration tests to assess whether their application was vulnerable to a SQL injection attack. By staying current with free resources – for example, OWASP’s Top Ten Project – the event organizer could have reduced the risk of exposing racers’ personal information to unauthorized access.

Example: An app company regularly consults public resources like US-CERT for updated information about cyberthreats. The company realizes that the product it’s developing includes a security flaw some hackers have started to exploit. By catching the problem early and implementing an appropriate fix, the company has protected its customers and its reputation.

What can companies learn from these examples? Building security from the ground up is a cost-effective approach to innovation.

Next in the series: Make sure your service providers implement reasonable security measures