Safe Development. Who pays the price?

In the daily lives of programmers, haste is the famous enemy of perfection, and the capitalist interest of companies to increase their earnings above all, makes the products not have an expected quality in the end, with a series of problems arising.

In college we learned that there is an equation for developing systems between:

- Term

- Quality and

- Cost.

If the development time is short, the cost will also be low, but it will not have quality. To maintain quality, you have to hire more people and increase the cost.

If you need more quality, you need to increase the term, and it can have a higher cost mainly in the development of mandatory systems such as the Nota Fiscal Paulista. If the system does not work on time, fines are imposed.

These items are related to each other, however when we say safe development, quality is chained to the extreme, that is, it increases the time and also the cost, but we can also guarantee a quality and safety that in other cases there would be no way to arrive.

A system prototype can be developed by the systems analyst saying what has to be done, the software has to go one step further than the risk analyst and raise the points to add security controls, and plan items to ensure that the developed system can have the expected quality and safety.

After the software is produced, the final version software passes through the risk analysis department again, and the code is inspected, checking for and raising security, support and attack issues that the code may suffer. Any mere error is returned to the programmer to generate knowledge, pointing out what has to be adjusted and the reasons.

Usually companies place all the responsibility for development on the programmer alone, and the systems analyst just says what has to be done, and in the end just does a simple test to see if what was asked for was actually done.

However, fine tests such as read / write speed, multiple access simulations and attack simulations are not performed, and the system can be very vulnerable.

When we say that a good system has a reasonable timeframe, we have to think and plan that we need time for development and extra time for improvements, because when we make any system, the immediacy is to make it work, and we do not provide attention to details, and these in turn are very dangerous if explored.

The coherent method would be something close to:

1. Development of the system to complete everything that is necessary, in its traditional time and deadline.

2. 20% of the time spent on development for analysis on improvements by the programmer who made it.

So you can guarantee at least one way to maintain quality, and after that, still go through the analysis of the specific sector and analyze if you are really safe, carrying out all possible tests.

Some items that should be raised when developing safely are:

Physical aspects:

1. Who will develop. (ethical and moral behavioral profile regarding information security).

2. What equipment will be used for development. (computer, scanner, supercomputer, etc.)

3. Who will request requests from the programmer (personally, via the system).

4. Location of the development area (another state?).

5. Raise the risks of those who would be interested in copying the developed system, competitors, etc.

6. Surveillance cameras on the equipment. (for analysis of possible unauthorized persons in the use of the equipment).

Logical aspects:

1. Connections for equipment used in development (Internet, CD-ROM, Pen-Drive, Wi-Fi, etc.)

2. Password protection and preferably hard disk encryption.

3. Protection against the most well-known attack methods. (SQL Inject, Cross-Browser injection).

4. Performance test of the system's functional mechanisms at peak usage (simulation test of several people using the system at the same time).

5. Test new users using the system. (If the interface and on-screen directions are understood to understand the functionality of the system alone, or with support and help content).

6. Portability test - Sometimes the software developed works on only one device, and on another it requires additional files or additional software updates. Tests must be carried out in the most diverse environments and in the most diverse conditions of use.

In terms of security and portability, Java has been highlighted in large companies, because the programming code is unique and applied to a virtual machine, called JRE (Java Runtime Engine), which is exactly an emulator of a computer with its processor and its memory area on an existing platform.

One of the major disadvantages of Java today is the lack of support from Oracle for the various security incidents that have appeared, the low speed of execution (there is no way to compare to the C language for example, which is also in turn portable) and the high hardware and server costs when using Java-based systems to scale and integrate systems.

In turn, the quality standard in typing Java programming, forces the programmer to use certain methods for converting values, dates, texts, floating point values ​​(with a comma), and of which, they spend more time, increasing automatically the term.

An inexperienced programmer when starting with the Java language, is already faced with the great load of technical concepts of the language in relation to the methods of converting values, which, in other languages ​​such as Visual Basic or .NET, are automatically identified according to use.

It does not mean that the Java language is the only one that can be secure in any way. Safe development applies to any programming language, including from the simplest to the most complex programming languages ​​for Artificial Intelligence (which I believe has to be extremely secure).

Safe development does not start with system programming, it starts with the initial idea of ​​system planning. You must plan the system and then plan your security controls.

The simplest security control that exists is the login and password, existing on all important systems.

But creating a password has to have criteria, a well-established policy and not limited only to the criteria for a new password (quantity, complexity), but also an awareness of the importance of the password for employees and keeping it safe. (Example of leaving the password written on post-it on the screen).

The security controls must exist and must be analyzed if they really correspond to the security standard, and not only superficial controls but also protection controls within the system, and for all these items, we know that it takes time.