Currently there are methodologies and best practices, such as SCRUM, DevOps, etc, for a fast software development, where the objective is to release the software as soon as possible, in order to meet delivery dates and to make the budget investment, focusing on the functionality of the final product. However, these models in the Software Development Life Cycle do not pay enough attention to the Applications security and leave aside the vital consideration that must be taken into account in order not to put the organization's assets at risk.
The developers must understand the most common errors in programming, since they play a crucial role in the construction of software and in the good or bad use that can be given to the applications, the bugs can represent vulnerabilities and these can be taken advantage of by diverse malicious entities that put at risk the organization and the confidence in our product. These bugs are introduced mainly during the development stage and are documented under various investigations of large organizations, IEEE, OWASP, SANS.
Failure to develop in a secure manner leads to bugs that can become vulnerabilities and represent a risk within an organization, the most common development errors are defined as The Seven Harmful Domains, which are the categorization of the most common errors that exist in the Software Development Life Cycle, or SDLC for its acronym in English, and that must be contemplated during every phase of the SDLC, which I describe below; adding to them an eighth domain that is not part of software development but contemplates everything that can affect the proper functioning of our product.
One of the most persistent vulnerabilities in software is caused by metacharacters, alternate encodings, numeric representations where inputs are not properly checked and the user is trusted to use them correctly. All input must be sanitized and validated. The vulnerabilities that this generates are: "Buffer Overflows", "Cross-Site Scripting" attacks, "SQL Injection", etc.
This is a contract between who makes the request and who responds, however, the problem begins when the contract is violated. The one who makes the request makes it incorrectly, violating the functionality contract. The problems caused by this contract violation are: "Heap Inspection", "Directory Restriction", "Unchecked Return Value", etc.
At this point what it should be understood is that a pseudo-random number does not support cryptographic attacks, also storing passwords in plain text or encrypting them is a security risk or not having a correct access control can lead to the execution of paths. It is possible to have several security controls, but this does not ensure that our software is not vulnerable or not being exploited for different purposes.
This concept refers to distributed computing that is based on state and time. Current systems offer multi-core, multi-cpu or distributed systems, in which two events can take place at the same time.
It is important to be aware that what is executed and what actually happens are very different. Events occur by occupying variables, file systems and above all changes in memory, cache, wherever information is stored. Failure to control these events can lead to authentication failure problems, where a session could be stolen, temporary files could be accessed or even privilege escalation could be achieved.
Uncontrolled errors are common. There are two ways to create a security error. Errors not correctly controlled and to create errors that provide information. The correct control of errors from the development of the software is of vital importance since these can provide useful information or be exploited as pivots by an attacker.
A low code quality can produce unexpected behaviors, which for an attacker is an advantage that can be exploited to compromise the system.
Strong boundaries must be created. This means that validated and non-validated information must be differentiated, as well as what a user can see and what he/she should not see. Failure to encapsulate information correctly means a risk to security and privacy.
This includes everything that is outside our code and it is crucial to consider it since they are part of our product. Within this point we consider bad configurations of the server itself, compiler, network, etc. To be able to evaluate our environment it is necessary to perform a correct threat modeling in order to protect our assets.
The most common errors in code development that represent a security risk are called the Common Core Error Enumeration or CWE. Here are the 25 most common ones, ordered from most to least impact on security.
As we have seen, a great effort is required for code analysis and vulnerability detection, so it is of utmost importance to mention the Challenges that are presented for this important task.etección de vulnerabilidades, por lo que es de suma importancia mencionar los Retos que se presentan para esta importante tarea.
The need to perform a code analysis has already been taken into account by various authorities in different sectors such as the banking sector, the energy sector, governments, etc., which require that software must be developed in a secure manner and that it must comply with security standards. The security standards, to mention a few, are: PCI, FISMA, MITRE CWE, SANA 25, OWASP, etc.
The importance of developing secure software goes beyond compromising our information. Users trust the functionality of the product, so a quality and reliable product must be developed. There have been software failures in various technologies throughout history, which demonstrates the need to develop a secure product. The following cases can be mentioned:
- May 1-2015 when a "buffer overflow" is detected on a Boeing 787 aircraft, causing the system to shut down, despite being in flight. The first solution is to restart it every 248 days.
- 2018 in Mexico, an attack is carried out on SPEI and 300 million pesos are stolen. They take advantage of the platform's functionality.
- February 2018 Bangladesh, more than 80 million dollars are stolen through the Swift platform. The bank's environment was not properly protected or adequate threat modeling was not performed.
- February 2019 vulnerability is detected in the TLS V 1.3 protocol that allows listening traffic. The attack exploits a side-channel leak through the cache access times of these implementations to break the RSA key exchanges of the TLS implementations.
It is clear that not developing software in a secure manner can be very expensive if we do not develop it in a secure way.
Performing vulnerability remediations to a product that has already been released and probably was not contemplated within the project's budget, thereby reducing the expected profits. The following graph shows the cost, the economic figures are representative, of making these remediations according to the phase in which our software is.
We can observe that during the development phase is where more bugs are added to the code and it is here where it is more convenient to fix them, but in the final stages it raises the cost a lot, so I suggest integrating during the Software Development Life Cycle a tool like Checkmarx, which specializes in the static analysis of source code in order to identify vulnerabilities and thus reduce security risks in any organization. The integration of this tool to our SDLC helps us to automate the hard work of analyzing our code and not only that but we will have a Secure Software Development Life Cycle, or S-SDLC, and if our organization is a mature one then we will not only have a DevOps but now we will have a SecDevOps.
I have used this specialized tool to carry out the challenging job of analyzing source code for security vulnerabilities. It is also important to note that Checkmarx is a leader in this category in the Gartner quadrant. The Checkmarx module for this task is called CxSAST, Checkmark Static Application Security Testing. The goal is to secure the code from the start
Checkmarx goes beyond analyzing the correct code syntax and following good development practices, it analyzes the flow of information that our code performs and on these flows it performs the vulnerability analysis.
Checkmarx supports several programming languages, just to mention a few:
|
• Java • C# • JavaScript and commonly used frameworks • Node.JS and commonly used frameworks • VB.NET • ASP • VB6 • PHP |
• C/C++ • Apex and VisualForce • Ruby • VBScript • Perl • HTML5 • Python • Groovy • Scala |
Mobile Development Languages • Android (Java) • Objective C • Swift • PhoneGap and commonly used frameworks. |
One of the features that makes Checkmarx different is that it offers the best place for vulnerability remediation. This helps us to save a lot of time in the repair and makes our life easier by indicating where to repair the code and fix the bugs at the source of the vulnerability. The effort to perform a scan is minimal since you practically only have to upload the code and Checkmarx will analyze it, requires no external dependencies to configure, and is easily integrated with various IDEs.
Checkmarx analyzes 200 thousand lines of code per hour approximately, depending on the hardware where Checkmarx lives, which demonstrates its great ability to analyze huge projects looking for weaknesses that we have created unintentionally, or have we?
The code can exist in several repositories or File Systems. Checkmarx can go after it in order to automate and facilitate vulnerability scanning.
Since Checkmarx is so easy to use, it is able to integrate with agile and DevOps development models, and we can have a SecDevOps very easily if we already have a DevOps model, which helps us to meet our deadlines not only of a functional product but also of a functional and secure product.
In order to adapt to agile development models, Checkmarx offers remediations of detected vulnerabilities, we can copy and paste the remediation, and Checkmarx even explains why it is a vulnerability.
Checkmarx has been developed to facilitate the security of our developments and make our life easier, because we can assign and track vulnerabilities to be fixed by a specific developer, we can even create our own custom scanning rules, that's how flexible Checkmarx is.