alphaspirit - Fotolia

Lo básico Póngase al día con nuestro contenido introductorio.

Las tres acciones para darle seguridad al código

“Hay riesgos y costos en un programa de acción –pero son mucho menores que el costo resultante de la inactividad confortable”: John F. Kennedy

There are risks and costs to a program of action –but they are far less than the long range cost of comfortable inaction. — John F. Kennedy

Me lo encontré de camino a un evento y nos desviamos por un café. Es un desarrollador y de broma (aunque era en serio) le dije: a ustedes no les interesa la seguridad cuando codifican. "La verdad no, cero prioritario", respondió.  Y siguió confesando: "es más trabajo para nosotros, si de por sí ya estamos saturados de prioridades, mejor fijarse en lo único importante que es: el programa debe jalar; debe cumplir con lo solicitado por los usuarios. ¿Y sabes? Los usuarios no piden seguridad, quieren que funcione".

Fue muy honesto. Me queda claro: no son quienes desarrollan los que pensarán por sí solos en la seguridad. Sólo cuando están obligados por alguna política, el usuario u otra "motivación jerárquica" meten el tema de protección a su código. Pero  la seguridad no les quita el sueño. Creo que para ellos es un tema de "cumplimiento".

¿Entonces cómo dar seguridad al código de la organización? He aquí tres iniciativas:

1.- Políticas. Con ellas obligamos a los desarrolladores a seguir criterios de revisión de código. Puede ser tan simple como: "si está expuesto a internet debe ser verificado y solo tener hallazgos de baja criticidad".  Me gustaría decir: esto puede prosperar sin una política de por medio, pero no, este es el tipo de cuestiones que debe ser "a fuerzas". De otra manera, como dicen los mismos programadores, será ‘cero prioritario’.

2.- Herramienta. Revisar código es algo complejo en el área de seguridad. ¿Por qué? Quien haga la revisión debe de saber cómo codificar, sobre seguridad y cómo ambas convergen para entender la manera de atacar a una aplicación. El primer reto será hallar el perfil adecuado.

Cientos o miles de líneas son analizadas en un extenso tiempo sin una herramienta. Imaginemos la tarea de revisar miles o cientos de miles de líneas de código. Una herramienta es imprescindible. Ella debe soportar los lenguajes de la empresa y producirá un reporte con el cual el personal de seguridad lo analizará y determinará la criticidad de los hallazgos. Luego convocará a los codificadores para juntos entender los hallazgos y solucionarlos. Al menos los severos deberán solucionarse antes de poner la aplicación en producción.

Los códigos fuentes no son estáticos. Sufren cambios por diversas causas, y en cada cambio el proceso de revisión de seguridad debe de iniciarse de nueva cuenta.

¿Qué tipo de programas deben de ser revisados desde el punto de vista de seguridad? Idealmente todos, pero al menos los que están expuestos a internet u otros con riesgo.

3.- Consecuencias. Santo Tomás necesitó ver para creer. No podemos esperar más de los desarrolladores. Requieren ver las consecuencias de sus actos para hacerlos reflexionar. ¿Por qué no de vez en cuando tomar uno de sus desarrollos inseguros, crear un exploit y mostrarles el ataque? Y decirles: ustedes serían los responsables por ignorar la seguridad. La gente necesita ejemplos para comprender mejor la importancia de participar en pro de la seguridad en aplicativos.

¿Saturarlos con más acciones? Claro, podría listarles 20. Pero al menos tomemos estas tres básicas y si las hacen ya estarán por encima del promedio. Es más, hagan solo las dos primeras. Podría decir lo importante que es tener integrada a la seguridad dentro de la metodología de desarrollo de la compañía. Pero eso y otras acciones son el siguiente paso en el camino a la incrementar la madurez de seguridad informática de una organización.

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close