desarrollo seguro de aplicaciones mÓviles aplicando
TRANSCRIPT
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
1
DESARROLLO SEGURO DE APLICACIONES
MÓVILES APLICANDO PRINCIPIOS DE LA
NORMA ISO 27001 López Vargas, Johann Harry.
Universidad Piloto de Colombia
Resumen—El propósito de este artículo, es
identificar las características que son necesarias
para el desarrollo seguro de aplicaciones móviles,
brindando un enfoque que permita alinearse con los
estándares de la norma internacional ISO 27001
versión 2013; aplicando conceptos generales que
empresas y organizaciones reconocidas, a nivel
mundial han desarrollado a lo largo de los años y
facilitaran implementar los procedimientos
necesarios para alcanzar este objetivo.
Abstract— The purpose of this article; is to
identify the features, that are necessary for the
secure development of mobile applications,
providing an approach that allows alignment with
the standards of the international standard ISO
27001 version 2013. Applying general concepts,
that companies and organizations recognized
worldwide have developed over the years and will
facilitate the implementation of the necessary
procedures to achieve this objective.
Índice de Términos—aplicaciones seguras,
desarrollo de aplicaciones, implementación de
seguridad, principios de la norma ISO 27001,
ingeniería de software.
I. INTRODUCCIÓN
Actualmente el mundo ha alcanzado un nivel de
interconexión jamás imaginado. Según un estudio
realizado por el Fondo Monetario Internacional,
“La demanda de equipos móviles se ha
incrementado a una cifra casi astronómica y su
tendencia indica, un crecimiento de adquisición
mayor con el paso de los años” (Ver Fig. 1), el
crecimiento del mercado ha generado que las
personas hoy en día puedan acceder más fácilmente
a tecnologías, que en años anteriores no eran tan
comunes; motivo por el cual, no existe actualmente
una preparación adecuada que pueda afrontar los
retos de seguridad que esto conlleva.
El crecimiento en la demanda ha generado una
cantidad descomunal de aplicaciones para todo tipo
Fig. 1. Crecimiento en la demanda de Smartphones en los últimos
años, Obtenida de https://www.econmatters.com/2018/02/is-
smartphones-demand-peaking.html
de situación, estas son indiscriminadamente
instaladas por los diferentes usuarios y son usadas,
en diferentes contextos en el día a día; ya sea por
temas laborales, el incremento de la productividad,
acceso a contenido educativo e incluso, consumo de
ocio.
El crecimiento descomunal de los dispositivos ha
convertido el mercado móvil no solo en un objetivo
comercial, también ha llamado la atención de los
criminales informáticos; es por eso, por lo que
existe una necesidad de producir aplicaciones de
manera rápida y tal vez, sin la correcta
implementación de las consideraciones necesarias
en su desarrollo, que permitan entregar al cliente
final una herramienta acorde a unos mínimos
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
2
estándares de seguridad y calidad. El ramillete de
opciones está servido en la mesa. En las diferentes
tiendas de aplicaciones podemos encontrar
software, tanto para la integración como para
ofrecer nuevas experiencias a los consumidores
finales, convirtiéndose en algo imprescindible y
quien no cuente con este recurso, pierde nivel
competitivo en su nicho de interacción.
Pero, ¿Qué conlleva este crecimiento? ¿Qué
impacto tiene en las diferentes áreas tecnológicas de
las empresas? ¿Hemos evaluado la necesidad de
implementar medidas para mitigar los riesgos que
generan este tipo de dispositivos en una
organización?, aún la respuesta es incierta y de
difícil evaluación; los llamados “smartphone”,
dando un vistazo desde un punto de vista técnico,
son equipos que ofrecen el mismo servicio que un
computador de escritorio, pero con la ventaja de la
portabilidad, es por eso que su uso se ha masificado
y de igual forma, se ha multiplicado el riesgo de
seguridad.
Teniendo como base el anterior análisis,
podemos identificar claramente que el desarrollo
móvil, se ha incrementado en los últimos años y
esto conlleva, al reto de suplir y monetizar este tipo
de productos. Para intentar cumplir y satisfacer las
exigencias de sus clientes, esto nos conduce a
realizar el siguiente cuestionamiento: ¿Se toman las
medidas necesarias para que con cada desarrollo se
cumplan con los requisitos mínimos de seguridad
que preserven la disponibilidad, integridad y
confidencialidad de la información?,
lastimosamente la respuesta es NO; vemos con
cierta preocupación que la necesidad de cumplir con
estos estándares, no es algo que esté dentro de las
prioridades de los proveedores de este servicio, ni
tampoco existe una conciencia de crear un
presupuesto que permita cumplir con este alcance.
La organización sin ánimo de lucro OWASP, que
se encarga de apoyar los esfuerzos que encaminen a
las instituciones, empresas y mercado en general
para concebir, desarrollar, adquirir, operar y
mantener aplicaciones en las que se pueda confiar
[1], plantea un Top 10 de vulnerabilidades, las
cuales afectan a los diferentes dispositivos móviles
a nivel mundial; este referente podría ser un punto
de partida para identificar la necesidad de establecer
una serie de prácticas en las diferentes
organizaciones, para brindar un producto con
óptimos niveles de seguridad y que cumplan, a
satisfacción con los requerimientos de las empresas
y sus clientes, implementando unas mejores
prácticas que minimicen las afectaciones, que
podrían presentarse por el uso indebido de estas
tecnologías, realizando los análisis de riesgos
correspondientes y planteando un modelo para el
control de amenazas, como punto de partida para el
inicio de cualquier construcción de un software; y
puedan sentar las bases de una correcta
implementación, en donde el enfoque sea un
procedimiento de seguridad, que por medio de las
buenas prácticas permita generar un valor agregado,
en donde se apliquen unos correctos controles que
favorezcan, el desarrollo de productos con un
máximo nivel de calidad y seguridad.
II. A QUÉ NOS ENFRENTAMOS
Fig. 2. Top 1 de Vulnerabilidades OWASP para dispositivos móviles,
obtenida de https://www.owasp.org/index.php/OWASP_ Mobile_
Security_Project#tab=Top_10_Mobile_Risks
En la imagen anterior, (Ver Fig. 2) la
organización OWASP presenta un top 10 de
vulnerabilidades, que se pueden presentar en los
dispositivos móviles [2]; estas vulnerabilidades en
los sistemas, no identifican la totalidad del
conjunto, que podemos encontrar en los diferentes
ámbitos de desarrollo y producción, pero sí nos
brindan un norte para poder empezar a evaluar, qué
nivel de seguridad ha sido implementado en cada
uno de los procesos de construcción y despliegue,
para el usuario final.
Las vulnerabilidades que ofrece este top OWASP,
son las recopilaciones de diferentes colaboradores a
nivel mundial, que permitieron identificar los
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
3
mayores riesgos de los sistemas móviles. A
continuación, daremos una visión general de los
principales:
A. M1-Controles Débiles de lado servidor
La dificultad para desarrollar una implementación
mínima de seguridad, que permita identificar
vulnerabilidades en los servicios Apis de terceros,
como se describe en OWASP, es todo lo que pueda
salir mal que no tiene lugar en el teléfono
(CLOUD).
B. M2- Almacenamiento de datos inseguros:
Esta vulnerabilidad se presenta cuando los
equipos de desarrollo, confían que los usuarios u
otro software; no tendrá acceso a datos sensibles de
la aplicación.
C. M3- Debilidad en la protección de la capa de
transporte
Las aplicaciones a menudo no protegen el tráfico
en la red y exponen información crítica del usuario.
D. M4- Fuga involuntaria de datos
Esta pérdida se produce cuando el desarrollador,
almacena información sensible en secciones del
sistema operativo como: cache, cookies,
portapapeles y puede, ser fácilmente accedida por
terceros, exponiendo la información crítica del
usuario.
E. M5- Pobres mecanismos de autenticación y
autorización:
Los mecanismos pobres o inexistentes, para la
autenticación de una aplicación, permiten el ingreso
de modo anónimo en la aplicación.
F. M6- Uso Inseguro de Criptografía
El uso de algoritmos de cifrado débiles o su mala
implementación, permitirían a un adversario, tener
acceso a la información crítica del usuario que usa
el sistema.
G. M7- Inyección de lado del Cliente
Permite ejecutar código malicioso directamente
en el dispositivo móvil, a través de las mismas
aplicaciones instaladas. La estructuración de las
fuentes de entrada no permite una validación
correcta y son susceptibles a ingreso de datos
incorrectos, que pueden afectar el sistema.
H. M8- Decisiones de seguridad a través de
entradas no confiables.
La aplicación puede aceptar datos de cualquier
fuente IPC (inglés Inter Process Comunication), la
cual es una función básica de los sistemas
operativos, que permite que los procesos puedan
comunicarse entre sí, compartiendo espacios de
memoria [3], sin que exista un filtro para acceder a
estas comunicaciones.
I. M9- Manejo incorrecto de sesión
Cuando se realiza una autenticación entre el
cliente y el servidor, se comparte un TOKEN de
sesión, el cual es administrado para realizar las
diferentes transacciones mientras dure la sesión; un
manejo o exposición no adecuado permite que un
adversario, pueda acceder a esta información y
pueda suplantar al cliente.
J. M10 – Falta de protecciones binarias
La aplicación no tiene mecanismos que permitan
protegerla contra la ingeniería inversa; el análisis de
flujo de control, la modificación de la capa de
control HTML o la modificación de un ejecutable
binario, que evite pasar por un control de seguridad.
El común de las vulnerabilidades expuestas por
esta organización indica que, los elementos que
convergen puedan materializarse en un ataque o una
exposición de datos críticos, hasta un nivel de:
infraestructura, transporte y desarrollo. Esta
convergencia de factores, es el campo de acción, al
que tiende a estar expuesto cualquier software, que
se encuentre abierto a un público general u objetivo.
Para evaluar qué tanto está expuesta, una
determinada aplicación a estos factores, es
necesario identificar en qué grado de madurez se
tiene la implementación de los procesos de
seguridad y cómo poder alinearnos a los objetivos
estratégicos de la organización; siendo necesario
establecer una estrategia que nos permita dar
seguimiento, a las actividades de control de nuestros
elementos de desarrollo.
III. CONCIENCIACIÓN
La Real Academia de la Lengua RAE [4] describe
concienciar como: “Hacer que alguien sea
consciente de algo”; esta definición es importante
tenerla en cuenta, ya que es el punto de partida para
iniciar cualquier proceso, que busque implementar
herramientas para un desarrollo seguro. Las
organizaciones han adoptado tecnologías
importantes en los últimos años y es común ver,
como las empresas han sistematizado una enorme
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
4
cantidad de sus procesos, haciendo grandes
inversiones en la compra de nuevos recursos, que le
permitan generar un recorte de gastos y una mayor
eficiencia de estos.
Esta tecnificación ha ayudado a las empresas a
tener un mejor control sobre sus recursos, lo cual
actualmente, se ha convertido en uno de los grandes
puntos débiles, debido a la falta de conciencia por
parte de la alta gerencia y el personal en general.
La norma internacional ISO 27001[4] nos indica en
su numeral 7.3, la necesidad de crear una conciencia
de seguridad en la organización, siendo un factor
decisivo para establecer procedimientos, que hagan
más seguras las unidades de trabajo; los equipos de
desarrollo, actualmente deben ser concientizados
sobre los riesgos a los que se exponen en su trabajo,
ya que, esto junto a la falta de controles afecta a la
organización y a las personas, que son destinatarios
del producto final.
El primer paso por dar en la organización es
reconocer que hay riesgos y vulnerabilidades
latentes, que pueden afectar sus productos, su
imagen y su reputación en el mercado; riesgos que
deben ser transmitidos y analizados, desde el punto
de vista económico, para que se pueda evaluar el
posible impacto en caso de presentarse. Por tal
motivo, una vez que la organización entienda que se
encuentra expuesta, debe evaluar el riesgo, e
identificar los factores que puede converger en su
contra.
IV. ANÁLISIS DE RIESGOS
El análisis de riesgos es el estudio de las posibles
causas de las diferentes amenazas. La frecuencia
con la que pueda presentarse y como pueden afectar
una organización, son probables eventos que
podrían materializarse y atentar negativamente
contra los activos. En el desarrollo de software,
estos riesgos son intangibles, por lo que hace más
difícil su identificación y el impacto, es más
imperceptible; es por tal motivo, que su
identificación debe ser objeto de estudio en cada
inicio de proyecto y no se debe desconocer, la
necesidad de su implementación.
La seguridad de un producto de software está
determinada por una serie de factores, que
convergen desde su creación hasta su obsolescencia;
los protocolos de comunicación, la arquitectura del
sistema y la legislación, son una serie de elementos
para tener en cuenta, ya que pueden blindar el
desarrollo, prevenir y generar un protocolo de
acción, en caso de que se produzca un incidente que
atente contra la seguridad de la información. Pero,
¿cómo determinamos que posibles amenazas
pueden ser materializadas y afectar nuestro
desarrollo?, el análisis de riesgo es la respuesta que
nos permite contemplar un panorama y unos
objetivos más claros, que en consecuencia permite
trabajar en la metodología de aplicación, que puede
tener como punto de seguimiento las normas o
estándares existentes, como lo son las normas ISO
27005 e ISO 31000, u otras metodologías
comúnmente aceptadas, que ofrecen los conceptos
necesarios, para una correcta evaluación del riesgo
y su adecuación en el contexto del negocio y sus
interrelaciones con otras áreas. Las siguientes son
actividades y acciones, para tener en cuenta en un
análisis de riesgos [5]:
1) Definir el alcance, estableciendo las necesidades
coyunturales del proyecto.
2) Identificación de los activos, que participaran en
el proceso: infraestructura, software, talento
humano, etc.
3) Identificación de los requisitos legales y de
negocio, que son relevantes, para brindar soporte a
los activos y son propios de cada país, donde se
desarrolle el producto.
4) Identificación de posibles amenazas.
5) Identificar vulnerabilidades.
6) Evaluación del riesgo, que dependerá
directamente de las necesidades y posible impacto
de cada organización.
7) Documentar el análisis.
La identificación del riesgo es un factor
indispensable, para iniciar el proceso de
implementación de seguridad, es una condición
previa que permite dimensionar el alcance y la
necesidad del proyecto, estos valores nos permiten
cuantificar y dar un indicador, para la toma de
decisiones.
Cada vez que se realice un proyecto, es necesario
realizar una evaluación inicial y volver a retornar
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
5
este análisis en periodos de tiempo prudentes, con el
fin de poder identificar nuevos riesgos adyacentes y
revisar cómo se han venido manejando los que se
contemplaron en la etapa inicial. La calificación que
se le asigna a cada riesgo, está determinada en
función de la obtención del valor del índice de
probabilidad, de ser una amenaza x la magnitud del
daño y el resultado en el impacto en el activo que
está afectando, cada compañía elabora esto de
manera arbitraria; debido a que sus activos no están
en la misma escala de valor de otras compañías.
Fig. 3. Ejemplo de valoración del riesgo, obtenida de:
https://protejete.wordpress.com/gdr_principal/analisis_riesgo/
La valoración está comprendida en una escala
dada, de acuerdo con los criterios de evaluación de
cada organización, en la medida en que se tengan
identificados los riesgos (Ver Fig. 3) se podrán
establecer las medidas preventivas o correctivas
para dar tratamiento.
Al realizar el análisis de riesgo, la participación
de los diferentes procesos que interactúan en un
proyecto de desarrollo, son indispensables, como
resultado, los aportes que se realicen harán
extensibles esta evaluación y determinará con
mayor comprensión, los elementos que intervienen
en el proceso.
Algunas empresas dentro de sus diferentes áreas
de seguridad, ya cuentan con un plan para el control
de riesgos informáticos, en este se contempla su
evaluación y su tratamiento; se debe tener claro que
éste no necesariamente es aplicable para todos los
casos, es por eso, por lo que se recomienda siempre,
evaluar su aplicación específica, cada vez que
empiece un nuevo proyecto, para el desarrollo de un
producto o servicio en la compañía u organización.
V. MODELADO DE AMENAZAS
Con el análisis de riesgos podemos identificar las
vulnerabilidades inherentes, que se presentan al
momento de desarrollar un proyecto, el modelo de
amenazas está enfocado al desarrollo de
aplicaciones, su objetivo principal es ponernos en
los zapatos del defensor y atacante, como nos lo
indica OWASP[6]: “El modelado de amenazas es
una representación estructurada de toda la
información que afecta la seguridad de una
aplicación, en esencia, es una vista de la aplicación
y su entorno a través de las gafas de la seguridad”,
es decir, es un análisis más enfocado a la parte
técnica, sin que se llegue a revisar el código, pero sí
complementando el proceso de revisión de
seguridad. Según Microsoft [7], utilizar esta
estrategia trae unas ventajas que podríamos
enumerar de la siguiente manera:
1) Facilidad de comprensión de la aplicación.
2) Ayuda a detectar errores.
3) Ayuda a los miembros del equipo a entender la
aplicación con mayor profundidad.
4) Contiene información importante para que otros
equipos trabajen con la aplicación.
5) Resulta de utilidad para los evaluadores.
El modelado de amenazas permite tomar
decisiones, dando prioridad a los riesgos de
seguridad en la aplicación y tiene las siguientes
características:
A. Objetivos del Modelado de Amenazas
El objetivo es determinar los riesgos de
seguridad, que pueden aparecer en un producto de
software, aplicación o entorno, así como la forma en
cómo se materializan los ataques, identificando las
amenazas y que tipo de mitigación requieren.
El modelado de aplicaciones no es un análisis de
riesgos convencional que se aplica a un proyecto
general específico, es una herramienta que nos
ayuda a mejorar la arquitectura, diseño y
codificación de manera cíclica, enfocándonos en
adquirir características seguras en el desarrollo del
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
6
software.
B. Características del modelo de Amenazas
Cuando realizamos un modelado de amenazas
este debe ser capaz de:
1) Identificar amenazas inherentes al uso o
naturaleza de la aplicación.
2) Identificar Vulnerabilidades que podrían ser
explotadas, por un atacante o por mal uso del
recurso.
3) Obtener información de las contramedidas
necesarias, para mitigar el riesgo resultante de los
hallazgos encontrados o posibles escenarios.
4) Socializar el resultado del análisis a las
diferentes áreas y a los superiores encargados.
5) Poder establecer una estrategia, para minimizar
las brechas de seguridad encontradas en el análisis.
C. Proceso de Modelado de Aplicaciones
Según el proceso presentado por OWASP [8],
este se divide en tres pasos de alto nivel:
1) Descomposición de la Aplicación:
Comprender la lógica de la aplicación y su
interacción con los diferentes componentes, tanto
internos como externos; tener diseñados casos de
uso para determinar su alcance; generar diagramas
de flujo que visualmente proporcionen un modelo
detallado.
2) Determinar y Clasificar las amenazas:
Se debe categorizar las amenazas para
comprender la situación de parte del atacante, como
la perspectiva de defensiva; los flujos de procesos
identificados en la descomposición de la aplicación,
ayudan a darnos una vista de posibles objetivos,
como fuentes de datos y la interacción del usuario.
3) Determinar las contramedidas y la mitigación:
Las amenazas podrían materializarse cuando se
explota una vulnerabilidad, pero podrían mitigarse
con una contramedida; estas pueden mapearse en
una lista y se pueden clasificar de mayor a menor
según sea su impacto.
El proceso debe documentarse a medida que va
realizándose, con el fin de poder dar seguimiento y
brindar asistencia a las personas que intervengan
posteriormente, explicando los conceptos y las
medidas tomadas para mitigarlos. El análisis de
proyectos anteriores puede ser un punto de partida,
para identificar amenazas generales y evitar volver
analizarlas.
VI. PASOS PARA REALIZAR EL MODELO
DE AMENAZAS
El proceso de modelado de aplicaciones según las
recomendaciones de Microsoft [9], debe tomar en
cuenta los siguientes pasos para poder tener éxito en
su realización:
A. Recopilar información básica:
El claro entendimiento del funcionamiento de una
aplicación, es fundamental para poder determinar
las características y necesidades del sistema; esta
recopilación de datos nos permitirá, identificar el
campo de acción tanto en su infraestructura,
arquitectura de componentes, servicios, backend,
plugins, librerías de terceros o las librerías propias
del framework, que se dispone a utilizar como base.
Fig. 4. Diagrama del flujo de datos (DFD) de un Sistema de
facturación, obtenida de https://es.slideshare.net/ Yaskelly
Yedra/diagrama-de-flujo-de-datos-dfd-59486803
Una práctica común que se recomienda es
identificar las interacciones con un DFD (Diagrama
de flujos de datos) (Ver Fig. 4), que nos permita
tener un concepto general del comportamiento de la
aplicación, esta herramienta permite exponer
visualmente cómo se planteó el software y que
posibles caminos tendría, según las decisiones
tomadas, las selecciones realizadas y las entradas
de datos que tenga el sistema; este proceso debe
partir de un análisis profundo de la ingeniería de
software, que se realizó previamente, utilizando las
herramientas como recursos humanos, casos de uso,
lenguaje unificado de modelado, notación para el
modelado de negocios (BPMN), diagramas de flujo
(DFD), obtención de requisitos, análisis,
especificaciones, arquitectura, programación, etc.
Cuando se identifican los límites del campo de
acción del software, podemos ver un panorama
claro de las necesidades reales, que podrían
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
7
presentarse para el equipo de desarrollo y
optimizarnos para ajustarnos a las necesidades
reales del cliente final. Cuando se plantea el diseño
inicial de los diferentes flujos de proceso,
identificamos las dependencias externas y la
interdependencia entre los orígenes de datos
necesarios, para satisfacer las demandas del sistema,
esta visión global nos permitira dar seguimiento a
las acciones y planear las diferentes actividades, que
nos permitirán desglosar un cronograma en el cual
registramos las actividades; así mismo se crea la
necesidad de llevar un documento, en el cual se
registre la información de los hallazgos y poder
tener información retrospectiva, para futuros
proyectos (Ver Tabla I).
Tabla I.
Ejemplo levantamiento de información dependencias externas [10].
Dependencias Externas
ID Descripción
1
En el sitio web de la biblioteca de la universidad se
ejecutará en un servidor Linux, que ejecute Apache. Este
servidor se reforzará según el estándar de endurecimiento
del servidor de la universidad. Esto incluye la aplicación del
último sistema operativo y parches de seguridad, de la
aplicación.
2
El servidor de la base de datos será MySQL y se ejecutará
en un servidor Linux. Este servidor se reforzará según el
estándar de endurecimiento del servidor de la universidad.
Esto incluirá la aplicación del último sistema operativo y
parches de seguridad de la aplicación.
3 La conexión entre el servidor web y el servidor de la base
de datos, se realizará a través de una red privada.
4 El servidor web está detrás de un firewall y la única
comunicación disponible es TLS.
B. Crear y analizar el Modelo de amenazas
Una vez se cuente con la información concreta del
funcionamiento e interacción de la aplicación con
los demás componentes, es necesario establecer una
retroalimentación, por lo menos con uno de los
participantes del proceso de cada disciplina de
desarrollo; esta reunión se debe enfocar en
encontrar amenazas concernientes al flujo normal
de los procesos de desarrollo, pero en ningún
momento el objetivo es dar una solución.
Según Microsoft [9], el siguiente paso es analizar
el DFD e identificar los puntos de entrada, los
límites de confianza, desde su punto inicial hasta el
final de su última ubicación, con el objetivo de
poder obtener una idea global de donde podrían
presentarse las amenazas, como lo es la
suplantación de identidad, la manipulación de datos,
la repudiación, la revelación de información, la
denegación de servicio, etc., con el fin de poder
realizar una comprobación y/o revisión de la
arquitectura, validando que se encuentren cubiertas
la mayoría de las amenazas. Una vez realizado este
proceso, se debe generar un documento donde se
tipifique los hallazgos identificados, junto con su
respectiva codificación para controlar cada una de
las etapas efectuadas.
A continuación, definiremos los ataques más
convencionales según el top 10 OWAPS móvil:
1) Controles débiles de lado servidor:
No se puede definir como un ataque en sí, pero
sus consecuencias negativas radican en el hecho de
que el dispositivo móvil sea un punto de entrada,
para que el servidor sea vulnerado generando un
impacto y brecha de seguridad técnica, en él
servidor.
Mitigación: La mitigación posible radica
principalmente en los encargados de la instalación y
mantenimiento de la infraestructura, en donde se
debe implementar una técnica que le brinde
seguridad a los diferentes componentes, tales como:
hardening (Aseguramiento de servidores), pruebas
de lógica de negocio, autenticación con niveles de
seguridad fuertes, configuraciones de servidor
robustas y evitar a toda costa, utilizar
configuraciones por defecto.
2) Almacenamiento inseguro de Datos:
Al tener acceso a la información de un dispositivo
por técnicas descuidadas en el proceso de
desarrollo, es posible que un atacante pueda
obtener: nombres de usuario, tokens de
autenticación, contraseñas, cookies, datos de
localización, nombre del id del dispositivo,
información personal, datos de la aplicación, etc.
Mitigación: La primera forma de mitigar este
riesgo, es no almacenar información relevante en el
dispositivo; hay que tener en cuenta como
desarrollador, que la perdida de datos es un factor
de alta gravedad para él usuario y que puede
generar un daño en la reputación de la compañía.
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
8
Una de las recomendaciones más difundidas
para el proceso de autenticación de forma segura, es
hacerlo a través de web o API; cuando sea necesario
almacenar información en el dispositivo, ya que no
hay más alternativas viables, se aconseja la
utilización de librerías de cifrado que permitan
ofuscar la información.
Cuando sea necesario cifrar la información de las
bases de datos tipo SQLite, el mercado cuenta con
herramientas tales como SQLite Encryption
Extension [11] o wsSQLite [12] y en lo posible
desactivar los permisos de lectura y escritura, en las
memorias del dispositivo.
3) Bajos niveles de protección en la capa de
transporte:
Cuando se diseña una aplicación, en la mayoría
de los casos se interactúa a nivel de cliente servidor;
por tal motivo la información es expuesta en
internet y podría ser accedida por terceros, que
podrían utilizarla para fines inescrupulosos.
Mitigación: La recomendación que brinda
OWASP, para identificar si estamos siendo
vulnerables, es realizar un análisis de tráfico por
proxy, utilizando herramientas como lo son BURN
[13] o ZAP OWASP [14], que nos permiten
analizar la información del tráfico de red y con sus
resultados podríamos hacernos las siguientes
preguntas: ¿Las conexiones están cifradas?, ¿Los
certificados SSL están vigentes?, ¿La fortaleza del
SSL es lo suficientemente robusta para ser
difícilmente descifrada?, una vez definido estos
interrogantes, las medidas a aplicar podrían ser:
• Utilizar certificado SSL / TLS para realizar
transporte de información entre cliente - servidor.
• Evitar sesiones mixtas de SSL, para no exponer
información importante de inicios de sesión con
API de terceros.
• Utilizar algoritmos de cifrado fuerte, con
longitudes de clave adecuadas.
• No usar certificados auto firmados.
• Validar la identificación del servidor cuando se
realice la conexión, utilizando certificados
confiables.
• Informar al usuario cuando la autenticación no
cumpla con los parámetros de seguridad y se haya
rehusado el certificado.
• No enviar información confidencial por canales
no seguros.
• Cifrar la información por separado antes de
utilizar el SSL, para evitar que posibles
vulnerabilidades de este protocolo, expongan la
información sensitiva del usuario u organización.
4) Fuga Involuntaria de Datos:
La falta de conocimiento en la forma que un
sistema operativo utiliza sus componentes de
memoria, podría convertirse en una herramienta
para que terceros accedan a información sensible de
un usuario; las aplicaciones podrían almacenar en
cache o en cookies, datos para su reutilización y si
no se tiene el cuidado correspondiente, ésta
información estará expuesta a otras aplicaciones o
malware instalados, en el dispositivo.
Mitigación: Conocer más a fondo la utilización
que hace el sistema operativo de las herramientas
como la cache de url, la cache del teclado, el
portapapeles (copiar/pegar), el almacenamiento de
datos (localstorage), las cookies del navegador y los
datos de analitycs.
La capacitación en estos temas, permitirá utilizar
más adecuadamente los recursos del sistema y
determinar si la exposición de datos a este tipo de
tecnologías, es adecuada o es necesario obtener los
datos de una forma más segura.
5) Pobres mecanismos de Autorización y/o
autenticación:
La autenticación en un sistema y la forma en que
se autorizan los perfiles de los usuarios, en algunas
ocasiones son descuidadas por los desarrolladores;
esto implicaría un problema de seguridad, ya que le
permitira a un atacante conectarse anónimamente a
un servicio y suplantar su identidad.
Mitigación: Para prevenir problemas en la
autenticación y en la autorización de los usuarios,
podríamos considerar los siguientes factores:
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
9
• Cuando una aplicación web se transfiere a una
móvil, debe contar con los mismos mecanismos de
autenticación (token).
• No se deben almacenar datos locales de
autenticación, en lo posible todas las solicitudes de
autenticación que se hagan del lado del servidor,
deben utilizar canales seguros de cifrados.
• La autenticación persistente debe usarse
opcionalmente, pero no debe ser aplicada por
defecto.
• No se debe utilizar Pin de 4 dígitos para la
autenticación, debido a que un atacante utilizando
tablas arcoíris, podría llegar a conocer fácilmente la
contraseña del sistema.
• Se debe validar y/o realizar comprobaciones de
código, que permitan detectar cambios en la
estructura, a causa de un ataque de binarios, el cual
puede llegar a modificar los mecanismos de
autenticación de la aplicación.
6) Uso inseguro de Criptografía:
Un atacante podría obtener acceso a la
información sensible de un usuario u organización,
intentando vulnerar el sistema de cifrado, debido a
que el algoritmo usado no es robusto, o el proceso
utilizado para la encriptación no cumpla con unos
estándares mínimos, que ofrezcan un nivel de
protección adecuado, un manejo deficiente de las
llaves de encriptación, también es un factor de
vulnerabilidad, sin importar la efectividad y
fortaleza del algoritmo, que se utilice una mala
selección de este recurso puede desencadenar, en
que un atacante ingrese al sistema.
El uso de algoritmos propios de cifrado, también
es una mala práctica debido a que el nivel de
evaluación para comprobar su efectividad, podría
no ser el suficiente.
7) Inyección del lado del cliente:
Las aplicaciones en general tienen mecanismos
de entrada que permiten la interacción con el
usuario (input), en este proceso un atacante podría
enviar datos no confiables, que alteren el
funcionamiento esperado del sistema; estos datos
podrían estar mal formados y debido a la falta de
validación, los procesaría de una forma subyacente,
en un contexto diferente para el que fue diseñado.
Entre los ataques más comunes podríamos
encontrar:
• Inyección de SQL: Este ataque está enfocado a
ejecutarse en el contexto de una base de datos,
donde él atacante intenta agregar información a una
consulta SQL; desde una entrada de interfaz o
navegador tratando de acceder a la información del
sistema, por medio del incorrecto chequeo o filtrado
de variables (Ver Fig. 5).
Fig. 5.Ejemplo de ataque de inyección de SQL, obtenida de:
https://www.securityartwork.es/2013/11/21/evasion-de-
autenticacion-con-inyeccion-sql/
• Inyección de javascript (XSS): Los navegadores
móviles son también vulnerables a este ataque, que
consiste en inyectar código JavaScript por medio de
la barra del navegador (Ver Fig. 6), o encontrando
una vulnerabilidad de XSS (Cross-site scripting).
Fig. 6.Ejemplo de Ataque XSS, obtenida de:
https://dotnetcoretutorials.com/2017/10/25/owasp-top-10-asp-net-
core-cross-site-scripting-xss/
• Código Binario: Un malware u otra aplicación
maliciosa, podrían realizar un ataque binario contra
la capa de presentación (HTML, Javascript, CSS) y
ejecutar código malicioso, en tiempo de ejecución
de la aplicación.
Mitigación: Para mitigar este tipo de ataque, es
fundamental la correcta validación de los campos,
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
10
así mismo como la parametrización de los datos que
se envían a la base datos como consulta. Se debe
restringir los permisos a los navegadores móviles,
cuando se construye la aplicación para evitar que se
ejecuten archivos locales desde esta instancia.
8) Decisiones de seguridad a través de entradas no
confiables:
Las aplicaciones utilizan mecanismos de
autenticación, para diferenciar los usuarios de nivel
superior de los de nivel inferior. Una mala
implementación de IPC [3], podría permitir que un
atacante intercepte las llamadas y obtenga
información sensible del sistema.
Mitigación: Se debe usar listas blancas de
aplicaciones de confianza que validen la
comunicación entre procesos.
Validar de parte del usuario las acciones
sensibles que se ejecuten, a través de puntos de
entrada IPC.
Validar la información que se ingrese por IPC,
para evitar ataques dirigidos.
Evitar en lo posible transmitir información
sensible por canales IPC, para que no pueda ser
leída por terceros.
9) Manejo incorrecto de sesión:
Generalmente cuando realizamos operaciones
cliente servidor, se usan tokens para mantener el
estado sobre los protocolos HTTP y SOAP, cuando
existe una autenticación exitosa el servidor, entrega
una cookie de sesión que sirve para validar toda
operación, que se ejecute mientras el usuario se
encuentre logueado y se solicita para los diferentes
request de operación. El peligro de esta
vulnerabilidad, consiste en compartir esta
información a un tercero que podría suplantar
nuestra identidad.
Mitigación: Invalidar sesión no solamente en el
lado de la aplicación (front-end), sino también en el
servidor (back-end), el error de permitir este
comportamiento podría generar, que un atacante
obtenga la información de sesión y hacerse pasar
por el usuario, que ha finalizado su sesión desde el
dispositivo móvil.
• Falta de protección adecuada en el tiempo de
espera. Cuando una aplicación se ha logueado en un
servidor, tiene un tiempo de inactividad para cerrar
la sesión, con lo cual pierde validez el token de
sesión, así, se evita que un tercero pueda obtener
acceso y asuma el control del rol del usuario. Según
OWASP, se recomienda que el tiempo de
finalización de sesión por inactividad sea de 15
minutos en aplicaciones críticas, de 30 minutos en
aplicaciones de seguridad media y de 1 hora en
aplicaciones de baja seguridad. Actualmente
muchas aplicaciones mantienen su sesión iniciada,
para darle mayor facilidad a los usuarios y depende
únicamente del factor de autenticación que ofrece el
móvil (huella, pin, reconocimiento facial, patrón,
etc.); por esta razón, se debe analizar sí, estos
controles son suficientes o se deben agregar otros
mecanismos de autenticación; esto en si dependerá
directamente del criterio del desarrollador, la
necesidad del usuario y la criticidad de los datos.
• Restablecer cookies al generarse un cambio de
estado en la autenticación. Es necesario tener en
cuenta el cambio de estado de las cookies, para
destruirlas en el lado del servidor y no deben
aceptarse las de sesiones anteriores, que ya hayan
expirado en su validez.
• Generación de Tokens seguros. Los
desarrolladores deben utilizar métodos aceptados
que sean estándar, deben tener una longitud
apropiada, complejidad y pseudo aleatorios, para
evitar que sea fácil para un atacante adivinar el
patrón.
10) Falta de protección Binaria:
Un atacante podría realizar ingeniería inversa a
una aplicación, con el fin de entender su
funcionamiento y poder realizar cambios a nivel
binario; la mayor susceptibilidad radica en alojar en
el código en ambientes no seguros, que permitan
observar el funcionamiento en tiempo real del
aplicativo, tales como clientes móviles o el
firmware en los dispositivos. En términos prácticos,
cualquier aplicación instalada, en cualquier tipo de
dispositivo es vulnerable a un ataque de este tipo.
Mitigación: Para poder mitigar este tipo de
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
11
ataques es necesario tomar medidas, que detecten
cambios en la estructura del sistema operativo y del
código, tales como:
a) Controles de detección de jailbreak.
b) Controles de ckecksum.
c) Certificado de fijación de controles.
d) Controles de detección de depurador, que en
tiempo real detecte cambios en el código.
e) Desarrollar aplicaciones para evitar análisis de
ingeniería inversa con técnicas de análisis estáticas
o dinámicas.
C. Analizar las amenazas
Una vez completada la identificación de las
posibles amenazas que podría presentar el software,
se debe dar valor al riesgo de cada una de los
hallazgos encontrados, determinando posibilidad
del daño, posibilidad de reproducción de la
amenaza, posibilidad de poder explotar la
vulnerabilidad, usuarios afectados y su
descubrimiento en caso que se pueda materializar
un ataque, tomando las medidas necesarias para
poder mitigar el riesgo o aplicar las conductas
necesarias, que puedan ser documentadas
claramente para el equipo de trabajo.
D. Proceso Identificar técnicas y tecnologías de
mitigación
Una vez se han identificado las amenazas a las
que se encuentra expuesta la aplicación, se deben
determinar que posibles técnicas podrían aplicarse
para contrarrestar el efecto de un posible ataque.
En el numeral VI. B se puede identificar las
amenazas del TOP 10 de OWASP, en las cuales se
describen los factores más trascendentales, que se
pueden presentar en el desarrollo móvil y las
posibles buenas prácticas, que permitan mejorar los
aspectos de seguridad en estos temas, teniendo en
cuenta que la elección de las tecnologías, debe ser
enfocada a los objetivos de la empresa y
presupuestos aprobados para esta.
E. Documentar el modelo de seguridad
El éxito de aplicar un modelo TMA de análisis de
amenazas, consiste en la documentación de los
hallazgos que se obtienen al realizar todo el
proceso, este factor implica poder dejar evidencia
de todo el análisis, para que posteriormente pueda
ser utilizada para dar soporte, realizar pruebas,
efectuar control de calidad (QA) y ofrecerá ayuda,
técnica en el siguiente proceso de implementación
de la infraestructura, para la correcta ejecución de la
aplicación.
F. Implementar y probar Mitigaciones
Es fundamental que en caso de que se materialice
una amenaza, sea probado y ajustado el plan de
acción, para llegar a un punto final que proporcione
un nivel adecuado de protección, que mitigue
efectivamente el riesgo.
G. Mantener el modelo de amenazas sincronizado
con el diseño
Debemos tener claro que las aplicaciones tienen
un ciclo de vida, esto le permite ir en crecimiento y
agregar nuevos componentes, suprimir otros e
integrarse con nuevas tecnologías, es necesario estar
en una continua verificación, que permita identificar
nuevos hallazgos e ir ajustándolo, haciendo que el
sistema madure.
VII. CONTROLES
Para poder mantener un proceso de desarrollo
seguro, es necesario implementar controles que den
seguimiento y evaluación, que puedan medir la
eficacia de las medidas aplicadas; si nos apegamos a
la definición que brinda ISACA, la cual define el
control como el medio para gestionar el riesgo,
incluidas las políticas, procedimientos, directrices,
prácticas y estructuras organizativas, que pueden ser
de naturaleza administrativa, técnica o legal [15],
entendemos la necesidad de implementar
mecanismos, que nos ayuden a ponerlos en
funcionamiento, por esta razón podemos utilizar
como guía el numeral 14.2 de la sección de
controles de la norma ISO 27001. Algunos de los
más importantes son los siguientes:
A. Políticas de desarrollo Seguro
La organización debe estar completamente
comprometida, a realizar todo lo necesario para que
sus productos de desarrollo sean seguros, las
políticas permitirán erigir los lineamientos y serán
el punto de partida, para que todos los integrantes
del proceso tengan conciencia de que existe una
necesidad y compromiso, de ofrecer productos
confiables.
B. Procedimientos de Control
Las políticas son el punto de partida de cualquier
proceso que desee implementar seguridad, pero el
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
12
cómo aplicarlos se identifica en los procedimientos.
La compañía u organización debe mantener
manuales de las practicas que se deben realizar para
aplicar los modelos como el TMA y probar la
eficacia de estos, actualizándolos nuevamente
cuando se presenten cambios en la plataforma,
garantizando su correcto funcionamiento. Estos
procedimientos deben mantener unos principios de
desarrollo seguro, donde los integrantes del equipo
puedan socializar, entender la necesidad y se ajusten
a los lineamientos de la compañía.
C. Ambientes seguros de desarrollo
El éxito de que se mantenga la información y la
propiedad intelectual, radica en poder controlar los
entornos de desarrollo, cada organización debe
contar con herramientas que sean de tipo lógico y
físico, que mantengan a salvo los recursos utilizados
en las prácticas de desarrollo.
Además de los controles generales expuestos en
la norma técnica ISO 27001, OWASP nos brinda 10
controles generales, que podemos implementar para
el desarrollo de Software, los cuales se enumeran a
continuación:
1) Parchado.
2) Implementación de sistemas de Cortafuegos.
3) Validaciones en las entradas de los programas.
4) Escáner de vulnerabilidades.
5) Manejo adecuado y profundo de mensajes de
error.
6) Manejo y escalabilidad en los integrantes
proceso desarrollo.
7) Análisis de código seguro.
8) Analizar los procesos de seguridad de terceros.
9) Endurecimiento de la configuración de la base de
datos.
10) Capacitar al personal que desarrolle
aplicaciones, para escritura desarrollo seguro.
VIII. CONCLUSIONES
El desarrollo seguro, es una necesidad en toda
organización, la implementación es un proceso de
compromiso y debemos enfocarnos a cumplir con
una serie de requisitos, de los cuales podríamos
destacar como más importantes los siguientes:
1) Crear la conciencia de la necesidad de desarrollo
seguro.
2) Crear políticas que puedan dar bases para la
creación de todo el proceso.
3) Crear los procedimientos que puedan aplicarse en
cada etapa del desarrollo y sean la base de
seguimiento de los equipos participantes.
4) Identificar los riesgos inherentes a cada proyecto.
5)Crear un plan de mitigación de los riesgos
inherentes del proyecto.
6) Dar seguimiento y control en las etapas de
desarrollo.
7) Ajustar y corregir los lineamientos a medida que
avance el proyecto, buscando retroalimentar a los
integrantes en todas sus etapas.
8) Documentar todos los procesos, en cada etapa del
desarrollo del producto.
REFERENCIAS
[1] OWASP, «https://www.owasp.org,» [En línea]. Available:
https://www.owasp.org/index.php/About_The_Open_Web_Ap
plication_Security_Project.
[2] OWASP, «https://www.owasp.org,» [En línea]. Available:
https://www.owasp.org/index.php/Mobile_Security_Project_A
rchive#tab=Top_10_Mobile_Risks. [Último acceso: 24 05
2018].
[3] RAE, «REAL ACADEMIA ESPAÑOLA,» 2017. [En
línea]. Available: http://dle.rae.es/?id=A8mrPcH. [Último
acceso: 30 05 2018].
[4] Análisis de Riesgos I. O. f. Standardization, ISO/IEC
27001, Ginegra Suiza, 2013.
[5] OWASP, «https://www.owasp.org,» [En línea]. Available:
https://www.owasp.org/index.php/Category:Threat_Model
ing. [Último acceso: 24 05 2018].
[6] M. Corporation, «https://docs.microsoft.com,» [En línea].
Available: https://msdn.microsoft.com/es-
es/library/aa561499(v=bts.10).aspx. [Último acceso: 01 06
2018].
[7] OWASP, «https://www.owasp.org,» [En línea]. Available:
https://www.owasp.org/index.php/Application_Threat_Modeli
ng. [Último acceso: 27 05 2018].
[8] M. Corporation, «https://docs.microsoft.com,» [En línea].
Available: https://msdn.microsoft.com/es-
es/library/aa561499(v=bts.10).aspx. [Último acceso: 01 06
2018].
[9] J. A. Kreibich, «Sqlite,» hwaci, [En línea]. Available:
http://www.hwaci.com/sw/sqlite/ams.html. [Último acceso: 03
06 2018].
[10] u/blackpaw, «https://sourceforge.net,» [En línea].
Available: https://sourceforge.net/projects/wxsqlite/. [Último
acceso: 29 05 2018].
Universidad Piloto de Colombia. López Vargas Harry. Desarrollo de Aplicaciones Móviles con ISO 27001.
13
[11] PORTSWIGGER, «portswigger.net,» [En línea].
Available: https://portswigger.net/burp/. [Último acceso: 28 05
2018].
[12] OWASP, «https://www.owasp.org,» [En línea]. Available:
https://www.owasp.org/index.php/OWASP_Zed_Attack_Prox
y_Project. [Último acceso: 27 05 2018].
[13] ISACA, «ISACA.ORG,» [En línea]. Available:
https://www.isaca.org/Pages/Glossary.aspx?tid=2011&char=C
. [Último acceso: 01 06 2018].
[14] OWASP, «https://www.owasp.org,» [En línea]. Available:
https://www.owasp.org/index.php/Category:Control. [Último
acceso: 27 05 2018].
Autor:
Johann Harry Lopez Vargas Ingeniero de Sistemas de la
Corporación Universitaria Remington, Desarrollador de
Software de profesión, con experiencia de más de 5 años en
lenguajes de programación, desarrollando aplicaciones para
dispositivos móviles, entornos web y escritorio, participando
tanto en proyectos particulares como con entidades del estado,
desempeñándose actualmente en el sector financiero.