• Author / Uploaded
• jhhenaor

• Categories
• Contraseña
• Clave (criptografía)
• Cookie HTTP
• Transport Layer Security
• Seguridad y privacidad en línea

Citation preview

Análisis y Construcción Criptografía Jaime Henao, Luis Ardila, Fabio Castro, Amaury Gamarra, Jaider Contreras Escuela de Ciencias Básicas Tecnología e Ingeniería Colombia [email protected], [email protected], [email protected], [email protected]

Universidad Nacional y a Distancia “UNAD” following is the insecure passwords, in this case it was Escuela de Ciencias Básicas,The Tecnología e Ingeniería Resumen— En este documento se registra el análisis y estudio de found that with the use of some specialized software can Colombia alternativas de solución a los inconvenientes identificados en la fase decrypt some passwords, which is no less worrying. However, dos de este momento. Alternativas de solución para: ataque de colisión, contraseñas inseguras y captura de cabeceras con Live http headers.

everyday experts devise better ways to encrypt passwords and users to collaborate try creating passwords for stricter parameters.

El primer caso en estudio es el ataque de colisión, caso que se presta a confusión pues como se detecta es en el uso del generador de firma digital openssl, se cree que este último software es el responsable de ese error. Pero analizado el caso se encontró que en realidad el error proviene del uso de una función de encriptación, la MD5.

The last event, capturing live http headers with headers, is the analysis of a vulnerability you determine applications where developers have not advanced in the use of improved security features.

El siguiente es el de contraseñas inseguras, en este caso se encontró que con el uso de algunos softwares especializados es posible descifrar algunas contraseñas, lo cual no deja de ser preocupante. Sin embargo, día a día los expertos idean mejores mecanismos de cifrar las contraseñas y tratan que los usuarios colaboren creando contraseñas bajo parámetros más estrictos. El último caso, la captura de cabeceras con live http headers, es el análisis de una vulnerabilidad de determinas aplicaciones, en las que sus desarrolladores no han avanzado en el uso de mejores elementos de seguridad. Palabras clave— Máquina Virtual, Sistema Operativo, Hardware, Software, Autenticación, Claves, firmas digitales, script, md5, hash, salt, vulnerabilidad

Abstract— In this paper the analysis and study of alternative solutions to the problems identified in phase two of this time is recorded. Alternative solutions for: collision attack, weak passwords and capture Live http headers with headers. The first case study is the collision attack, if that was confusing because as detected is in the use of digital signature generator openssl, it is believed that the latter software is responsible for the error. But analyzed the case found that the error actually comes from using an encryption function, MD5.

Keywords— Virtual machine, Operating system, Hardware, Software, Authentication, keys, digital signatures, script, md5, hash, salt, vulnerability.

I. INTRODUCCIÓN es sin duda una herramienta valiosa en todos Laloscriptografía procesos de comunicación desde antes de la era digital y en especial en esta era, porque es claro que la informática sería debe ofrecer todos los elementos necesarios para asegurar una adecuada seguridad de la información, en especial manteniendo su confidencialidad.1 Confidencialidad: este principio permite no develar los datos a usuarios no autorizados, es decir, la privacidad de la información (protección de datos).

II. ATAQUE DE COLISIÓN

La primera alternativa de solución consiste en adicionar números de serie aleatorios en los certificados digitales. Pero esta solución tiene el problema de hacer poco práctico el proceso. Segunda alternativa, usar funciones de hash más seguras (solución obvia), por lo cual varias entidades a nivel mundial, como Microsoft y Google, están trabajando en la implantación

2

de certificados SHA-2. De hecho ya anunciaron que a partir de 31 de diciembre de 2015 entraran a poner en ejecución planes de degradación del uso de SHA-1. Por lo cual las organizaciones deben implementar planes de migración de los certificados SSL a la nueva función de certificación. [1] Luego de una larga investigación del tipo de ataque presentado y que permite aprovechar la vulnerabilidad del algoritmo utilizado para la generación de la firma digital en esta práctica, podemos aconsejar efectivamente el uso de mejores algoritmos de encriptación para la generación de dichas firmas, debido a que MD5 no es el mejor para este tipo de casos teniendo en cuenta que como se ha dicho esta presenta la posibilidad que se genere una llave igual para atacar nuestro sistema. Del mismo modo aunque la familia de algoritmos SHA2 (SHA-224, SHA-256, SHA-384, y SHA-512) o SHA3 posiblemente no se pueda decir que es infalible, por lo menos si es destacado decir que implementa mejores procedimientos de encriptación que hacen mucho más complejo la labor de violar los esquemas de seguridad criptográficos, sobre todo que SHA2 para openssl ha demostrado ser de momento lo suficientemente bueno. En ese mismo sentido otra opción que parece ser viable es hacer uso de combinaciones de algoritmos de encriptación tales como SHA-1 Y RIPEMD-160, teniendo en cuenta que si se presenta una colisión en SHA-1 sería muy difícil que coincida en RIPEMD-160. Cabe decir que dentro de esto es pertinente adoptar como buena práctica la necesidad de establecer políticas de vencimiento y actualización en la generación de firmas y certificados digitales, es decir establecer periodos para el cambio de los mismos. También es preciso señalar que es buena práctica, para casos de sistemas de información de extremo cuidado sobre todo, solicitar validación de la firma o certificado digital por parte del emisor de dicho certificado, es decir no usar certificados que no sean emitidos por fuentes fiables. Para concluir un poco de acuerdo a la actividad realizada la mejor recomendación es definitivamente No firmar o generar certificados digitales con MD5 debido a sus evidentes vulnerabilidades.

II.

CONTRASEÑAS INSEGURAS

LA SEGURIDAD DE LAS CONTRASEÑAS La seguridad de un sistema protegido por contraseña depende de varios factores. El sistema debe estar diseñado para sondear la seguridad. A continuación presentó algunos problemas sobre la administración de contraseñas que deben ser considerados para garantizar contraseñas seguras: Formas de almacenar contraseñas Los mejores sistemas almacenan las contraseñas en una forma de protección criptográfica, así, el acceso a la contraseña será más difícil para algún espía que haya ganado el acceso

interno al sistema, aunque la validación todavía sigue siendo posible. La técnica de criptográfico común almacena solamente el texto de la contraseña codificado, conocido como hash. Cuando un usuario teclea la contraseña en este tipo de sistema, se genera a partir de la contraseña y mediante un algoritmo el código hash equivalente para esa contraseña, y si el resultante (hash) coincide con el valor almacenado, se permite el acceso al usuario. El texto codificado de la contraseña se crea al aplicar una función criptográfica usando la contraseña y normalmente, otro valor conocido como Salt. El salt previene que los atacantes construyan una lista de valores para contraseñas comunes. [17] Aunque la aplicación de un algoritmo hash a la contraseña es un buen comienzo, para incrementar la seguridad frente a posibles atacantes, podrá aplicar un algoritmo salt al hash de la contraseña. El aplicar un algoritmo salt implica la inserción de un número aleatorio en la contraseña a la que se le ha aplicado un algoritmo hash. Esta estrategia ayuda a impedir que posibles atacantes aprovechen ataques de diccionario calculados con antelación. Los ataques de diccionario son ataques en los que el atacante utiliza todas las posibles combinaciones de claves secretas para descifrar la contraseña. Al utilizar un valor salt para ordenar de forma más aleatoria el hash, un atacante podría necesitar crear un diccionario para cada valor salt, de esta manera el ataque resultaría muy complicado. [18] Los algoritmos hash como MD5, SHA1 o SHA256 están diseñados para ser muy rápidos y eficientes. Con las técnicas y equipos modernos, es algo trivial extraer por fuerza bruta la salida de estos algoritmos, para determinar los datos de entrada originales. Con la masificación del uso de aplicaciones en las: LAN, MAN, WAN y en la WEB. Se ha convertido en un problema real la forma en que los usuarios elegimos nuestras claves. Son muchas las instituciones que propenden por orientar en los usuarios de sus aplicaciones la adopción de recomendaciones para la creación de contraseñas más seguras. Entre estas recomendaciones, están algunas genéricas como: • Cambiar la clave periódicamente. • Tratar de no elegir una clave anterior dada en el mismo sistema. • Evitar que la clave sean datos de fácil conocimiento público, como:  Nombres y apellidos del usuario o sus parientes cercanos.  Fechas de nacimiento del usuario o parientes cercanos.  Nombres de las instituciones a las que está o ha estado vinculado.  El número o parte del número de identificación pública (cédula, pasaporte, licencia de conducción, etc.)  Evitar el uso de contraseñas populares. Otras tratan sobre la conformación de la clave misma y

3

hacen recomendaciones como: • La clave debe contener mínimo 6 caracteres. • Debe hacerse una combinación entre mayúsculas y minúsculas. • Debe incluirse, al menos un dígito.

sea todas aquellas características físicas consideradas estáticas (de ninguna o muy mínima variación en el tiempo). De entre ellos uno de los de mayor difusión es el lector de huella digital, que combinado con el dato del usuario y la clave, hace más complicada la tarea del hacker. [4]

Estas y otras recomendaciones se leen o escuchan provenientes de los expertos en la temática. Pero desafortunadamente, de una parte los usuarios tiende a elegir sus contraseñas con ligereza, de otra para muchos usuarios es tan grande el número de claves que requiere manejar en tan diversos sistemas que cada vez se hace más complicado observar la correcta aplicación de todas las recomendaciones.

Otro tipo de dispositivos de gran difusión entre los usuarios de cierto nivel de las entidades financieras y otras que por el tipo de acceso se hace más exigente elevar los niveles de seguridad. Ese dispositivo es un pequeño aparato portátil que genera para el usuario un Token (considerado de seguridad segundo nivel). Ese dato conformado por 6 dígitos, cambia cada 60 segundos y este dato es exclusivo para cada usuario a quien se asocia el dispositivo, es parte de la información con la que el usuario debe identificarse ante el sistema para poder ingresar.

Por lo cual, algunas instituciones han optado por realizar otra comprobación con alguna frecuencia o cuando detectan cambio en la IP de uso corriente de un usuario específico. Esta comprobación típicamente radica en la indagación al usuario por alguna de sus respuestas registradas en un banco de preguntas previamente diligenciado. De esta forma se trata de garantizar la autenticación de quien se ha identificado y solicita el acceso. Con todo eso, hay circunstancias en las que poco o nada puede hacer el usuario cuando se suceden los ataques a las grandes bases de datos, repositorios de esta información sensible. De allí que existen compañías preocupadas por establecer sistemas duros de cifrado para esta información, de tal manera que si esta información clave es hurtada no sea de fácil lectura. Por lo anterior, hay quienes manifiestan que la solución ya existe y consiste en aplicar técnicas como Secure Remote Password (contraseña remota segura), que permite al usuario presentar su contraseña pero la misma, ni algún derivado de ella, es de conocimiento de quien realiza la comprobación. Indican que este mecanismo fue creado en 1998 por la Universidad de Stanford y estandarizado en el protocolo TLS. [2] De esta forma un atacante no llegaría a obtener suficiente información como para establecer mediante el sistema de fuerza bruta la clave, sin tener que interactuar simultáneamente con las dos partes, solicitante y verificador. O sea que el atacante tendría que conocer perfectamente el funcionamiento del sistema y obtener la información de las dos partes. Con la preocupación de allegar mayor control al acceso a determinadas aplicaciones que exigen alta seguridad para determinados usuarios, la industria del hardware también ha realizado su aporte con dispositivos de identificación biométrica. Los que son usados en reemplazo o en combinación con la clave. Identificación biométrica significa reconocimiento único por identificación matemática de las medidas del ser humano, permitiendo la identificación única por alguna de sus características. Entre otros: la huella dactilar, el iris, rasgos faciales, la retina, la geometría de algunas partes del cuerpo. O

Adicionalmente, todos estos datos son encriptados a 128 bits, más certificado digital. O sea que no son cualquier tipo de medias de seguridad, tienen un nivel de efectividad elevado. Aunque todo esto, obviamente eleva los costos del sistema de seguridad que usa la empresa. Por lo cual no está disponible para todas las personas. [5]

OTRAS ALTERNATIVAS PARA EL CONTROL DE ACCESO 1 Contraseñas de un solo uso: son contraseñas válidas para una sola ocasión, lo que hace que sea más complicado para los atacantes. Este tipo de contraseñas han sido implementadas en la banca personal en línea donde se les conoce como TANs, pero el uso de este mecanismo no ha sido bien recibido por los usuarios. 2 Símbolos de Seguridad: este mecanismo es similar a las contraseñas de un solo uso pero el valor a ingresar aparece en un pequeño FOB que cambia cada minuto. 3 Controles de Acceso: estos están basados en la criptografía pública dominante, es decir SSH. Las claves deben ser almacenadas en una computadora local, en un símbolo de seguridad o en un dispositivo de memoria portable (memorias o discos flexibles) 4 Métodos biométricos: están diseñados con características personales de tal forma que no puedan ser alterados, requieren hardware adicional para poder escanear características personales tales como las huellas digitales, el iris, etc. 5 Verificación en 2 Pasos: este es un método comúnmente utilizado, que consiste en él envió de un segundo código mediante mensaje de texto o llamada al teléfono móvil que pertenece al usuario, de esta forma la única persona que puede acceder a la información será quien tenga la contraseña y el teléfono móvil donde se envía el código.

4

El inconveniente del método de verificación en 2 pasos, está ligado con la disponibilidad o no del teléfono, ya sea por pérdida o robo, por tal razón se debe suministrar otro equipo de confianza. Este sistema es utilizado muy regularmente en las cuentas de correo como Outlook, Gmail y en las redes sociales como Facebook. 6 Mediante dispositivos móviles: este procedimiento es realizado mediante aplicaciones diseñadas para enviar una contraseña encriptada, desde un dispositivo móvil hasta un computador de escritorio, de esta forma al sitio web al que se ha intentado acceder puede reconocer la contraseña en vez de tener que digitarla. 7 Mediante ondas Cerebrales: este mecanismo se encuentra aún en proceso de desarrollo y consiste en un dispositivo que es un auricular simple, que mide las ondas cerebrales evitando el uso de cualquier otro mecanismo de identificación III.

CAPTURA DE CABECERAS

En primer lugar se sugiere que al momento de tratar de enviar información sensible desde un equipo se tome la precaución de verificar que en el mismo no este corriendo algún tipo de aplicación de recolección de información. Desafortunadamente, no todas las personas cuentan con el conocimiento suficiente para detectar este tipo de software y saber cómo evitarlo. Otra opción, pero que depende del proveedor de la aplicación que se esté usando, propone que toda información sensible (usuario, clave, etc.) que se requiera transmitir por la red vaya encriptada con protocolos seguros en los que el algoritmo de encriptación no sea parte de la transmisión. Adicionalmente, se deberían disponer el uso de un token o código encriptado que sirva para verificar la procedencia de la información. Como se mencionó, la mayor parte de las soluciones para este tipo de problema radica en la gestión de seguridad que los desarrolladores de apliquen a sus productos. Es así, como actualmente se dispone del protocolo HTTPS, que se diferencia del HTTP porque emplea SSL para que con la utilización de un algoritmo la transmisión de datos es cifrada. Esto quiere decir que hará mucho más difícil su lectura por parte de mal intencionados. [5] Es pertinente tal como se ha mencionado el uso de algoritmos de encriptación del lado del cliente, para ello es pertinente que los desarrolladores implementen mejores prácticas y técnicas a la hora del envío de los datos de autenticación de usuarios, tales como procesar la petición antes de enviarla, encriptando información de cajas de texto. Enfatizo que la utilización del protocolo HTTPS para que la

comunicación sea cifrada incluyendo la cookie de sesión. Así mismo es pertinente que se active la opción secure para las cookies de sesión, lo cual evita que dichas cookies sean enviadas por el navegador a través de la petición HTTP y esto previene que sea posible obtenerla interceptando el tráfico. Otro aspecto importante es la activación de la opción httponly en servidores web la cual es una estrategia para evitar el acceso por medio de scripts a las cookies que tienen este atributo habilitado, el proceso consiste en declarar los cookies como HTTPonly, protegiéndolos de lectura y escritura por parte de scripts del lado del usuario, lo cual garantiza que solo el servidor y el navegador tendrán acceso a la información guardada en los mismos. Sin embargo complementario a esto es importante de igual forma la deshabilitación del método TRACE ya que con este método activo es posible robar la cookie así se tenga la opción httponly habilitada, por ende es importante hacer lo siguiente: Se habilita primeramente el módulo rewrite en Apache mediante a2enmod rewrite y a luego de eso se añade la línea TraceEnable Off en/etc/apache2/apache2.conf para deshabilitar el método.

IV. CONCLUSIONES 

La industria de software especializado en seguridad es muy activa y próximamente podremos tener en nuestro arsenal de seguridades nuevas y más seguras funciones hash.



El tema de seguridad en claves de acceso tiene dos vectores fundamentales: la consciencia del usuario frente a un manejo seguro de sus claves y la labor de los ingenieros especializados en software para aplicar los necesarios elementos de seguridad.



Aunque en buena parte, la seguridad de transmisión de la información recibida en formularios, depende exclusivamente de los ingenieros que desarrollan esos formularios, los usuarios deben aprender a tomar unas precauciones mínimas.

V. REFERENCIAS

[1] S. Corporation, 2015 . [En línea]. Available: http://www.symantec.com/es/es/page.jsp?id=sha2transition. [Último acceso: 22 03 2015]. [2] I. N. d. Ciberseguridad, «Autenticación segura con passwords... ¿es posible?,» incibe, [En línea]. Available: https://www.incibe.es/blogs/post/Seguridad/BlogSeguri

5

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

dad/Articulo_y_comentarios/autenticacion_passwords_ srp. [Último acceso: 22 03 2015]. «HTTP vs. HTTPS: ¿Cuál es la diferencia?,» BizTech CDW, [En línea]. Available: http://www.biztechmagazine.com/article/2007/07/httpvs-https. [Último acceso: 22 03 2015]. Davivienda, «Seguridad,» Davivienda, [En línea]. Available: https://www.davivienda.com/wps/portal/empresas/davi vienda/inferior/p_seguridad. [Último acceso: 25 03 2015]. F. A. F. R. C. B. Javier Ortega García, Biometría y Seguridad, Madrid, España: Universidad Autónoma de Madrid, 2008. squirrel, «Seleccionado el nuevo estándar SHA3,» 08 10 2012. [En línea]. Available: http://www.kriptopolis.com/nuevo-sha3. «Keccak es el algoritmo elegido como SHA-3,» 03 10 2012. [En línea]. Available: http://cyberseguridad.net/index.php/230-keccak-es-elalgoritmo-elegido-como-sha-3. «Keccak is SHA-3,» 2 10 2012. [En línea]. Available: https://www.schneier.com/blog/archives/2012/10/kecca k_is_sha-3.html. M. M. Yerko, «Algoritmos HASH y vulnerabilidad a ataques,» 2009. [En línea]. Available: http://www.revistasbolivianas.org.bo/scielo.php?pid=S 1997-40442009000200026&script=sci_arttext. t. e. i. i. Ministerio del poder popular para la ciencia, «ESTUDIO DE FACTIBILIDAD PARA ACTUALIZACIÓN DE ALGORITMO DE HASH,» 26 09 2011. [En línea]. Available: http://acraiz.suscerte.gob.ve/sites/default/files/documen tacionPKI/Informe_Algoritmo_criptografico_v1.4Firmado.pdf. J. P. H. Hugo Daniel Scolnik, «IMPACTO DE RECIENTES ATAQUES DE COLISIONES,» 5 09 2004. [En línea]. Available: https://www.certisur.com/sites/default/files/docs/ataque s_funciones_hashing.pdf. «Protocolos,» [En línea]. Available: http://www2.dc.uba.ar/materias/crip/docs/n_07_protocolos_i_hashi ng.pdf. R. Naraine, «¡SSL roto! Investigadores crean un certificado CA falso usadon colisiones MD5,» 31 12 2008. [En línea]. Available: http://seguinfo.blogspot.com/2008/12/ssl-rotoinvestigadores-crean-un.html. LordHASH, «Algoritmos HASH (II): Atacando MD5 y SHA-1,» 18 4 2007. [En línea]. Available: http://gaussianos.com/algoritmos-hash-ii-atacandomd5-y-sha-1/. S. D. Luz, «Criptografía : Algoritmos de cifrado de clave simétrica,» 4 11 2010. [En línea]. Available: http://www.redeszone.net/2010/11/04/criptografiaalgoritmos-de-cifrado-de-clave-simetrica/.

[16] «Http al descubierto,» [En línea]. Available: http://www.taringa.net/posts/info/13845034/HTTP-alDescubierto.html. [17] «¿Qué son y para qué sirven los hash?: funciones de resumen y firmas digitales,» Genbeta: dev, 15 1 2013. [En línea]. Available: http://www.genbetadev.com/seguridadinformatica/que-son-y-para-que-sirven-los-hashfunciones-de-resumen-y-firmas-digitales. [Último acceso: 20 3 2015]. [18] «Protección de credencial de contraseña,» Microsoft, [En línea]. Available: https://msdn.microsoft.com/eses/library/aa289843(v=vs.71).aspx. [Último acceso: 20 3 2015]. [19] «Hijacking de cookies HTTP-Only con XSS usando TRACE,» UN INFORMÁTICO EN EL LADO DEL MAL, 10 11 2011. [En línea]. Available: http://www.elladodelmal.com/2011/11/hijacking-decookies-http-only-con-xss.html?m=1. [Último acceso: 28 3 2015]. [20] M. M. R., «¿Qué son los HTTPonly Cookies?,» eSecuring, [En línea]. Available: http://www.esecuring.com/novedad.aspx?id=34. [Último acceso: 28 3 2015].

VI. BIOGRAFÍA

Jaime Henao nació en Bogotá, el 12 de enero de 1958. Se graduó bachiller en el Colegio Nacional de San Simón, Licenciado en Matemáticas y Física en la Universidad del Tolima, Ingeniero de Sistemas de la Unad, Especialización en Ingeniería de software en la Universidad Distrital. Ejerció profesionalmente la dirección docente para la secretaría de educación del Tolima, Universidad Colegio Mayor de Cundinamarca, Escuela Nacional de Impuestos de la Dian. En el área de TI: Director de informática en la Dian, Director de Informática de Telecom, asesor en informática en Ecopetrol, asesor en informática en el Seguro Social, asesor en informática en Siesa, Director de Calidad en desarrollo informático en Sertisoft. Asesor y desarrollador de soluciones de software. Experiencia acumulada en el área de TI por más de 25 años. Vinculado como estudiante a la Unad desde 2007, con periodos de interrupción. Vinculado al CEAD de Barranquilla, aunque por razones laborales estoy ahora radicado en Bogotá.

6

Luis Ardila. De nacionalidad colombiano, Nació en Cartagena bolívar, es Tecnólogo en administración de empresa, Ingeniero de Sistemas y administración de empresa graduado de la Universidad Nacional y a Distancia UNAD y Especialista técnica en seguridad industrial y está realizando estudios en la Especialización en Seguridad Informática que ofrece la UNAD. Labora como administración de las salas informática de la universidad de Cartagena como Responsable de todas las sedes , enlace municipal jóvenes en acción DPS

Fabio Castro, nació en Barranquilla, Colombia, el 12 de marzo de 1981. Ser graduó en la Universidad Abierta y a Distancia UNAD en Ingeniería Electrónica. Trabaja actualmente en UNE EPM Telecomunicaciones en la cabecera de TV, tiene 7 años laborando en la empresa, vive en la ciudad de Barranquilla, sus expectativas como ingeniero son seguir creciendo en el ámbito laboral y profesional. Pertenezco al CEAD Simón Bolivar de la ciudad de Cartagena.

Amaury Gamarra nacio en Cartagena Bolivar, el 24 julio 1977 se gradu en el Instituto Tecnologico Comfenalco en convenio con la Universidad Tecnologica de Bolivar en Ingenieria de Sistemas, realizo estudios especiallizado en Administracion de Bases de datos en el Servicio Nacional de Aperendisaje SENA. Ejerció profesionalmente en la Departamento administrativo Nacional de Estadísticas DANE desde 2008 como ingeniero de soporte. Su experiencia profesional está enfocada en la administración de las base de datos y en la seguridad de los Dispositivos Móviles, actualmente trabaja en el Departamento Administrativo Nacional de Estadísticas DANE como ingeniero de plata como apoyo y soporte informático en la captura y transmisión de los datos recolectados en campo de las Investigaciones estadísticas que se llevan a cabo en la ciudad de Cartagena.

Jaider Contreras nació en Sincelejo Sucre, Colombia, el 25 de Septiembre de 1983. Se graduó en 2006 como Ingeniero de Sistemas en la Corporación Universitaria del Caribe. Sus experiencias profesionales incluyen la corporación autónoma regional de Sucre (CARSUCRE), el SENA, ParqueSof, entre otras, actualmente se desempeña como ingeniero de sistemas en el cargo de profesional especializado dentro de la Oficina de Tecnologías de la Información de la Unidad de Restitución de Tierras.