5 Practices That Will Help You Develop Secure Software

Software security is the number one priority these days. Considering the tremendous costs of a security breach or data theft, it’s in the company’s best interest to develop robust and 100% safeguarded software.

Even though there are many proven ways to secure your software, we can outline the 5 main practices that are obligatory for any software provider. Follow these secure software development best practices to ensure your software product is protected from possible internal and external threats.

5 Practices That Will Help You Develop Secure Software

Validate data input

Your software application may be collecting data from many external sources or clients. Hence, you need to validate data input from all external sources in order to eliminate a number of software vulnerabilities.

Here are some of the recommendations that OWASP provides for input validation:

  • Identify all your data sources and classify them (trusted and untrusted). Data from the untrusted sources must be validated.
  • Establish a centralized input validation procedure.
  • Parameterize SQL Queries.
  • A validation fail must result in input rejection.
  • Data should be encoded to a common character set before validation.
  • Data from redirects should be validated.
  • Data length and data range should be validated.
  • Implement additional controls in case there are any potentially hazardous characters that must be allowed.

Input validation helps ensure that only properly formed data enters the system. Note that input validation is not the main method of preventing an SQL injection or an XSS but it can play a big role in minimizing potential damages and eliminating vulnerabilities.

Control access to the app

It goes without saying that you should grant access to the app only to authorized users. As well, it is highly recommended to allow the least possible access to the least number of users in order to prevent any threat agents from entering the system. This relates to the Principle of Least Privilege described by OWASP. It states that only those permissions should be granted that are needed to complete the requirements and nothing more than that. 

Here is what you can do to ensure strict control over the access to the app:

  • Filter the requests made by third-party services via individual and dedicated accounts.
  • Enforce access controls for all app’s activity.
  • Restrict access to protected URLs, protected functions, app’s data, and services to authorized users only.
  • Ensure that server-side implementations and presentation layer representations match.
  • Limit the number of transactions that a single user (or a device) can perform within a certain time period.
  • Use encryption and integrity checking in case the state data must be stored on the client.

Error handling and logging

When a threat actor tries to penetrate your system, the first thing they do is attempting to acquire information about the target, such as the name and version properties. Hence, you need to have a proper error handling procedure in order to prevent hackers from acquiring any information about the system. Here are some helpful practices:

  • Always trap and release error conditions.
  • Never disclose sensitive information in error responses (i.e. system details, session identifiers).
  • Implement generic error messages.
  • Free the allocated memory when an error condition occurs. 

It is also important to have consistent and well-organized application logging. Application logs provide an immense amount of valuable data for such procedures as identification of security incidents, the establishment of baselines,  defense against vulnerability identification, and many others. The practices to follow include:

  • Implementation of all login controls on a trusted system.
  • Constant monitoring of logs for any irregularities or intrusion.
  • Logging both successes and failures.
  • Limit access to the logs to authorized users only.
  • Establish a mechanism to conduct log analysis.
  • Utilize cryptographic hash function for validating the integrity of log entries.

By logging both successes and failures, you will be able to better understand the performance of your system and therefore will be able to timely identify any alerts or potential risks.

Design with security in mind

There is a term “secure by design” and it implies building secure software from the start and not adjusting it once everything is built. Such an approach is very beneficial as it allows to create secure and robust product architecture from the start. This, in turn, significantly minimizes the possible threats.

The first step of secure design development will be the identification of the data that the app will process. Then, based on this data, the developers will come up with the corresponding security controls. For example, compare a banking application and a blog on WordPress – the first product handles much more sensitive information than the second one and will need stricter controls.

As well, the developers need to understand the possible types of attacks and to take preventative measures against them. Note that there is always a possibility of a staff member or a programmer to intrude the app so take precautions against that as well.

The design of the system architecture also has to be security-centered. A developer should think about every feature of the app and estimate whether it is:

  • Surrounded by safe processes?
  • Possible to be attacked and how exactly?
  • Default? If yes, how can it be protected?

Here are the main security principles stated by OWASP that relate to design security:

  • Minimize the surface area for the attack: meaning, every new feature added to the app is an additional area that can be targeted by a hacker. If the feature is absolutely needed, minimize access to it only to the authorized users.
  • Establish secure defaults so the users’ authentication and logins are as secure and verified as possible.
  • Follow the principle of the least privilege as discussed above.
  • Follow the principle of defense in depth: there should be multiple security controls for approaching risks in different ways.

Other recommendations include avoiding sophisticated architecture in order to minimize the risks and always double-checking the validity of any third-party services being used.

You might find this article interesting:

  • Vulnerability Assessment vs Penetration Testing

Secure the database

The database is probably the most vulnerable part of the application and therefore it should be guarded at a double rate. However, the rules for database security are not as complex as they may seem. The basic principles are: never grant write access if read access is enough, make sure the variables are strongly typed, ensure that all queries are prioritized, and use stored procedures as much as possible.

These rules are considered the basic ones for securing the database. However, there are additional practices recommended by OWASP:

  • Use input validation and output coding.
  • Grant the lowest level of privilege to the app when it accesses the database.
  • Always use secure credentials for database access.
  • Close connections as soon as possible.
  • Either remove or change the default database administrative passwords.
  • Do not hard code the connection strings within the application.
  • Disable all default accounts that are not needed and disable all unnecessary database functionality.

Follow cryptographic practices

It’s common knowledge that encoding is one of the most efficient ways to secure the data. Hence, when designing a system, follow the cryptographic practices that will help keep the data safe and secure:

  • Store the keys in secure key vaults.
  • Make sure that cryptographic models fail securely.
  • Ensure that master secrets are protected from unauthorized access.
  • Implement all cryptographic functions on a trusted system only.
  • Ensure that deployed cryptographic modules comply with FIPS 140-2 (or an equivalent standard).
  • Establish a policy for managing cryptographic keys.

Summary

The abovementioned practices are some of the basic practices of secure coding. However, this is just the top of the iceberg and there are many more practices to follow. We highly recommend checking out the OWASP security coding guidelines for a more detailed explanation of each practice. By acknowledging and implementing secure software development best practices, you can be sure that your system is safely protected from possible threats.

Being a software development provider with over 12 years of experience, SoftTeco always follows security coding principles and security standards established by the industry when creating software applications. In this way, we can always guarantee that our clients do not experience any security-related issues and that their applications function as intended. 

Want to stay updated on the latest tech news?

Sign up for our monthly blog newsletter in the form below.

Softteco Logo Footer