riesgo

Banco Ganadero: Auditor de Riesgo Tecnológico

Editor YPT 14/10/2021

DESCRIPCIÓN

Auditor(a) de Riesgo Tecnológico

(Sede: Santa Cruz)

Principales Responsabilidades del Cargo:

Evaluar las características de los sistemas informáticos del banco y los factores de riesgo tecnológico que se identifiquen, obteniendo evidencias competentes para confirmar si el sistema de control en las distintas áreas del sistema informático del banco son efectivos.
Evaluar si las operaciones de Sistemas de Información se están realizando de forma eficiente y si se cumplen los objetivos de negocio y de efectividad.
Evaluar la efectividad de la gestión informática del banco, el desarrollo de sistemas, la integridad de datos y la operatividad de los sistemas informáticos.
Evaluar los nuevos riesgos producto de las nuevas tecnologías emergentes de la Banca Digital.
Cumplir sus funciones con la objetividad, diligencia debida y debido cuidado profesional, de acuerdo con las normas profesionales de auditoria.

Perfil del Cargo:

Licenciados(as) o Ingenieros(as) en carreras Informáticas o de Sistemas.
Maestrías o Diplomados relacionados (Deseable).
Buen Dominio de Inglés Técnico (Deseable).
Experiencia mínima de dos años en cargos con similares responsabilidades en entidades financieras (Deseable).
Dominio de Herramientas de Microsoft Office, Software, Inteligencia de negocios, análisis de datos y herramientas de auditoria continua. (Deseable).
Conocimientos de normativas, estándares y legislación vigente (Estándares de Tecnología, Seguridad de la Información y Riesgos (Deseable).
Conocimiento y experiencia en el ciclo de vida del desarrollo de software.
Experiencia en Javascript y reactJs y conocimiento de consultas SQL y PSQL.
Conocimiento en DevOps (Docker, Jenkins, GitLab, Jira, Kubernetes) (Deseable).
Habilidades de comunicación, capacidad de aprendizaje y trabajo en equipo.

Requisitos: Habilidad:

Conocimiento del Idioma Inglés (Excluyente)
Dominio de Herramientas de Microsoft Office, Software, Inteligencia de negocios, análisis de datos y herramientas de auditoria continua. (Excluyente)
Conocimiento en normativas de seguridad de la información de entidades financieras y de estándares de seguridad de la información: ISO 27001, 27032, 27005, PCI-DSS, COBIT, NIST SP 800, OWASP. (Excluyente)
Conocimiento en DevOps (Docker, Jenkins, GitLab, Jira, Kubernetes) (Excluyente)

Articulos

DESPUES DE LA PANDEMIA – DESINTOXICACION TECNOLOGICA

Guido Rosales 18/06/2020

Ojala sea pronto. el stress tecnológico esta agobiando a todas las personas. Ya paso el momento de tomar la cuarentena como algo de verdad preocupante, pero novedoso. Ahora ya estamos pasando al momento del aburrimiento individual. No dejamos de lado la necesidad de protegernos con el debido resguardo domiciliario, pero el agobio mental y el encierro o limitada movilidad tendrá sus efectos muy pronto. Las relaciones familiares y laborales se hacen mas tensas y el cuidado de la salud sera menoscabado!!

Todo esto sin duda afecta y afectara al rendimiento y creatividad que normalmente pueda tener una persona. Dejaremos de preocuparnos por innovar y dedicaremos el tiempo a sobrevivir de la manera mas segura posible.

Uncategorized

Evaluacion Diciembre 2017: Debilidades en APPs moviles NACIONALES

Guido Rosales 21/12/2017

Muchas empresas contagiadas con la arrollante embestida del mundo móvil, decide entrar con aplicaciones móviles de todo tipo y sabor. Desde simples app informativas hasta sistemas de gestión o banca móvil.

Todo va bien, el entusiasmo por desarrollar apps móviles es impresionante, vemos muchos eventos promoviendo esto. Pero lamentablemente temas de Seguridad van por detrás. El optimismo de la gente hace que las preocupaciones y riesgos no sean parte del procesos de desarrollo sino hasta que las vulnerabilidades saltan.

Para demostrar este punto de la inseguridad, hemos realizado un relevamiento con 11 APKs compartidas en el Play STORE de google, todas bolivianas. Todas estas Apps pertenecen a entidades XXX-XXX (Censurado para no despertar a los GGX) y están en actual explotación con sistemas considerados sensibles.

Entendamos que la vulnerabilidad de una APP no solo expone el sistema de la Entidad XXX-XXX que la desarrollo. sino también expone los datos del usuario cliente. Casi todas las apps evaluadas consideramos no han tenido una evaluación de privilegios necesarios, sino en algunos casos como utilizan componentes de terceros, solicitan control de gps, wifi, micrófono, cámara, envio de sms y muchos mas. Al final uno se pregunta Por que tantos privilegios? estamos seguros y retamos a las entidades XXX-XXX que publiquen la justificación de esos privilegios.

Recordemos que un celular puede exponer:

credenciales de acceso
datos de ubicación por el gps,
la conexión telefónica por las antenas, datos
de los sensores (acelerómetro, giroscopio, podómetro y otros)
mucho mas

Entonces la publicación de APPs debe ser mas controlada, sobre todo si el usuario asume que la seguridad esta siendo cubierta por la Entidad que la despliega en el play store.

Voy a ser redundante en el tema de que estar en los Store de aPPs no hace las mismas seguras. Google no se ocupa de ver cuan segura es la aplicación, siempre y cuando no este afectando a su ecosistema.

Algunas características genéricas de Las APK analizadas

tienen entre 35mb y 2mb de tamaño
Las Apps de mayor tamaño contienen mas cantidad de vulnerabilidades.
Algunas tienen semanas de haber sido actualizadas y otras mas de un año de no Haber sido actualizadas
Todas están el el Play store
Solo una tenia controles para no ser montadas en un emulador

Se han evaluado 34 vulnerabilidades (OWASP mobile)

De esa cantidad se han encontrado 16 vulnerabilidades presentes en las App analizadas. En el cuadro siguiente exponemos las 16:

File unsafe Delete Check

SSL Implementation Check - SSL Certificate Verification

Certificate Pinning

Using activities/improper export of android application activities

Fragment Vulnerability Check

Usage of Adb Backup

Usage of Native codes

Outputting Logs to logCat/ Logging Sensitive information

SQLite Journal Information Disclosure Vulnerability

WebView addJavascriptInterface Remote Code Execution

Usage of Root/Superuser Permission

Usage of Installer verification code

Executing "root" or System Privilege Check

Emulator Detection Check

Unencrypted Credentials in Databases (sqlite db) Vulnerability check

Access Mock Location

El resultado en terminos porcentuales por SEVERIDAD es el siguiente:

Desglozadas por su nivel de Severidad tenemos:

Las vulnerabilidades expuestas NO son nuevas. Solo veamos un ejemplo con Certific ate Pinning

Les dejo un enlace del 2013 donde se expone la misma: http://blog.elevenpaths.com/2013/08/certificate-pinning-el-que-el-como-y-el.html

y otro enlace de OWASP: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

ACLARACION

El presente articulo continen datos que han sido colectados a inicios del mes de diciembre. Las evaluaciones se han terminado antes del 10/12. En ese tiempo podrian haberse dado algunas modificaciones, pero estimamos que no muchas.

El contenido trata de ser lo mas generico posible para llegar al publico en general. Sin embargo el soporte es tecnico.

CONCLUSION:

La innovacion por supuesto que es bueno y no podemos cargar con temas de seguridad toda esa corriente que motivada por el acelerado crecimiento de la tecnologia movil esta buscando nuevas formas o reinventando nuevos conceptos. Por eso en las entidades y en general estamos quienes nos ocupamos de temas de seguridad. No queremos estar contra la corriente y el entusiasmo. Pero seria irresponsable sacar un ultimo modelo de automovil sin la seguridad necesaria.

Las entidades reguladas, reguladoras deben prestar atencion a la bomba de tiempo que estamos colocando en cada telefono movil. Y el usuario final debe entender que ese Compañero digital llamado telefono movil, puede traerle muchos problemas en un momento dado.