Cyber Security Rules For Insurers
By Anna Murray, Author of The Complete Software Project Manager
A few months ago, my software team received the following request from an insurance company executive: “Please create a form on my WordPress website so potential clients and others can upload scans of sensitive documents.”
He thought it would be an improvement over the current process: Gmail.
Our client had no idea about the danger of his request. When we spoke to him and cautioned him to stop using Gmail to transfer sensitive documents, he immediately took action.
This vignette may be an extreme example. But it illustrates the essential tension between software development and cyber security. Software development is efficiency-driven, deadline-driven, needs-driven and feature-driven. Achieving a first-mover advantage is critical, and in certain industries it may trump all other concerns.
Obviously these drivers are in direct conflict with cyber security considerations.
According to the U.S. Department of Homeland Security, ninety percent of cyber-attacks originate on the application layer. Therefore, we must do a better job at developing less vulnerable software.
Here is one key rule to follow:
Include cyber security thinking from the planning stage of software development all the way through launch. Your cyber security team will be an invaluable ally here. If you don’t have one, consider outsourcing.
To follow the rule, use these essential guidelines:
- Questionnaire for developers
Send a cyber-security questionnaire to your software development agency. It can be as simple as providing OWASP Top 10 Vulnerabilities list and requesting them to address each one, or explain why a certain item is not relevant to your project.
Include an essay question. Ask potential firms to comment briefly on their cyber-security experience and practices.
Depending on your business and risk considerations, you may need to expand this document to include hiring and firing practices, background checks, and controlling access to sensitive data. You may want to confirm your vendor has appropriate roles-segregation practices. Which means the systems administrator doesn’t have the database password, and the database administrator doesn’t have the system’s password.
Simply verifying upfront that your development team follows best practices helps ensure security through the lifecycle of your product’s development.
-
Choice of Platform
More enterprise-y development products tend (tend is the operative word) to be more secure. If your software is being built on SharePoint or the Adobe platform, security features in the framework itself are more likely to be handled for you.
Such is not the case in the open-source community. Hundreds of thousands of community-built modules exist for WordPress, Drupal, and RoR.
The problem: Enterprise-grade systems can cost multiples over open-source. Further, open-source frameworks have been a godsend in terms of truly achieving feature-rich software and rapid application development.
If you are using an open-source framework, make sure your development team is taking security into consideration. What plugins are they using? Have they been thoroughly vetted by the community and reviewed as secure?
Further, smaller businesses must remember to update open-source platforms like WordPress for the latest patches. This step is simple and often forgotten.
-
Forms, passwords and entry points
Any place where a user enters data into an application is a potential vulnerability. Hackers can use these input opportunities to tunnel in to deeper layers of the software. Or, they can access the accounts of your users through tricky combinations of social engineering and brute-force password cracking apps that are freely available.
Take a look at your forms, logins, and password-recovery practices. Best-practice guidelines are readily available. For things you don’t catch, a security test will help.
(See #8)
-
Data Collection and Storage
Understand the sensitivity of the data you plan to collect. Is it personally identifiable information (PII) such as emails, phone numbers, and dates of birth? If so, you must plan to encrypt the data in transit (as it’s being transmitted from the web form to the database), and at rest (when it is simply stored in the database waiting for retrieval).
-
Integration points
Integration powers most modern software development. An integration point is where your application exchanges data with another system, such as when you retrieve a user’s account information from your CRM and use it to show a profile page on your website.
For example, to execute an integration, you might create something called a webservice between the two systems, and each system has an “endpoint.”
But how do you know if the authorized system (CRM) is the one accessing your endpoint?
To ensure security, methods such as IP whitelisting and VPN-to-VPN mutually trusted connections can be employed.
-
HTTPS
An ISP (internet service provider) can look at web traffic passing through their network and tell what sites a user has visited. They can (and do) sell that information to advertisers. If the ISP is hacked, that information is available to the hacker.
Putting your site on an HTTPS url gives your users an added layer of protection. The pages visited on the site are encrypted against snooping by anyone trying to intercept the traffic, and so is any data exchange between your application and your users.
- Temporary environments and backdoors
In most software development, programmers set up non-production environments. These dev spaces are not behind firewalls, may not have encryption “turned on,” or have whitelisting active. Further, your software vendor may have been given temporary access to a company’s database for the purposes of setting up an integration. It is a good idea to treat these environments with care and apply security best practice there as well. Hackers don’t really care if it is the production environment or the test environment that they got access to. Once in, they are likely capable of navigating to any environment they want.
Finally, once your software is launched, all these temporary environments must be retired and private access revoked. In short, from a security standpoint, decommissioning a dev environment (hardware, software, credentials, data) is as critical as launching your production application.
-
Testing
General third-party QA testing itself is one of the most overlooked areas of software development. “Our internal team will test the software,” is still commonly heard at companies.
Needless to say, if organizations are reluctant to do general third-party QA, they are even less likely to do security testing.
Both are essential. A general QA effort will ensure the functioning and stability of your software. Added testing for security vulnerabilities will validate that all your planning efforts have paid off in a secure software product.
You probably plan to introduce new features on your application. This means testing must be incorporated as a maintenance task. There are automated tools such as BurpSuite to test basic code vulnerabilities. You may also want to include a by-hand test at least quarterly to ensure ongoing security. Remember, hackers are constantly probing for vulnerabilities and developing exploits. Don’t let your application become an easy target!
*******
