Actualidad

28/05/2020

/ , , , , , ,

Temas para reflexionar… con pensamiento positivo

En esta red profesional nos esforzamos por transmitir positividad pero no hay que obviar que podemos tener momentos complicados. No es malo compartir que nos toca luchar cada día por mantenernos ocupados para conseguir alejarnos de pensamientos negativos y superar la ansiedad producida por la situación actual. Asumir abiertamente que estamos obligados a redoblar esfuerzos y reinventarnos – en muchos casos a empezar desde cero – porque se han producido cambios que se quedarán con nosotros de forma definitiva afectando de lleno a paradigmas que teníamos establecidos y totalmente interiorizados.

Hace unas semanas veía una conversación de Rafael Nadal donde afirmada “No quiero nueva normalidad, quiero la normalidad de antes”.

Me sentí optimista ante la posibilidad de recuperar algo tan lejano en estos días como esa “normalidad de antes”. Y frente a ese anhelo, un entorno que nos habla de un futuro incierto y difícil en muchos ámbitos.

Tengo la fortuna de estar rodeado de un equipo increíble, en un proyecto profesional apasionante que consigue mantener mi motivación muy alta. Podemos decir orgullosos que estamos teniendo la agilidad y la pizca de suerte necesarias para afrontar estos meses con el mínimo impacto en nuestros proyectos.

En tiempos de cambio es cuando más se crece, cuando más se aprende

A pesar de ello, la incertidumbre que nos rodea nos exige más porque en tiempos de cambio es cuando más se crece, cuando más se aprende. Un aprendizaje forzado que afecta a una serie de temas sobre los que reflexionar y construir una nueva versión mejorada de nosotros mismos. Unos ejes que considerábamos diferenciales en el modelo de empresa de ITERIAM – tanto en nuestra cultura interna como de cara a nuestros clientes – pero que de forma general debemos replantearnos.

El primer eje y el más cercano desde mi posición de responsabilidad es el liderazgo: ¿cómo ejercer un liderazgo cercano en momentos de lejanía? ¿qué modelo de liderazgo necesitamos ahora? ¿cómo hacemos partícipes a nuestros equipos de la necesidad de cambios? ¿y cómo lo trasladamos a nuestros clientes?

Como comentaba con anterioridad, aquellas empresas que han demostrado agilidad para adaptarse han sido capaces de afrontar los retos de este nuevo escenario. En nuestro caso somos nativos digitales y tenemos definido un marco de trabajo que nos permite acompañar a nuestros clientes en sus proyectos de transformación digital de forma ágil, pero ¿somos ágiles también en todos nuestros procesos internos? ¿seríamos capaces de cambiar nuestro porfolio de productos y servicios de la noche a la mañana? ¿tienen nuestros ejecutivos mentalidad de startup? ¿y nuestros empleados?

Y hablando de empleados y talento, ¿seremos capaces de sostener en el tiempo esta necesidad autoimpuesta de completar nuestros conocimientos? Aunque ya teníamos una cultura de aprendizaje online y una amplia oferta formativa digital, soportada entre otras opciones en OpenWebinars, ¿seguiremos todos tan concienciados en la necesidad de estar siempre actualizados? ¿cómo tutelamos esa adquisición de nuevas capacidades en la dirección correcta? Y de nuevo, ¿cómo hacemos partícipe a todo el talento disponible en nuestros equipos ante esa necesidad de cambios?

Por último el teletrabajo como quinto eje. En ITERIAM ya teníamos implementada esta posibilidad en la mayoría de proyectos en los que participamos, pero su aplicación intensiva por la pandemia impacta en todos los ejes antes mencionados de forma evidente y nos obliga también a repensar el concepto de oficinas y puestos de trabajo.

Cinco temas sobre los que reflexionar para construir una versión mejorada de nosotros mismos

Temas sobre los que todas las empresas y organizaciones públicas, independientemente del sector de actividad, deberíamos estar actuando ya. Temas que nos mantienen ocupados, que muchas veces nos crean más dudas que certezas, sobre los que vamos sacando conclusiones parciales y que suponen un reto continuado que debemos afrontar con pensamiento positivo para encontrar de nuevo una forma diferente de hacer las cosas.

Actualidad

25/05/2020

/ , , , ,

Recomendaciones para desarrollo de código seguro

Actualmente, tanto los clientes como los desarrolladores de software estamos muy preocupados por la calidad del código, pero parece que se sigue pesando más el cumplimiento de las fechas de entrega y el ajuste en el presupuesto.

Tan evidente es que en el documento de cumplimiento del servicio (ANS) que se firma en muchas colaboraciones se recogen todo tipo de variables, KPIs y sus correspondientes penalizaciones en el caso de incumplimiento, pero pocas veces se miden o se cuantifican criterios de seguridad.

En el mundo Agile en el que se definen las historias de usuario, se establecen los sprints y se hacen las fases más difusas y menos largas, en ningún momento se tiene en consideración la securización de las aplicaciones de forma explícita. Se diseña, construye, prueba y se entrega, pero ¿y la seguridad?, ¿en qué fase entra? ¿se considera incluida en la parte de construcción? ¿no debería ser una parte de cada una de las fases?

El diseño de aplicaciones debería abordarse siempre bajo criterios de seguridad, siguiendo unos estándares de construcción seguros y finalmente se debería probar la seguridad de cada una de las funcionalidades desarrolladas en el sprint correspondiente.

En este punto debemos reflexionar si en nuestro caso tenemos en cuenta la seguridad: ¿existe un checklist al respecto que validamos antes de entregar y/o recepcionar los desarrollos o mientras que cumplan con las funcionalidades definidas y se entregue en los plazos establecidos entendemos que es un buen trabajo?

No se necesita ser un experto ni tener un equipo de hacking ético para definir una línea base y poder testar la seguridad de nuestros desarrollos. Mi recomendación para definir correctamente esos mínimos debemos tomar como referencia OWASP – Open Web Application Security Project.

OWASP es una fundación sin ánimo de lucro cuyos miembros trabajan a favor de la seguridad del software en general. Cada año analizan los 10 principales riesgos que se producen en las aplicaciones.

El informe de 2020 nos recomienda tener en cuenta los siguientes aspectos:

1. Inyección – Injection

Consiste en la ejecución de comandos o querys directamente desde la propia aplicación. Supongamos que tenemos el típico método de acceso a una aplicación con los campos usuario y contraseña ¿Qué ocurriría si la consulta a la base de datos no tuviese mecanismos de validación o estuviese mal construida y permitiese meter en el campo usuario el siguiente texto?

' or "=';

La consulta siempre saldría positiva y accederíamos a la base de datos.

2. Pérdida de autenticación – Broken Authentication

Englobaría a todo lo referido en el tratamiento y técnicas de protección de credenciales y cómo las implementan las aplicaciones. Es decir, la utilización de canales no cifrados para transmitir credenciales (https), no proteger debidamente las credenciales de usuarios, mala gestión en la recuperación de credenciales, exposición de los ID de sesión (Cookies de sesión).
Un ejemplo de esto podría ser

xxxx.es/url/control?action=profile&ID=vH]OzN8F8_==

en el que el ID va directamente en la URL.

3. Exposición de datos sensibles – Sensitive Data Exposure

Se produce cuando un usuario puede comprometer los datos debido a una mala u obsoleta encriptación de los mismos. Tiene puntos de conexión con el reglamento general de protección de datos (RDPD). Un ejemplo claro puede ser guardar en un archivo de configuración el usuario y contraseña en “texto plano”.

4. Entidades externas XML – XML External Entities (XXE)

Antiguos procesadores de XML permiten la especificación de una entidad externa, una URI sin referencia y evaluada durante el procesamiento del XML. Es decir, que al parseador de XML se le envía un XML con funcionalidades añadidas. Ejemplo de esto podría ser:

]>&entidad;

5. Pérdida de control de acceso – Broken Access Control

El control de acceso determina qué usuarios se comunican con qué sistemas y recursos. Esto implica que los usuarios no pueden actuar fuera de los permisos previstos.

Un ejemplo de esto es la configuración incorrecta de CORS que permite el acceso no autorizado a una API, o acceder a una API sin control de acceso mediante el uso de POST, PUT o DELETE.

6. Errores de configuración de seguridad – Security Misconfiguration

En este apartado se incluiría todo aquello que se relaciona con el despliegue de una aplicación y su entorno. Es decir, permisos, configuraciones por defecto, actualizaciones librerías, sistema operativo, servidores de aplicaciones, puertos, servicios, cuentas de usuarios, manejo de errores, etc.

7. Cross-Site Scripting – Cross-Site Scripting (XSS)

Este ítem considera la posibilidad de modificar valores que la aplicación web usa para pasar variables entre dos páginas.Los ataques XSS se basan en la inyección de scripts maliciosos que se ejecutan en el navegador del usuario. En muchos casos, el usuario ni siquiera es consciente de lo que está ocurriendo. Los tipos principales de ataques XSS son:

  • Reflected: Normalmente se basan en conseguir que el usuario siga un link o complete un formulario malicioso, aunque aparentemente normal. (ejemplo: Phising)
  • Stored: El código malicioso se inyecta en algún elemento persistente, como una base de datos, de manera que se consigue que se ejecute en el navegador del cliente al recuperar la información almacenada.

8. Deserialización insegura – Insecure Deserialization

Estos defectos ocurren cuando una aplicación recibe objetos serializados dañinos y estos pueden ser manipulados por el atacante para realizar ataques de repetición, inyecciones o modificar sus privilegios de ejecución. En el peor de los casos, la deserialización insegura puede conducir a la ejecución remota de código en el servidor.

Los datos serializados (que el atacante envía al servidor de consumo de servicios) hacen que se ejecute, al momento de deserializar, un código arbitrario (malicioso).

Código con los datos originales:

a:4:{i:0;i:23;i:1;s:5:"Admin";i:2;s:4:"user";i:3;s:32:"fkg498ok32ñ5p0fw48";}

Código modificado en el que se le conceden permisos de administración a un usuario externo, siguiendo la misma serialización que el original

a:4:{i:0;i:12;i:1;s:7:"ITERIAM";i:2;s:5:"admin";i:3;s:32:"ufr53psm56115ld357";}

9. Utilización de componentes con vulnerabilidades – Using Components with Known Vulnerabilities

Este tipo de ataque ocurre cuando se emplean librerías o frameworks que contienen vulnerabilidades. Un ejemplo de esta vulnerabilidad es la no actualización de los plugins de WordPress.

10. Recolección de logs y monitorización insuficiente – Insufficient Logging Monitoring

No es en sí una vulnerabilidad de las aplicaciones, pero si hace que la detección y las acciones de mitigación sean más dificultosas y lleven más tiempo.

Con estos 10 puntos, podemos definir nuestra línea base de actuación en temas de seguridad, y a partir de ella, hacer un checklist e incorporarlo como tarea en nuestro desarrollo Agile.

¿Qué valor añadido le daría a un cliente el saber que el desarrollo que ha contratado o realizado, además de cumplir funcionalmente con las especificaciones, cumple unos mínimos de seguridad?

Y a partir de aquí, ¿cómo seguimos? Con nuestra línea base definida, con nuestros mínimos de seguridad implementados, ahora toca ir evolucionando y madurando de forma incremental como en cualquier otro sistema de calidad que tengamos en nuestra empresa.