4 Security Concepts Any Software Developer Should Understand


Security is something that developers tend to not think about in software that they write in the early phase. Security gets put off as something to address when there is time and guess what that almost never happens. As a result, applications are often the weakest link in a company’s infrastructure.

 

Developers don’t need to be security experts to build secure software. Developers need to know and understand some key security concepts that way they are aware of it when they are coding. When a developer is aware of security it usually starts to show in their code. So, let’s look at 4 security concepts that software developers should understand.


 

CIA Triad

 

The CIA triad is made up of Confidentiality, Integrity, and Availability. For the most part, security activities exist to support and protect data that falls under one or a mixture of the three. The three acts as the base concept for other key security concepts.

 

Confidentiality

 

Confidentiality means that data should be made available only to those authorized to view them. Authentication, encryption, authorization are some key security concepts that branch off confidentiality.

 

Authentication

 

Authentication is the process of a user proving they are who they claim to be. Usually, this can be done in a few ways such as by something the user knows (pin or password), something the user is (biometrics), and something the user has (token).

 

Authorization

 

Authorization is the process of determining if the authenticated identity is allowed to perform an action or see some data. An example is logging into an online shopping platform doesn’t give you access to see other people’s orders. You are only authorized to view your own orders.

 

Encryption

 

Encryption prevents eavesdroppers from seeing the real data that is either at rest or in transit. This means sensitive information such as login credentials, account numbers, or social security numbers are not readable by someone that is listening on a connection.

 

Integrity

 

Integrity ensures that the data can only be modified by those authorized to change it. In addition, integrity ensures that the data you see is the real data that has been tampered by someone else. Some key security concepts that stem from integrity are accountability, authorization, and hashing.

 

Accountability

 

Accountability is the ability of a system to know who changed what and when. It ensures that a change is detected and can be repaired if necessary. So, in the unfortunate case that someone unauthorized was able to modify data, it is tracked.

 

Authorization

 

Authorization ties with confidentiality, but it also impacts on integrity. It is important to have a system that can identify identities that are authorized to see the data (confidentiality) as well as change the data (integrity).

 

Hashing

 

Hashing involves passing data through a one-way function. It results in something easy to compute, but given the output, it is near impossible to figure out the input. If even a single bit changes for the input, the hash output will be entirely different. This allows you to compute a new hash for an input and if they match then you can be assured that the data have not changed.

 

Availability

 

Availability is the assurance that the system and its data will be accessible to authorized users when needed. This process ensures your website is up when users need it or your API service is available when your clients call it. Some major topics related to availability are failover, resiliency, and disaster recovery.

 

Failover

 

Failover is achieved through redundancy. For example, in the case of a loss of service, another instance of that service can instantly take over.

 

Resiliency

 

Resiliency is a system’s ability to withstand attack. An attack can be a DoS (denial of service) or another type of attack. Regardless of the attack, the system should not simply go down without a fight.

 

Disaster Recovery

 

Disaster recovery plans assist in the recovery of a system when a major disaster does occur. As a developer, you may not create the plans, but you should know what they contain.

 

Least Privilege

 

Least privilege is the concept that users should only have the access needed to do their job and no more, and only if the duration they require to have access. Users in the context of least privilege don’t mean only individual users; it also expands to an application.

 

For example, is your application connecting to a database using an account that has superuser access? If so, this can lead to possible exploitation. If your application has a SQL inject vulnerability and it gets exploited, the attacker can do all sort of terrible stuff to your application’s database or another application’s tables.

 

A more secure approach would be to create an ID for your application and only grant permission to that ID that it absolutely needs to do its work. So, if the application’s ID has read and write access, then your tables won’t be destroyed or another application’s table.

 

Cryptography and Cryptographic Agility

 

Any software that deals with sensitive data such as PII (personal identifiable information), PHI (protected health information), or anything that is aligned to industry standards like HIPPA (health insurance portability and accountability act) will involve cryptography. When it comes to extremely sensitive data, it is important for the developers to understand which algorithms to use as well as which are stronger than others.

 

In addition to cryptographic algorithms, cryptographic agility is even more important in designing secure software. Cryptographic agility is a design principle that states that software is free to change its cryptographic algorithms whenever it is necessary. This requires you to think during the planning phase before any code is written.

 

When developing for cryptographic agility, there are a few things to consider. If you are using a configuration file make sure to use the least privilege and protect it so that only administrator can have access. Carefully plan out your database column sizes for encrypted or hashed data. If your database was built many years ago and you are using MD5 (128 bits) to hash data then you can’t upgrade to SHA-256 or SHA-512 easily.

 

Complete Mediation

 

Complete mediation is the principle that ensures there are no potentially sensitive actions can be done without verifying that the user is authorized for the action. For example, you need to enter an admin password to install a program or delete a file in a protected directory and you will need to do this every single time. If you rename a protected file, you need to enter your admin credentials. Then if you rename the same file again, you will need to provide your admin credentials again. You get the idea.

 

This principle is important when you are building a web application using REST (Representational State Transfer) services that are being consumed by a client. Consider the case where a developer might assume that the URLs for the REST services are not published anywhere so only the UI application will know. Then as long as the UI application knows who you are, the REST service doesn’t need to authorize each call.

 

This would be problematic because someone can easily obtain the URLs that the UI application is calling. They can use a browser’s view network traffic feature or a proxy application such as Fiddler or Charles. Once someone knows the URLs they can craft their own requests and send them to the REST URL without the client at all.

 

In such a scenario is where complete mediation comes into play. Each call to a REST endpoint needs to be authorized. The server should always perform authorization check before doing any work from the client because the client can be easily manipulated.

 

It is best to architecture code in such a way that all calls are passed through a single authorization module that can’t be bypassed. For example, to reach the business logic the code must pass through the same authorization module regardless of where the source is coming from.

 

 


 

I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.

 

To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.


About Steven To

Steven To is a software developer that specializes in mobile development with a background in computer engineering. Beyond his passion for software development, he also has an interest in Virtual Reality, Augmented Reality, Artificial Intelligence, Personal Development, and Personal Finance. If he is not writing software, then he is out learning something new.