8 steps to avoiding cyber hacking

A few months ago, my software team received the following request from an attorney: “Please create a form on my WordPress website so potential banking clients can upload scans of their documents.”

He thought it would be an improvement over the current process: Gmail.

A gentleman of a certain age, our client had no idea about the danger of his request, and of his current practice. 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.

Need for speed may make you bleed

Software development is efficiency-driven, needs-driven, feature-driven—and deadline-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.

The U.S. Department of Homeland Security says that 90% 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 for bank IT departments 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 my rule, use these essential guidelines:

1. Questionnaire for developers puts facts in black and white.

Send a cyber-security questionnaire to your software development agency. It can be as simple as providing the OWASP (Open Web Application Security Project) Top 10 Vulnerabilities list and requesting them to address each one, or explain why a certain item is not relevant to your project.

And you should also 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 control of access to sensitive data. You may want to confirm your vendor has appropriate roles-segregation practices.

(What do I mean by roles-segregation? Safe practices—the systems administrator doesn’t have the database password, and the database administrator doesn’t have the system’s password.)

Simply verifying up front that your development team follows best practices helps ensure security through the lifecycle of your product’s development.

2. Choice of platform is critical.

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.

3. Forms, passwords, and entry points—they can all invite in the bad guys.

Any place where a user enters data into an application represents a potential vulnerability.

Hackers can use these input opportunities to tunnel into 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)

4. Data collection and storage—be clear on what’s being protected and when.

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).

5. Integration points—“watch the gap.”

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 (internet protocol) whitelisting and VPN to VPN (virtual private network) mutually trusted connections can be employed.

6. HTTPS provides a second coat of security.

An ISP (internet service provider) can look at web traffic passing through its 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 website 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.

7. Temporary environments and backdoors—they sound as risky as they are.

In most software development, programmers set up non-production environments. These “dev spaces” are not behind firewalls; may not have encryption “turned on”; or may not 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.

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.

8. Testing, testing, and more testing.

General third-party quality assurance 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.

However, if organizations are reluctant to do general third-party quality assurance testing, 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, an ongoing affair. 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!