Back to blog

The safety of software development

In programming, security is a set of strategies, good practices, and procedures that prevent unauthorized access to organizational assets such as computers, servers, networks, and data. It maintains the integrity and confidentiality of sensitive information, blocking access for unauthorized individuals.

Here are some basic methods of enhancing software safety that we will discuss today.

Classic security frameworks.
Threat modeling.
Project templates.
Examples of vulnerabilities.
Sources of information about vulnerabilities and good practices.

Classic Security frameworks. Let us begin with a set of security frameworks that serve as guidelines for understanding how the topic of security should be approached.

The first security rule is called C.I.A. Triad and it might bring some other associations to mind but it stands for Confidentiality, Integrity, and Availability.

Confidentiality means an organization tries to keep its data private or secret.

Typically, this involves ensuring that only authorized individuals have access to specific assets and that those who are not authorized are prevented from obtaining access.

Integrity In everyday usage, refers to the quality of data being whole or complete. It also means that no data is tampered with and the data is accurate, authentic and correct.

Availability means that the data is accessible which means the system, network or application is running providing intended functionalities

Triple A (authentication, authorization and accounting)

Authentication.

Authentication in simple terms provides a way of identifying the user. Usually, it is done by having them enter a valid username and password.

Authorization.

Following authentication, the user must be authorized to perform certain activities. After logging in to a system the user might try to issue commands. The authorization process determines whether the user has the authority to do so. In a nutshell, authorization is the process of enforcing policies by determining what types or qualities of activities, resources or services the user is permitted.

Accounting.

Accounting measures the resources the user consumes during access. For example, the amount of system time or data the user has sent and received during a session. Accounting logs session statistics and usage information and is used for authorization control, resource utilization, trend analysis, etc.

So, now we have the security frameworks we can use but we still need to answer several important questions proposed by threat modeling frameworks.

FQF- Four Questions Framework/ Adam Shostack’s questions.

What are we working on?

What can go wrong?

What are we going to do about it?

Did we do a good (enough) job?

Another approach is presented by the STRIDE framework. Stride stands for:

Spoofing

Tampering

Repudiation threats

Information disclosure

Denial of Service

Elevation of privileges

Spoofing occurs when an unauthorized individual like a hacker pretends to be another person assuming the identity and information in that identity. Phishing is an example of this fraud.

Tampering with data occurs when data is changed without authorization. For example, it might be done through changing a configuration file in order to gain control over a system.

A repudiation threat occurs when an illegal or malicious operation is performed on a system that lacks the means of tracing the culprit. Repudiation attacks are relatively easy to execute on e-mail systems, as very few systems check outbound mail.

Information disclosure- also known as information leakage. It happens when information is revealed to unauthorized users. an error message revealing database information.

Denial of Service (DoS) occurs during a DDoS attack that denies access to authorized users.

Elevation of privileges. An unauthorized or authorized user is able to access resources that should not be accessible for this user’s permission level.

Now let us discuss project templates that are invaluable when designing a project.

The economy of project design should be taken into account as the first step.

A project should be simple. This means we should not try to reinvent the wheel and try to keep things simple.

Project transparency. A well-thought security system should not be built on solutions that seem to be unnecessarily complicated and in fact easily broken. A security system should not be a burden to the process.

The least privileges rule.

Access privileges should allow a user access to assets appropriate to the user’s function in an organization and the activities performed.

In other words, the safest strategy is to grant privileges needed for the job to be done.

The least information rule.

A system should gather as little personal information about the user as possible. In the event of a security breach the less information an organization gathers, the better. The European GDPR directive also prohibits entities from using and storing personal data.

Allowlist instead of Blocklist

Having an allowlist is a better idea than having a blocklist mainly because it is more difficult to define the undesired parameters than to define the desired ones.

Avoid predictability

It does not only refer to using obvious passwords.

For example, avoid giving users subsequent IDs and generate random ones instead.

Now, we can enumerate some examples of vulnerabilities that were exploited in the past and are important lessons to be learned.

Injection vulnerability

Using double dashes allows inserting another command.

INSERT INTO Students (name) VALUES (‘Robert’);
INSERT INTO Students (name) VALUES (‘Robert’); DROP TABLE Students; –—’);
INSERT INTO Students (name) VALUES (‘Robert’);
DROP TABLE Students; --’);

Heartbleed bug

This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet.

hbmessage *hb(hbmessage *request, int *message_length)
{
int response_length = request->payload_length + sizeof(hbmessage);
hbmessage* response = malloc(response_length);
response->type = heartbeat_response;
response->payload_length = request->payload_length;
memcpy(& response->bytes, & request->bytes, response->payload_length);
*message_length = response_length;
return respon


Finally, we can focus on sources of information about vulnerabilities and good practices that are widely considered as great sources of security wisdom.

Here are some of them.

CERT Coding Standard

The CERT Secure Coding Team describes the root causes of common software vulnerabilities. The ways of exploiting these vulnerabilities and their potential consequences and secure alternatives you can use.

An example of CERT Standard for C coding.

Designing Secure Software

Loren Kohnfelder

The book begins with a discussion of core concepts like trust, threats, mitigation, secure design patterns, and cryptography. The second part, perhaps this book’s most unique and important contribution to the field, covers the process of designing and reviewing a software design with security considerations in mind.

OWASP Top Ten

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

https://owasp.org/www-project-top-ten/

Microsoft Security Development Lifecycle

The Microsoft SDL introduces security and privacy considerations throughout all phases of the development process, helping developers build highly secure software, address security compliance requirements, and reduce development costs.