Secure Coding

A software security threat is anything or anybody that could harm your software system.

Software Security Threats

Architectural Design -> Detailed Design -> Code -> Hardware

There are various threats to software security. Each layer represents potential threats to software security.

To prevent hardware-level threats like natural disasters we can use cloud service.

About code-level threats, it has unintentional and intentional threats(malicious insider -> logic bomb). To prevent unintentional code-level threats:

• software security education and training is critical
• automation such as static and dynamic code analysis to identify vulnerabilities is the key.
• Once identified, the vulnerabilities need to be managed properly until they are mitigated satisfactorily.

To prevent intentional code-level threats, security oversight such as peer code review, job rotation and mandatory vacation is essential. Code-level threats are preventable, but requires a lot of resources to manage them properly.

To avoid threats at a detailed design level, adhere to the design patterns. And also, use the well-known

Requirements-Level Threats to Software Security

Collecting security requirements is a challenging task. You need expertise in Requirements Engineering as well as Information System Security which is often a rare combination.

The biggest problem is that customers and users also don't know what they want with respect to security. On the other hand, requirements engineers don't know what questions to ask to elicit security requirements. This combined lack of security expertise lead to missing or unidentified security requirements. These unaddressed security requirements in turn result in security vulnerabilities.

There could a few solutions to mitigate the requirements level threat to software security. The most obvious solution is to provide an extra resource to the team of requirements engineers. That is, provide a software security expert to work with the requirements engineers. This is easier said that done because of the monetary investment required.

A compromise could be the use of a comprehensive security requirements checklist. Each stakeholder, during the requirements process, can work with the checklist. Then the requirements engineers can ask intelligent questions while the customers or users can provide educated answers, Correcting the missing security requirements tends to be costly as in the case of any missing requirements. You might have to rewrite the entire software in the worst case scenario.

Understand an Attacker

The mind of an attacker or bad actor is foreign to many software developers. We spent our lives building things that we hope make the world a better price. I know that is kind of cliche, but the reality is most of us want to write code that improves our business or engages our passion. As such, we are builders and makers.

An attacker, however, has a very different mindset. They want to tear down what you have built. Now, their motivations can be all over the place, and while it is important to understand these motivations, the simple fact that they want to tear down what we build is very hard for many developers to grasp. So part of writing secure code is understanding the mindset of the attacker.

The first component is looking at why they want to break your code. Now, the reasons can be as many as the stars in the sky, but each attacker has a reason. Most attacks we hear about seem to be financial in purpose, but attacks happen for other reasons, things like political motivations, revenge, or building credit with other bad actors, to name a few. I have seen attacks happen because people want to build a reputation as a security tester. While I'm not a fan of this type of extortion, it currently is a reason why people are attacking systems. Now, regardless of the why, it's very beneficial to figure out all of the possible attack reasons. This why is critical because once you know why attackers might disrupt your application, you can start looking at the possible exploits that could exist in your system. This is really the heart of understanding the attacker.

As a developer, truly understanding an attacker is one of the most difficult challenges in my opinion. But once you start recognizing the mindset of an attacker, it opens up a wealth of new ways to protect your system. For instance, understanding motivations allows you to look at an attack vector in your application by thinking through the lens of the attacker.

Once you collect this information, you can start building an attack tree. The attack tree allows you to build scenarios based on probable attacks. With these scenarios, you can determine where you need to add testing, increase threat detection, or apply mitigating controls. Getting into the mindset of the attacker can be a huge undertaking. However, it can reap significant rewards to your organizations.

Web Client Server Interaction Code Issues

Input validation issues