In programming, security is a set of strategies, good practices, and procedures. These procedures ensure the safety of software development by preventing unauthorized access to organizational assets such as computers, servers, networks, and data. Security 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 software security should be approached to ensure the safety of software development.
These frameworks provide a structured foundation that helps development teams identify risks, enforce controls, and build systems that are resilient against attack. By grounding your approach in established software security principles from the outset, you create a far stronger baseline than any reactive measures applied after the fact.
CIA Triad
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.
Authentication in simple terms provides a way of identifying the user. Usually, it is done by having them enter a valid username and password. Weak or improperly implemented authentication is one of the most common software vulnerabilities, making it a critical area to get right from the start.
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. Misconfigured authorization controls are a frequent source of software vulnerabilities that can allow users to access resources or perform actions well beyond their intended permissions.
Accounting measures the resources the user consumes during access. For example, it tracks the amount of system time or data the user has sent and received during a session. Accounting logs session statistics and usage information for authorization control, resource utilization, trend analysis, and maintaining overall software security. Thorough accounting practices also play an important role in detecting unusual patterns that may indicate exploitation of software vulnerabilities, enabling teams to respond before significant damage occurs.
What is threat modeling?
To ensure the safety of software development, we can use security frameworks, but we still need to answer several important questions proposed by threat modeling frameworks. Threat modeling is a core component of software security, helping teams identify and address potential risks early in the development process.
Four question framework
The following four question framework, also known as Adam Shostack’s questions, can help to organize threat modeling and serves as a practical starting point within a secure software development life cycle:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good (enough) job?
By working through these questions at each stage of development, teams can embed security thinking into the process from the outset rather than addressing it as an afterthought. A principle that sits at the heart of any secure software development life cycle.
STRIDE framework
Another approach is presented by the STRIDE framework. It utilizes a mnemonic to systematically uncover vulnerabilities before code is written and STRIDE stands for:
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 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 (non-repudiation means proving an action occurred). Repudiation attacks are relatively easy to execute on email systems, as very few systems check outbound mail.
Information disclosure also known as information leakage, this is a significant software security concern. It happens when information is revealed to unauthorized users, such as an error message exposing database details.
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 with software security in mind.
The first step is considering the economy of project: keeping the architecture as simple as possible. This means we should not try to reinvent the wheel and try to keep things simple for the safety of software development. These principles align closely with what a secure software development life cycle promotes — building security in from the start rather than treating it as an afterthought.
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, ensuring the safety of software development.
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.
Examples of vulnerabilities
Now, we can enumerate some examples of vulnerabilities that were exploited in the past and are important lessons to be learned for the safety of software development. Understanding these vulnerabilities is also a key reason why adopting a secure software development life cycle is so valuable. It provides a structured approach to identifying and addressing such risks at every stage of a project.
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; --');
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
Key Safety Of Software Development Insights
Finally, we can focus on sources of information about software 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’s 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.
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.
Final Thoughts
Hopefully, this article helps you decipher the software security riddles that arise in your next project. By applying these frameworks and best practices within a secure software development life cycle, you can approach security as an integral part of building reliable, trustworthy software. Rather than something bolted on after the fact.
Key Takeaways for Secure Development
Foundation First: Ground your strategy in the CIA Triad (Confidentiality, Integrity, Availability) and the AAA framework to ensure robust authentication and accounting.
Proactive Threat Modeling: Use STRIDE and Adam Shostack’s four-question framework to identify vulnerabilities during the design phase, long before code is written.
Minimalist Design: Adhere to the principles of least privilege and least information to reduce the attack surface and ensure compliance with standards like GDPR.
Continuous Learning: Regularly audit your project against the OWASP Top Ten and CERT Coding Standards to mitigate common risks like injection and encryption flaws.
