Choosing a company to outsource your software development to has never been easy. And due to the current state of cybersecurity and privacy it is a much more daunting task.
Privacy requirements (legal and otherwise) and the potential fines and bad publicity, can bankrupt your company if your software is not properly developed and maintained.
In addition, the need for employees to work from home means your internal business applications must be available outside your office network where they are more vulnerable to hackers and other nefarious actors.
This is why security must be one of the prime considerations when procuring or developing software.
If you are in a business or industry that handles credit cards, or financial, health and other private information, the importance of understanding the law and security ramifications becomes even more important. As well as working with a partner that also understands those implications.
How The Wrong Software Contractor Can Be A Disaster
Here at Big Fish, a company that hired us to develop a mobile application had been using a different contractor to develop their backend API (the software that runs in the Cloud to perform the heavy lifting of the mobile app).
Since our client was not intimate with software development, they were unaware of how poorly the API had been developed. Engineering, design and development had been de-emphasized in favor of speed.
Our team discovered glaring issues with the other company’s API during our development of the mobile application. Worst of all, sensitive customer data was available without a password in plain-text on an AWS server.
Sensitive customer information was available without a password, on a public AWS server.
This project was subject to HIPAA (Health Insurance Portability and Accountability Act) compliance and when we explained that violating HIPAA regulations could make our client (not the developer) subject to fines up to $50,000 per violation (i.e. per customer record) we were asked to take over the entire project.
Unfortunately, it was clear that the other developers did not use best practices (or any practices) in software design or security. The only way the project could be saved was to throw out all the old code and start development of the backend API from scratch, wasting all of the previous development money.
How to Successfully Choose Your Software Contractor
When selecting a software development contractor you should be able to determine the level of security awareness they and their developers have by asking some basic security questions.
While these might sound like a word-salad of acronyms, bringing them up when discussing a potential contract should help elucidate their familiarity with basic security concepts.
These questions will also show that you are familiar with, and place importance on, security and privacy when your application is developed.
Questions to Ask Your Software Contractor
Here are some specific topics to bring up to make sure the contractor understands.
Frequently you will be initially contacted by a salesperson or sales engineer who is not generally expected to fully understand these concepts. Ask to have someone technical on their team join the call to ensure that their team does understand the following concepts.
1. Ask Your Potential Contractor About SQL Injection
After all these years, this is still the number one way to attack a system. Have them explain why their solution will not be vulnerable to SQL Injection attacks. They could mention using Data Access libraries that prevent this, and that all user input is sanitized in some ways. They should also be able to explain what SQL Injection is and what causes it.
The following four topics (CSS, CORS, CSP, CSRF) are only relevant if you have, or are going to have, a web-based application or website.
XSS – Cross-site-scripting
XSS stands for Cross-Site-Scripting. They should know that other than data sanitization, strict CORS and CSP settings (see below) are the primary tools for mitigating XSS attacks.
CORS – Cross-origin resource sharing
Cross-origin resource sharing is a way of limiting resource sharing and is one way to prevent the injection of malicious scripts on your website.
On a well-configured server the headers sent should be as restrictive as possible: only allowing the domains, methods, headers required, and avoiding the use of wildcards.
The contractor should be able to name at least a few of the standard CORS headers: Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Expose-Headers, Access-Control-Max-Age, Access-Control-Allow-Methods, Access-Control-Allow-Headers.
Some contractors will use a wildcard for their CORS settings which basically disables all security around resource sharing provided by the browser.
CSP – Content security policy
Content Security Policy describes which content (images, scripts, fonts, stylesheets, media, etc.) a site is allowed to load and from where.
You should make sure that the website they develop will have a strict Content Security Policy allowing only access to the sites that are absolutely required.
Make sure that the developer is not using wildcards, the “unsafe” keyword, or broad domain inclusions (facebook.com for example).
Preferably nonces or hashes are used to restrict scripts from foreign websites. This enforces that the script the developer thought they were including is the one that is actually included.
Lax settings (wildcards, using unsafe, and not using nonces) are less work for the developer, but open the user of the site up to the potential of various XSS attacks.
CSRF – Cross site request forgery
Cross Site Request Forgery is how hackers can gain access to accounts without a password.
This is done by stealing the user’s authentication token (after a user logs into a website an authentication token is used to ensure the user is who they claim to be) through a barrage of various tricks and hacking techniques.
Mitigating CSRF is complex, but when rolling out a site ensure that SameSite is set, Browser Only C and HTTPS cookies are enforced in the application.
2. Ask If and Why They Sanitize Data
Make sure that they can explain what Data Sanitization is and why it is necessary. They should know that all data is assumed to be malicious and not trusted.
Narrowly trusting data with an “allowed-list” is better than trying to weed out malicious data with a “block-list”.
Input escaping is important but only as effective as the library you use to perform that task. Roll-your-own implementations are recipes for failure.
3. Ensure Your Software Contractor is Familiar with OWASP
The contractor should be familiar with OWASP (Open Web Application Security Project) and its recommendations, as it is the gold-standard for understanding computer security.
4. Ask How Your Software Contractor Approaches User Authentication
If user login is required for your website, mobile application, or program, it is very important that authentication is done correctly.
The contractor should be able to explain how they plan to approach user authentication. If they do not mention a library or service that they intend to use you should be wary of them “rolling-their-own” authentication library.
5. Is PCI Compliance Important?
If your company is going to accept credit card payments, the developer will have to know about PCI Compliance. Even if you are using a third party payment processor such as Stripe or Square, your contractor should at least understand the basics of PCI compliance. They do not need to be an expert in this case.
If developing your own payment processing software, you can familiarize yourself with the PCI Self Assessment Questionnaire before interviewing any potential outsourcers to ensure you are up to speed in your requirements.
6. Is CCPA/GDPR Compliance Important?
If your website is accessible to California or the European Union you have to be aware of your legal requirements under the CCPA (California Consumer Privacy Act) or the GDPR (General Data Protection Regulation for Europe).
Whole blog posts (or books) could be written about this. Your lawyer, or other expert on the CCPA and GDPR can advise you.
7. Consider a Security/Code Audit
When having a software contractor develop your application for you, you are putting a lot of trust in that partner. Having a third party check over the source code can be expensive but it may save you both in the long run – and any reputable contractor should welcome such an audit.
The audit should obviously be performed by a party that has no vested interest in the failure of the project. And your company pays for their services, not your contractor.
If you’re interested in having Big Fish perform a security audit on software you already have, please reach out.
Conclusion
It should be easier to choose an outsourcing partner for developing software, but unfortunately, just like choosing a contractor in an unregulated industry, it is not.
Understanding more about what concerns security professionals, and what questions to ask your software developer, will make the process a little less daunting. It will also give you more tools in your arsenal to ensure a successful project.
