You can read this post in any language by clicking on this gadget =======>
(Puedes leer esta publicacion en cualquier idioma haciendo click en esta aplicación)
Can we trust the
programmers? / ¿Podemos Confiar en los
Programadores?
*You can read this article in Spanish more down below in
this same publish. (Puedes
leer este artículo en español más abajo en esta misma publicación)
"The biggest fraud in
code is not just a malicious line, but the blind trust that 'it will never
happen here.' Code without controls is an open invitation to disaster."
Efforts to prevent fraud
in access to information in the As400 ibm have been concentrated on using
mechanisms such as double validation (use of a token), authority levels, role
assignment, group profiles, among others.
It should be noted that
once inside the system, the danger has not ceased. It is important to direct
our gaze to the programming code developed by programmers.
There may be very
sensitive information embedded in the source code of programs that escapes the
naked eye.
In my experience, the use
of hard code in programs can be very risky if you do not have efficient audit
mechanisms to detect a fraud situation in time.
I heard of a developer who
didn't pay his phone bill for six months because he had hard-coded the program
with a zero balance to pay each time the read cycle read his phone number. Six
months later he was discovered and fired. The developer had been assigned to
the bank's direct debit payment system.
Direct debit payment
systems generate automatic charges against customer accounts for any of the
following services or recurring agreements that the customer wishes to pay
automatically: telephone, electricity, apartment rental, gas, subscriptions.
You might be wondering at
this point: does anyone still use hardcoding in programs?
Of course, hard code is
used in those variables or constants that range between two or three values
and beyond that it is not worth creating tables for those cases. A typical example refers to the status of a
data: Active/Inactive. This is obviously harmless.
It is important to check
if the source code exists:
-Variable names that do
not represent the data they contain.
Many times we take more
care of the forms than the content. They start with a certain letter that may
or may not have more or fewer characters, but we don't pay attention to whether
the name represents the data it contains.
Arrangements preloaded in
the source.
These are arrays whose
contents are loaded at compile time.(Time-compile Arrays)
It is necessary to check
if data of this type is inserted in these “pre-loaded” arrangements:
• Local telephone area
codes
• Gas, electricity
contract numbers
• Accounting accounts.
• Identification cards or
documents
Concatenation or
separation of characters.
You can hide hard code by
combining characters like:
Currency-country = 'U' +
'S' + 'D'
In general, code review
should be delegated to the technical leader.
Although each facility may
purchase or develop certain home-grown tools to review code and generate
alerts, these tools are not a substitute for human review whose vision is
interpretive and not mechanical.
Developing in Rpgle on an Ibm-i platform presents very
interesting challenges. In the next post we will review other topics about
RPGLE Ibm-I development
Until next time!
¿Podemos Confiar
en los Programadores?
"El mayor
fraude en el código no es solo una línea maliciosa, sino la confianza ciega en
que ‘aquí nunca pasará’. Un código sin controles es una invitación abierta al
desastre."
Se han concentrado
los esfuerzos para prevenir el fraude en el acceso a la información en el As400
ibm en utilizar mecanismos como la doble validación (uso de un token), niveles
de autoridad, asignación de roles, perfiles de grupo, entre otras.
Cabe destacar que una
vez dentro del sistema, el peligro no ha cesado. Es importante dirigir nuestra
mirada al código de programación desarrollado por los programadores.
Puede haber información
muy sensible inmersa en el código fuente de los programas que se escapa a
simple vista.
En mi experiencia, el
uso de código duro en los programas puede ser muy riesgoso si no se tienen los
mecanismos de auditoria eficientes para detectar a tiempo una situación de
fraude.
Conocí el caso de un
desarrollador que no pago su factura de teléfono durante seis meses porque había
colocado en el programa en código duro un saldo cero a pagar cada vez que el
ciclo de lectura leía su número de teléfono. Seis meses después fue descubierto
y despedido. El desarrollador había sido asignado al sistema de domiciliación
de pagos de la entidad bancaria.
Los sistemas de
domiciliación de pagos generan cargos automáticos contra las cuentas de los
clientes por alguno de los siguientes servicios o convenios recurrentes que el
cliente desea pagar de manera automática: teléfono, electricidad, alquiler de
apartamento, gas, suscripciones.
Se preguntarán en este
momento: ¿todavía alguien usa código duro en los programas?
Por supuesto que se usa
código duro en aquellas variables o constantes que oscilan entre dos o tres
valores y más allá de eso no vale la pena crear tablas para esos casos. Un ejemplo típico se refiere al estatus de
una data: Activo/Inactivo. Esto es obviamente inofensivo.
Es importante revisar
si en el código fuente existen:
-Nombres de
variables que no representan la data que contienen.
Muchas veces cuidamos
mas las formas que el contenido. Que comiencen con cierta letra que tengan o no
más o menos caracteres, pero no prestamos atención si el nombre representa la
data que contiene.
-Arreglos
precargados en el fuente.
Estos son arreglos cuyo
contenido se carga a tiempo de compilación.
Es necesario revisar si
en estos arreglos “pre-cargados” esta insertada data de este tipo:
·
Códigos
de área de teléfonos locales
·
Números
de contrato de gas, electricidad
·
Cuentas
contables.
·
Cédulas
o documentos de identidad
-Concatenacion o
separación de caracteres.
Se puede esconder código
duro concantenando caracteres como:
Moneda-pais = ‘U’ + ‘S’
+ ‘D’
En general se debe delegar
en el líder técnico la revisión del código.
Aunque cada instalación
puede comprar o desarrollar ciertas herramientas caseras para revisar el código
y generar alertas, estas herramientas no sustituyen la revisión por parte del
ser humano cuya visión es interpretativa y no mecánica.
Desarrollar en Rpgle en una
plataforma Ibm-i presenta retos muy interesantes. En la próxima entrega
revisaremos otros tópicos sobre el desarrollo en RPGLE Ibm-I
¡Hasta la próxima!
