Why Every Developer Should know About Security?

Introduction

Developers need to understand how to prevent threats. But this can be challenging because developers think about building things, not breaking things. Learning to think about how someone might break the system means being aware of all the things that could go wrong with the software—including the components and dependencies in the?software supply chain , and any known vulnerabilities.

Developers also need an understanding of what security testing is and what it can and can’t do. They also need to understand what happens during security testing—what the test is looking for, how vulnerabilities are prioritized, and how issues are mitigated.

When developing an application, you should consider things like:

• What should this application do?
• How should this application behave?
• What are my inputs? (form fields, query parameters, local storage, embedded css, etc)
• What are my outputs?
• What potential weaknesses could be taken advantage of by a hacker?

Developers can also benefit from understanding the various security technologies and processes, and how they relate to their organization. For example

• Software composition analysis (SCA )?identifies open source software used in a codebase to evaluate security, license compliance, and code quality. It can be used before ever deploying an application and pinpoint the source of known vulnerabilities.
• Static application security testing (SAST )?analyzes source code during the build process or even directly from the developer’s integrated development environment (IDE), and can identify lines of vulnerable code. Like SCA, SAST can be used before the application is deployed. After several cycles of fixing issues identified during SCA and SAST, the application can be deployed for IAST and DAST testing.
• Interactive application security testing (IAST )?generally takes place during the test/QA stage of the SDLC and catches problems as soon as code is changed and recompiled. It helps identify vulnerabilities in real time.
• Dynamic application security testing (DAST )?examines an application in the production system or in the text/QA system. It identifies vulnerabilities at runtime, but doesn’t identify the lines of vulnerable code.
• Penetration testing (pen testing)?is an authorized simulation of a variety of types of attacks when the software is ready for production and deployment. It can help organizations identify weaknesses in the system.

5 Security Concepts Every Developer Should Understand

A constant danger in software development is developers that do not or will not understand how to secure their software.

The current state of technology has created an environment where applications are constantly being attacked. Applications are often the weakest link in a company’s infrastructure.

That means that it is unprofessional for a software developer to build software without understanding how to secure it.

Some may feel that learning how to develop good code is hard enough and that there’s no time to learn about security , too. But the fact of the matter is that secure code is good code. A bug in production could cause big issues. An attacker using a vulnerability in your software to steal sensitive data is just as bad (and in some cases worse).

Write code with this in mind:

Secure code is good code.

Developers don’t need to be security experts to build secure software . There are experts available to provide guidance when needed and in tricky situations, but every developer should strive to learn key security concepts.

#1: The CIA Triad

One of the core security concepts that forms the foundation of any security activity is the CIA triad. This is not a clandestine government organization; rather, it’s the acronym for the triad of Confidentiality, Integrity, and Availability.

Confidentiality

Simply put, confidentiality means that data should be made available only to those authorized to view it. The key concepts that branch off of confidentiality are authentication, authorization, and encryption.

Authentication is the process of a user proving that they are who they claim to be within a system. This can be done in three ways: by something you know (password or PIN), something you have (token), or something you are (biometrics). Only data classified as public should be available to those who haven’t been authenticated. Authentication is a basic need of almost every website.

Authorization is not the same thing as authentication. Authorization is the process of determining if the authenticated identity is allowed to perform an action or see a piece of data. For example, logging into your bank’s website doesn’t give you access to see every account balance in the system. Instead, you are authorized only to view your own account balances.

Finally, encryption is a major method of ensuring confidentiality. When data is at rest or in transit, encryption can prevent any snooping eyes from seeing the real data, thus protecting its confidentiality.

Integrity:

While confidentiality ensures that data is seen only by those authorized to see it, integrity ensures that data is changed only by those authorized to change it.Integrity is ensuring that the data you see is the real data and hasn’t been changed in transit or at rest by someone else. The key concepts branching off of integrity are hashing, authorization, accountability, and auditing.

Authorization is discussed above in connection with confidentiality, but it also impacts on integrity. It is important for a system to have the ability to determine which identities are authorized to see the data (confidentiality) as well as change the data (integrity). If an unauthorized party is able to change data, a failure of integrity has occurred.

Accountability is the ability of a system to know who changed what and when. While it is preferred that unauthorized changes are not made to your data, accountability helps if that unfortunate event does occur.

Non-repudiation helps facilitate auditing at a later date, if that is required for compliance purposes.

Hashing is a tool that can be used to ensure integrity. Hashing involves passing data through a one-way function so that the hash of the data is easy to compute, but given the output, the input is near impossible.

Availability

Availability is the assurance that the system and its data will be accessible to authorized users when needed. This process ensures that your website is up when users need it, or your REST service is available when your clients want to call it. Denial of service (DoS) and distributed denial of service (DDoS) attacks are attacks against availability.

#2: Least Privilege

The next key security concept for developers is least privilege. Least privilege is the principle that users should only have the access needed to do their job and no more, and only for the time it is required for them to have this access.

#3: Complete Mediation

Complete mediation is probably a term you don’t hear too often. But this is definitely a concept that developers should understand, especially if you are building REST services consumed by a client-side framework, like AngularJS.

#4: Cryptography/Cryptographic Agility

Cryptography is highly relevant to any software that holds sensitive data, PII, PHI, or anything that is beholden to industry standards such as PCI-DSS or HIPAA.

Since this data is extremely sensitive, it’s important for developers to understand which algorithms to use in which situation, as well as which algorithms are stronger than others. Cryptographic algorithm choice is just the beginning when it comes to good secure software design. Cryptographic agility is even more important when designing secure software.

#5: Threat Modeling

The final concept every developer should understand is threat modeling. I did a post a while back on this topic, so refer to that post for a more detailed discussion. Instead, I’d like to talk more here about why it is important for developers to understand threat modeling for security purposes.

As a software developer, it is your responsibility to make sure that your software, or the pieces of it that you write, are not used to cause harm to your or your client’s organization; you must ensure that your software is secure.