Custom software development is gaining traction for businesses of all sizes. So are cyber attacks. In 2021, 64% of companies experienced at least one type of cyber attack. Moreover, in March 2021 alone, over 20 million records were breached.
A simple search on cybersecurity statistics paints a grim picture: the number of attacks is increasing and the attackers are getting better at what they do. Of course, this doesn’t mean that businesses should stop developing technology.
But it does mean that we should all be more careful with the security aspects of software development projects.
At Far Reach, our specialty is developing custom software systems. This requires keeping an eye on system security. These are a few of the critical security elements we emphasize in our software development process. We’re not cybersecurity experts, so when we need help, we can and do call on trusted partners like ProCircular.
But we stay updated on the basics to make sure security is built into every custom software system we create.
Looking to roll out a secure software system?
Download our software rollout plan template.
Secure Software Development Practices
Just as there is no one software solution that fits every business, there is no one security solution that fits every software system. So our first step is:
1. Understanding the Use Cases of the Software
There are different security approaches when you build an internal application and when you build a customer-facing app. Luckily, this first step is covered by our software development process itself—we don’t start building something until we know who’s going to use it and how.
Understanding the use cases also helps you identify some of the bigger risks the system might face. For instance, medical databases are a preferred target for hackers, and they require extra security layers by law.
As part of our process, we work with clients to understand the different roles in their company. We can then lock down the software so each role has access to perform only the necessary operations. We run access scenarios during our testing process, as well, to ensure users only have access to what they should—and more importantly, don’t have access to what they shouldn’t.
It’s easy to get lax on user access. For example, we have a client that thought they had user access controls, but when we dug deeper, it was just “security through obscurity.” Basically, they thought, if the user doesn’t know the page exists, then it’s secure, right? Wrong. Hiding pages doesn’t account for users that share links with one another. Locked-down user-based permissions are the way to go for security.
2. Security Beyond Compliance
Speaking of sensitive industries like healthcare, complying with established regulations is a must. It goes without saying that all our software is compliant with the current regulations imposed by the various agencies. But we work to go beyond that, based on the client’s, users’, and system’s needs.
For example, one of the goals of a recent encryption enhancement for a client was to further comply with HIPAA rules. We use encrypted buckets in Amazon S3 cloud hosting to store their documents but it didn’t seem like that was enough. After further research, it turns out that AWS offers a Business Associate Addendum.
Under the U.S. Health Insurance Portability and Accountability Act of 1996, a HIPAA business associate agreement (BAA) is a contract between a HIPAA covered entity and a HIPAA business associate (BA). The contract protects personal health information (PHI) in accordance with HIPAA guidelines.
This Addendum applies to the Far Reach account. Therefore any encrypted bucket we create under our account would be HIPAA compliant. While we mostly use Azure cloud hosting, which is also compliant, this extra security is helpful for clients on AWS.
Regardless of the hosting environment, we try to watch for upcoming changes in regulations and standards so we can get ahead of enhanced security. We have several tools in our toolbelt that help us with system security and monitoring for issues.
- The Basics - We do the basic 101 security best practices like deploying SSL Certificates on all systems
- Static Code Analysis - We use Whitesource and Dependabot during our build processes, and we then review the results on a scheduled basis
- Infrastructure - We use Armor and Microsoft Defender to ensure our environments are secure
3. Database Encryption
Database encryption is a fundamental security layer. You need to make sure that your sensitive information is protected and that no one has access to information they don’t absolutely need to access.
For a medical software system, for example, doctors obviously need access to the patients’ medical history. However, the administrative staff may not. They could get by just with access to a patient’s payment history, insurance information, or consultations history.
The more people who have access to sensitive information, the more likely a breach becomes. Once again, as custom software developers, it’s essential to understand use case details like these, so we can create and assign the proper roles and permissions.
4. Enhanced Access Control
Weak passwords are also a great way into a system for cybercriminals. While it may be frustrating to create passwords that are 12+ characters long, have a special character, lower and uppercase letters, and numbers, it is still the first line of defense in application security. You can do everything correctly on the backend, but one user error can open a system to vulnerabilities.
You can’t expect users to use top-notch security practices on their own. Some of the access control layers that can be implemented to enforce user-level security include:
- Multi-factor authentication
- Strong password requirements
- A secure password recovery method
- Regular password change enforcement
- Close management of inactive or suspended accounts (e.g., those of former employees)
It’s frustrating for users to try to remember secure passwords. To encourage strong password use for internal users, you can help make it easier by implementing LastPass or another password manager. This beats the “write passwords on a sticky note,” the “keep an excel file of passwords,” and the “store passwords in an open notes document” methods—by far.
Security Policy Implementation Doesn’t End with the Initial Development Phase
The cybersecurity landscape changes at an incredibly fast pace. When attackers refine their methodologies, your security policies need to change too. Keeping your software and dependent components up to date is one of the most important investments for security. We often integrate open source and paid components, so we apply major security updates, and then on a yearly basis, we update systems to be on the most current version.
Constant monitoring and updating of your security policies is mandatory—even after the initial development phase is complete. Obsolete security practices are an attacker's favorite way to gain easy access to valuable data.
One way to monitor your software’s security performance is through application insights. Azure’s solution monitors performance, errors, anomalies, dependencies, and usage, so you can always have a bird’s-eye-view a click away.
Want to talk more about security best practices in software development?
Reach out any time!