Learn the essentials of managing

compliance & ethics programmes

2017 INTERATIONAL BASIC

COMPLIANCE & ETHICS PLAN NOW TO

ACADEMIES
TAKE THE CCEP-I
®

CERTIFICATION
EXAM AFTER YOU
FROM THE SOCIETY OF CORPORATE COMPLIANCE & ETHICS
®
COMPLETE THIS
INTENSIVE TRAINING

10–13 JULY GET CERTIFIED

ENROLL NOW

SINGAPORE 9,800+
COMPLIANCE
REGISTER EARLY TO RESERVE YOUR PLACE PROFESSIONALS
LIMITED TO 75 FOR EACH ACADEMY HOLD A COMPLIANCE
CERTIFICATION BOARD
(CCB) CREDENTIAL
®

CLE APPROVED

SCCE Academies. Training more than 3,600

compliance and ethics professionals around the world.

corporatecompliance.org/academies
Questions: lizza.catalano@corporatecompliance.org
 The ISACA® Journal

Journal
tiene por objeto mejorar el
nivel de competencia y la
ventaja competitiva de sus
lectores internacionales,
proporcionando orientación
4 32 técnica y de gestión de autores
Materias seguridad de la información: ¿El final Aseguramiento de la seguridad en el SDLC para
del principio? la internet de las cosas experimentados globales. Los
Steven J. Ross, CISA, CISSP, MBCP Sivarama Subramanian, CISA, and Balaji
Swaminathan M., CISA, CISSP artículos son revisados por
7 pares y se centran en temas
Auditoría básica de SI: Gestión de datos 43 críticos para los profesionales
maestros: Un resumen para los auditores Protección de aplicaciones móviles con un enfoque
Ed Gelbstein, Ph.D. de ciclo de vida seguro para el desarrollo que intervienen en auditoría
Sakthivel Rajendran, CISA, CRISC, CISM,
CEH, GMOB de TI, gobierno, seguridad y
12
La red cumplimiento.
Jane Whitgift, CISM, MBCS MAS
53
14 Fuente de ayuda
Los aspectos prácticos: Mitigación de los Sunil Bakshi, CISA, CRISC, CISM, CGEIT, ABCI,
factores de riesgo de fracaso de un proyecto AMIIB, BS 25999 LI, CEH, CISSP, ISO 27001 LA,
de TI MCA, PMP
Vasant Raval, DBA, CISA, ACMA, and Rajesh Sharma,
Ph.D., ITIL-F, Six Sigma Black Belt 56
Palabras cruzadas
Myles Mellor
ARTICULOS
57
19 CPE Prueba
Gestionar el riesgo de IoT Kamal Khan CISA, CISSP, CITP, MBCS
Indrajit Atluri, CRISC, CISM, CEH, CISSP, CSSLP,
HCISPP, ITILv3 59
(Também disponível em português) Estándares, guías, herramientas y técnicas

S1-S4
27 ISACA Bookstore Supplement
IoT necesita una mejor seguridad
Hemant Patel, CISM, ITIL, PMP, TOGAF
Lea más acerca
(Também disponível em português) de los autores del
Journal...

Los blogs de los

escritores del Journal
estan en www.isaca.
Reconocimiento por
Traducción
org/journal/blog. Visita
el blog de ISACA
Journal, en términos
prácticos, para adquirir
ISACA le agradece al Capítulo de Chile por la traducción y la donación de la traducción de este volumen
conocimientos prácticos
del ISACA Journal. de colegas y participar en
la comunidad cada vez
Sr. Julian Rodrigo Davis Toledo, CISA, CISM Sr. Jorge Serrano Rodríguez, CISA, CRISC, mayor de ISACA.
Mr. Jorge Romero A, CISM CGEIT
Sr. Leonardo Vinett Herquiñigo, CISA Mr. Maximiliano Rojas Hinrichsen, CISM
Mr. Pablo Idiaquez Ríos Sr. Sergio Molanphy , CISM, CRISC
Sr. Fernando Méndez Erazo, CISA Sr. Pablo Caneo Gutiérrez, CISA, CRISC, CGEIT

3701 Algonquin Road,

Suite 1010
Rolling Meadows, Illinois
60008 USA
Discuss topics in the ISACA® Knowledge Center: www.isaca.org/knowledgecenter
Telephone
Follow ISACA on Twitter: http://twitter.com/isacanews; Hashtag: #ISACA +1.847.660.5505
Follow ISACA on LinkedIn: www.linkedin.com/company/isaca
Like ISACA on Facebook: www.facebook.com/ISACAHQ
Fax +1.847.253.1755
www.isaca.org
 ¿El final del principio?
En cada etapa de la evolución de la seguridad de
¿Tienes algo que la información, ha habido algún problema que ha
comentar sobre parecido insuperable: control de acceso, virus,
este artículo? hackers, fuga de datos, por nombrar algunos.
Visita las páginas del
Luego, poco a poco, la comunidad de profesionales
Journal en el sitio web
de ISACA® website de la seguridad de la información llegó a enfrentar
(www.isaca.org/ cada uno de estos problemas. No los eliminaron,
journal), encuentra el pero los contuvieron y los hicieron manejables.
artículo y hace click Después de todo, todavía nos enfrentamos a
en el link Comments accesos no autorizados, al desagradable malware,
para compartir tus a los script kiddies y a los datos mal utilizados, pero
pensamientos. somos capaces de seguir utilizando los sistemas de
información y, El-Fin-de-la Civilización-Tal-Como-la-
Conocemos-Hasta-Ahora no ha ocurrido, a pesar
de las frenéticas predicciones contemporáneas
sobre el caos.
El tema más reciente de la Brigada Doom and
Gloom son los ciber ataques1. Ahora bien, éstos
son realmente diferentes porque son intentos
intencionados, deliberados y maliciosos cuyo
objetivo es dañar a organizaciones específicas y
que son perpetrados por gobiernos, criminales y
terroristas con mucho tiempo, dinero y experiencia.
Pero estoy convencido de que, por más grande que
sea el problema, la comunidad de la seguridad de la
información contendrá y manejará el problema de los
ciberataques. Eventualmente, sí, ¿pero cuándo?
Steven J. Ross, CISA, CISSP, MBCP
Es director ejecutivo de Risk Masters International LLC. Ross ha
escrito una de las columnas más populares de la revista desde 1998.
Puede ser contactado en stross@riskmastersintl.com.
4 ISACA JOURNAL VOL 3
Bueno, quizá sea ahora. Con un poco de la valentía,
o de tontería, de sacar la cabeza por sobre el bunker,
y parafraseando a Winston Churchill, quisiera sugerir
que podríamos estar viendo no el principio del fin,
sino el final del principio2.
¿Qué nos aporta esta explosión de soleado
optimismo? IBM ha reportado estadísticas de
ataques cibernéticos que muestran un descenso
de 12.017 casos en el año 2014 a 1.157 casos en el
20153. La evaluación anual entregada por el Instituto
Ponemon, del costo de los ataques a la información,
indica que en Alemania y en los Estados Unidos la
tasa de aumento de los costos ha bajado durante
el período comprendido entre el 2013 y el 2015 y
realmente ha disminuido en Australia y en el Reino
Unido4. Symantec también publica un estudio anual
sobre las amenazas a la seguridad en Internet, en
donde informa un aumento del 2 por ciento en el
número de ataques a la información en el año 2015,
en comparación con el aumento del 23 por ciento
que fue observado en el año anterior5.
Ahora, una golondrina no hace verano, pero tres
informes de disminución de las tasas, o
disminuciones reales de éstas, pueden ser los
primeros indicadores de una tendencia. Por el bien
de este artículo supongamos que esto es así. Puesto
que podemos suponer razonablemente que los ciber
villanos (cyberbaddies) no han tenido un repentino
estallido de virtud, tal vez nosotros, que intentamos
prevenir los ciber ataques, estamos teniendo algún
efecto positivo. ¿Cuáles son algunas de estas cosas
que están creando esta tendencia favorable, si es que
es una tendencia?
Aceptación
Hace varios años escribí en este mismo espacio
que la aceptación de la amenaza de ciber ataques,
por parte de la alta dirección y los consejos de
administración, era la clave para generar los
presupuestos para contrarrestar estas amenazas6.
Existe una pequeña duda en mi mente de que
esto se haya logrado. Numerosos informes de
noticias, estudios de investigación y publicaciones7
han hecho que la realidad de los incidentes de
seguridad cibernética sea clara para aquellos que
gestionan el problema.
La comprensión no necesariamente conduce a la
acción, pero creo que en este caso sí lo ha hecho.

Como profesional veterano de la seguridad de la
información, creo se han hechos los preparativos
para enfrentar la seguridad cibernética. Por sí
mismos, los informes de los medios de comunicación
no convencieron a los tomadores de decisiones
de que se necesitaban adoptar contramedidas.
En todo caso, plantearon preguntas sobre por qué
las salvaguardias existentes eran insuficientes.
Pero cuando se dio el caso, la aceptación de la
existencia de las amenazas cibernéticas, mostró a
la administración de la seguridad de la información
tener una audiencia receptiva.
Tecnología
Donde se haga dinero, el mercado responderá, y
así ha sido. Hay cientos de productos y servicios
disponibles8 que pretenden ser la solución a los
ciberataques. Muchos de ellos, como he descubierto,
los productos para la ciberseguridad son meramente
un reempaquetado de herramientas y tecnologías
ya existentes, pero este dato es relativamente poco
importante. Esas tecnologías no fueron previamente
compradas, implementadas y utilizadas (o al menos
no) para fines de seguridad cibernética. Si para
poner las herramientas adecuadas en manos de las
personas adecuadas se necesita poner una nueva
etiqueta brillante y contar con un vendedor ávido, eso
está bien para mí.
Al analizar el mercado veo que, de aproximadamente
un tercio de los principales productos proporcionan
prevención cerca de un cuarto son para detección y
análisis y el resto se distribuye entre la administración
de riesgos, servicios y pruebas. Sorprendentemente,
para mí al menos, no existen en el mercado
productos para la recuperación de ciberataques.
Creo que allí hay una gran oportunidad de ofertar
productos, sí una significativa, si hay compradores
esperando a que el mercado responda.
En muchas organizaciones, la seguridad de la
información y la recuperación de desastres se
encuentran en diferentes cadenas de mando, y
los fondos presupuestados no están fluyendo en
la dirección de la recuperación. Quizás es solo
que la promesa de la prevención sobrepasa a la
realidad, que incluso las agencias del gobierno
y las compañías muy bien protegidas igual han
experimentado ciber ataques. No importa cuán
fuertes sean las herramientas preventivas y las de
detección, a los atacantes les sobra el tiempo, el
dinero y la paciencia. Los ataques suceden tanto a
los que están bien preparados como a los que están
desprotegidos, por lo que la ciber-recuperabilidad
necesita ser parte del arsenal de cada organización
materias
seguridad
de la información
La nube
Cada vez más organizaciones están migrando más
¿Te gusto este
y más aplicaciones e infraestructuras a la nube. Esto artículo?
puede ser un poco más de externalización o bien
puede ser una revisión completa de sus arquitecturas • Lee Transformando
de TI, pero parece que la ida a la nube ha traído un la Ciberseguridad.
efecto secundario positivo, tal vez involuntario: la www.isaca.org/
seguridad se ha mejorado. cybersecurity-cobit
Los proveedores de servicios de TI externalizados
tienen un interés estratégico en la seguridad de la
información en general y un interés específico en
la seguridad cibernética. La mayoría de nosotros,
profesionales de la seguridad de la información,
ofrecemos soporte para sistemas de información
que, a su vez, soportan procesos empresariales.
No hacemos préstamos, ni fabricamos acero ni
dulces para ganarnos la vida; ayudamos a que la
información que los empresarios usan sea más
confiable y que esté disponible. Incluso, si se rompe
la seguridad de la información, los productos igual
conserven su valor. Los proveedores de la nube
están en el negocio de los sistemas de información
y los sistemas son sus productos. Por lo tanto, las
infracciones a la seguridad, especialmente aquéllas
en las que los datos de los clientes terminan en
manos nefastas, socavan el potencial de mercado
de las mismas compañías de la nube. Como dijo un
colega mío, si eso es lo que se necesita para llegar al
principio del fin, yo estoy de acuerdo.
Los servicios en la Nube y el Software como
un Servicio (SaaS)…claramente tienen los
recursos y las capacidades para proporcionar
ambientes seguros. Sus recursos técnicos en
muchos aspectos no tienen precedentes, como
lo demuestra la forma en que los proveedores
En muchas organizaciones,
la seguridad de la información
y la recuperación de desastres
se encuentran en diferentes
cadenas de mando, y los fondos
presupuestados no están
fluyendo en la dirección de la
recuperación.
ISACA JOURNAL VOL 3 5
 de Nube y SaaS han desarrollado sistemas
innovadores, utilizando servidores genéricos
de bajo costo, que ahora amenazan a los
negocios de los bien capitalizados principales
líderes en tecnología. Presumiblemente, ellos
también tengan la capacidad para asegurar
sus servicios y datos. Ellos tienen, también,
un incentivo comercial. Una violación de
seguridad en una Nube o en un SaaS traería
al vendedor no sólo un riesgo financiero, legal,
reputacional y regulatorio, sino también un
riesgo existencial9.
Si eso es lo que se necesita para llegar al principio
del fin, yo soy todo para ello.
Notas Finales
1 Ross, S., “The Train of Danger,” ISACA®
Journal, vol. 5, 2011, www.isaca.org/archives/.
Myself included, no one who can write an article
called “The Train of Danger” has any right to
point fingers at others. But I shall point anyway.
2 Churchill, W.; “The Bright Gleam of Victory,”
speech delivered to the Lord Mayor’s Day
Luncheon at the Mansion House, London,
England, 10 November 1942. The exact quote
is, “Now this is not the end. It is not even the
beginning of the end. But it is, perhaps, the end
of the beginning.”
3 IBM Security, Reviewing a Year of Serious
Data Breaches, Major Attacks and New
Vulnerabilities, USA, 2016, p. 5. IBM defines
an attack as, “A security event that has been
identified by correlation and analytics tools as
malicious activity that is attempting to collect,
disrupt, deny, degrade or destroy information
system resources or the information itself.”
4 IBM, 2016 Ponemon Cost of Data Breach
Study: Global Analysis, 2016, p. 5,
www-03.ibm.com/security/data-breach/
5 Symantec, 2016 Internet Security Threat Report,
April 2016, p. 9, https://www.symantec.com/
security-center/threat-report
6 Ross, S., “Bear Acceptance,” ISACA Journal,
vol. 4, 2014, www.isaca.org/archives
7 ISACA®, Cybersecurity: What the Board of
Directors Needs to Ask, USA, 2014
8 See the list of the top 500 in 2016 at
www.cybersecurityventures.com.
9 Cytryn, A., et al; “Hackers, Snoopers and
Thieves: How to Handle the Latest Threats,”
The Journal of Corporate Accounting and
Finance, July/August 2014, p. 49–50

ASK
how you can make more
connections locally and globally
with ISACA’s Member Advantage.

Members know that community
counts! ISACA’s Member
Advantage helps connect you with
over 150,000 professionals in more
than 180 countries. Network locally
through your chapter and meet
like-minded people who can enhance
your skills, connections, business
development efforts and future
prospects for employment.
ACCESS includes special opportunities that only
members can receive:
• Insights from Global Conferences with thought leaders
• Invitations to online career fairs—connect with hiring
managers at top companies
• Professional networking through local and global
events—be sure to get your member discount!
• NEW Volunteer opportunities on the 2017 horizon
• Professional and Industry Advocacy
And members have access to 72 FREE CPEs in 2017!

ASK to see all of the access you will gain as

a member at www.isaca.org/justask

6 ISACA JOURNAL VOL 3


Gestión de datos maestros
Un resumen para los auditores
Esta columna es la contribución final de
Fundamentos de la Auditoría de SI de Ed
Gelbstein, Ph.D., a ISACA Journal. Él fue
columnista del volumen 1 de 2015 al volumen
3 del 2017 de Fundamentos de la Auditoría
de SI. Debido a su deseo de compartir sus
conocimientos profesionales y su prolífica
escritura, antes de su muerte, en julio de 2015,
Gelbstein escribió y contribuyó a ISACA Journal
con bastantes artículos para completar hasta
ahora esta columna. ISACA está profundamente
agradecido de Ed Gelbstein y su esposa Cora
por sus continuas y valiosas contribuciones de
conocimiento y experiencia a los lectores de
ISACA Journal, antes y después de su muerte.
En una columna anterior se revisaron los dominios
de las auditorías de datos e información1. Esta
columna sigue explorando este tema centrándose
en la Gestión de Datos Maestros2 (DMBOK) y lo que
esta no cubre. El DMBOK debe ser tomado como
un complemento a la guía ofrecida en COBIT 5 de
ISACA: Habilitando la Información3.
Sin los datos, las aplicaciones y las tecnologías
de la información son inútiles. A menudo nos
referimos a los datos como un “activo corporativo
clave” y sin embargo, siendo intangibles, no
siempre se gestionan como si tuvieran valor.
Además, los temas relacionados a gobernanza y
gestión de datos son complejos y no siempre son
comprendidos por el departamento de TI o los
propietarios de los datos (o, en otra terminología,
los administradores o custodios).
Es probable que los puristas y los especialistas
discrepen con las siguientes declaraciones:
• No puede haber conocimiento sin información.
• No puede haber información sin datos.
• Los datos representan “cosas” que pueden ser
observadas, medidas, compartidas y registradas.
Aunque sea difícil probar, podemos suponer que
la prehistoria humana fue rica en conocimiento e
información. Las primeras sociedades humanas,
Auditoría
basica
de SI
después de todo, sobrevivieron, se desarrollaron y se
extendieron por el mundo por tierra y por mar. Esto ¿Tienes algo que
no se puede explicar sólo por casualidad. comentar sobre
este artículo?
Visita las páginas del
Los registros más antiguos que se conocen son las
Journal en el sitio web
pinturas rupestres en cavernas, por ejemplo, Lascaux
de ISACA® website
y Chauvet4 en Francia, esta última se estima tiene
(www.isaca.org/
36.000 años de antigüedad, contiene impresionantes
journal), encuentra el
dibujos hechos por una razón desconocida. Estas
pinturas se convirtieron gradualmente en medios para artículo y hace click
representar el lenguaje en formas gráficas5 teniendo, en el link Comments
las más tempranas de ellas (Sumerias y Egipcias), para compartir tus
pensamientos.
alrededor de 5.000 años de antigüedad.
La alfabetización masiva (lectura y escritura)
continúa expandiéndose por el mundo, pero aún
no se ha alcanzado el 100 por ciento. A pesar de
este crecimiento, muchas personas siguen siendo
funcionalmente analfabetas, incapaces de dar
sentido, por ejemplo, a un formulario de impuesto a la
renta y a las pólizas de seguro, sin mencionar textos
complejos relacionados con algún tema.
Cuando se trata de datos, con miles de millones de
personas teniendo acceso a Internet y a las redes
sociales, todo el mundo es un potencial creador
de contenido. Muchos proporcionan información
de calidad, mientras que otros se sienten libres de
expresar opiniones, chismes, mala información y
desinformación. Los datos de mala calidad deben
ser tratados como la basura de la sociedad de la
información, y el verdadero problema es la capacidad
para separar los elementos de calidad de la basura.
La alfabetización en la calidad de los datos y la
validación de estos tiene un largo camino por
Ed Gelbstein, Ph.D., 1940–2015
Trabajó en SI/TI, tanto en el sector público como en el privado, en varios países
por más de 50 años. Gelbstein hizo desarrollo analógico y digital en la década de
1960, incorporando computadores digitales en el sistema de control para procesos
continuos a finales de los años 60 y principios de los 70, y administró proyectos de
gran tamaño y complejidad hasta principios de 1990. En los años 90, se convirtió en
un ejecutivo de los pre-privatizados ferrocarriles británicos y luego proveedor global
de comunicaciones informáticas y de datos en las Naciones Unidas. Después de
su (semi) retiro de la ONU, se unió al equipo de auditores del Consejo de Auditores
de las Naciones Unidas y a la Oficina de Auditoría Nacional Francesa. Gracias a su
espíritu generoso y su escritura prolífica, su columna continuará siendo publicada en
el Diario Póstumo de ISACA Journal.
ISACA JOURNAL VOL 3 7
 recorrer. Esto es igualmente cierto en el entorno temas, y el DMBOK es un marco integral que discute,
corporativo, ya que las empresas manejan sus en varias secciones bien estructuradas (áreas
propias colecciones de datos, sin hablar de los de conocimiento) que abarcan varios cientos de
grandes datos, la inteligencia de negocios y otros páginas, asuntos de gobernanza de datos.
servicios que requieren datos de múltiples fuentes.
El DMBOK
Para hacer las cosas más difíciles, la responsabilidad
de los datos no siempre es compartida entre los Publicado por primera vez en el año 2009, el
dueños y SI/TI. La calidad de los datos y la gestión DMBOK presentó una guía coherente y completa
del ciclo de vida, desde la adquisición hasta la sobre las mejores prácticas en la gestión de
eliminación, son asuntos empresariales (al igual datos. En el año 2012 se actualizó para reflejar
que la clasificación de datos, las reglas de acceso el crecimiento explosivo de datos, problemas de
basadas en roles, etc.), mientras que las TI se seguridad y nuevos servicios como la nube, y para
ocupan de implementar la gestión de identidades, añadir varios temas que no fueron incluidos en la
la seguridad física y lógica, los respaldos, la primera edición.
recuperación ante desastres, etc. A menudo el
diálogo entre estas partes deja mucho que desear. Sería bueno si las 430 páginas de la publicación
del año 2012 pudieran ser resumidas en algo fácil
Los auditores están en una posición ideal para de asimilar. Las ilustraciones en esta columna
determinar la efectividad de estas responsabilidades intentan hacer exactamente eso en una sola página
compartidas e identificar las áreas donde el riesgo del en forma de un mapa mental7, que se muestra en
negocio podría ser aún más mitigado. la figura 1. ¿Está completo? Ciertamente no, pero
muestra las 10 áreas de conocimiento cubiertas y
La familia de productos COBIT 5 incluyen una los principales elementos discutidos en ellas.
publicación especial6 que cubre algunos de estos

Figura 1—Comtenido del DMBOK

Definir requisitos de la calidad de los datos Taxonomías

Analizar y evaluar la calidad de los datos Establecer la arquitectura Namespaces
Definir métricas para la calidad de los datos Metadatos
Definir reglas de negocio para la calidad de datos Calidad de Datos Arquitectura de Datos
Medir y monitorear la calidad de los datos Diseñar e implementar Modelo de datos empresarial
Tratar problemas de la calidad de los datos Arquitectura base de datos
Limpiar y corregir defectos de la calidad de los datos Tipo de arquitectura para el lugar de la solución
Entidad relación
Entender los requisitos de los metadatos Lenguaje de Modelamiento Unificado (UML)
Análisis y diseño
Definir la arquitectura de los metadatos Modelamiento y Desarrollo Objeto rol
Definir y mantener estándares para los metadatos de Datos NoSQL y otro…
Implementar entorno de metadatos administrado Diseño detallado de datos
Crear y mantener los metadatos Metadatos
Integrar los metadatos Tipos de bases de datos y sistemas de archivos
Repositorios de metadatos administrados Gobernanza Soporte base de datos
Distribuir los metadatos de Datos Almacenamiento de Datos Gestión de la configuración
Consultar, informar y analizar los metadatos y Operaciones Virtualización y cloud
Habilitación de la Información COBIT 4.5 Integridad de los activos de datos
Comprender necesidades de la información BI
Definir y mantener DW y arquitectura BI
Data Warehousing e Inteligencia de Negocio
Implementar DW y data marts Clasificaciones de seguridad de datos
Implementar herramientas de BI e interfaces Requerimientos normativos de datos
Monitorear y sintonizar la actividad y rendimiento de BI Evaluación vulnerabilidades de la base de datos
Seguridad de Definir sensibilidad de los datos en los metadatos
Habilitación de la Información COBIT 4.6 los datos Definir políticas y procedimientos de seguridad de datos
Fuentes y colaboradores Gestionar el acceso a los datos
Datos de Referencia
Definir y mantener reglas de juego y Datos Maestros Seguridad de los datos de auditoría
Definir y mantener jerarquías y afiliación
Necesidades de integración de datos maestros y referencia
Gestión de Documentos y Contenido Arquitectura de integración de datos
Planificar e implementar la integración de nuevas fuentes de datos
Integración de datos e
interoperabilidad Replicar y distribuir datos maestros y referencia
Virtualización
Ver también COBIT Habilitación de la Información
Gestionar cambios

Fuente: E. Gelbstein. Reimpreso con permiso.

8 ISACA JOURNAL VOL 3

Presentado de esta manera, este gráfico contiene
Figura 2—Plantilla para el resumen del área
más detalles que el gráfico circular del texto
de conocimiento en DMBOK
DMBOK (un círculo dividido en 10 segmentos con
sólo un título). También es más fácil ver el todo a
la vez hacerlo mediante la lectura de la tabla de
Área de Conocimiento
contenido.
Definición: Qué es y qué hace
Una característica útil de ambas versiones de la
DMBOX es que cada capítulo, es decir, cada área Objetivo de las Áreas de Conocimiento
de conocimiento, comienza con un diagrama de
resumen utilizando la plantilla que se muestra en la
figura 2. Entradas Proceso Entregables
Entrada 1… Actividad 1… Salida 1…
Esto proporciona un resumen de cada área de Entrada n… Actividad n… Salida n…
conocimiento que facilita el estudio completo del
DMBOK. Curiosamente, el DMBOX no necesita
ser leído secuencialmente, ya que cada área de Métricas
Funciones de Funciones de
conocimiento está auto-contenida e invita a un
enfoque de estudio “en el momento justo”, en lugar los Proveedores Métrica 1… los Usuarios
Métrica n…
de un enfoque “por si acaso”. Rol 1… Rol 1…
Rol n… Rol n…
Lo nuevo de DMBOK, en la versión del año 2012,
es la evaluación de la madurez de la gestión
de datos, basado en la ISO/IEC 15504 de la Función Funciones Partes
Organización Internacional de Normalización Responsable Interesadas
(ISO)/Comisión Electrotécnica Internacional (IEC),
Rol 1… Rol 1…
Tecnología de la información–Evaluación de
Rol n… Rol n…
procesos. La publicación de COBIT Modelo de
Evaluación de Procesos (PAM): El uso de COBIT 5, Fuente: E. Gelbstein. Reimpreso con permiso.
es igualmente aplicable.
Un marco de valoración de datos9 agrupa los
Qué no Está en DMBOK
datos de una manera que identifica su importancia
En el DMBOK no están cubiertos dos temas para el negocio y, por tanto, el grado en ellos que
relevantes: la asignación de valor a los datos y la necesitan ser protegidos y recuperados:
gestión de datos de auditoría. • Misión crítica—Frecuentemente usados,
deben tener una disponibilidad muy alta. Si se
Asignación de Valor a los Datos corrompen o revelan puede tener un impacto
En el nivel más bajo, los valores de datos alto e inmediato en la empresa (financiero,
cualitativos, consisten en palabras mientras que operacional, reputacional, posiblemente legal).
los valores de datos cuantitativos consisten en
números, idealmente números financieros ya que • Negocio crítico—Uso frecuente, alta
pueden ser usados para apoyar evaluaciones del disponibilidad, si son divulgados tiene un impacto
retorno de la inversión (ROI) de tecnologías de base significativo a largo plazo
de datos, almacenes de datos, aplicaciones de • Esencial—Se utilizan periódicamente, están
inteligencia empresarial, iniciativas de seguridad de disponibles en un tiempo definido, si son revelados
datos, etc. El lector interesado podría considerar el es posible que tenga un impacto a largo plazo
libro de Douglas Hubbard sobre cómo medir algo8.
Si bien la clasificación de datos en categorías tales • Consecuencial—Utilizados ocasionalmente,
como público, restringido y confidencial está bien disponibles por un período de tiempo largo,
establecida, esto no asigna el valor comercial, por impacto financiero u operativo improbable si
ejemplo, de propiedad intelectual. son revelados, pero posibles problemas de
cumplimiento

ISACA JOURNAL VOL 3 9

 • No crítico—Rara vez utilizados, disponibilidad
no crítica, con un mínimo o ningún impacto en el
¿Te gusto este
negocio si se revelaran
artículo?
• No importante—Utilizado solo a petición,
• Aprenda más disponibilidad no crítica, con un mínimo o sin
acerca, discute ningún impacto en el negocio si se revelaran
y colabora sobre • Desechable—No se usan, sin impacto (y, sin
herramientas de
embargo, se mantienen en grandes cantidades
auditoria y técnicas
como datos oscuros)
en el Centro de
Conocimiento. En el Blog de Gartner existe una cita interesante
www.isaca.org/ sobre los datos oscuros: “Datos oscuros” es el
it-audit-tools-and- nombre lindo que se les da a todos los datos que
techniques una organización reúne y que no forman parte de
sus operaciones cotidianas. Es algo antiguo, cosas
que aparecieron en el correo que guardaste, “por si
acaso”. Se trata de datos que no borraste porque
“podrían ser útil en algún momento”10. Y, como dice
el blogger, los datos oscuros son el sueño de un
proveedor de almacenamiento.
Auditoría de la Gobernanza de Datos
A fin de auditar la gobernanza de datos, uno
podría considerar el Marco de Auditoría de Datos11
desarrollado por el Instituto de Tecnología e
Información Avanzada de Humanidades (HATII) de
la Universidad de Glasgow (Escocia, Reino Unido)
10 ISACA JOURNAL VOL 3
y su metodología DAF (Data Audit Framework)
asociada, ambos disponibles para descarga
gratuita12.
Además, los auditores pueden confiar en el
DMBOK y COBIT 5: Habilitando la Información13
para formular un plan de auditoría que examine:
• Cuáles de las 10 áreas de conocimiento han sido
implementadas
• El grado en que las sub áreas individuales han
sido implementadas
• El grado en que se definen e implementan las
funciones y responsabilidades de las distintas
partes que se muestran en la figura 2
• La madurez evaluada de los distintos procesos
del área de conocimiento
Conclusiones
Si los datos son realmente un recurso corporativo
tendría sentido manejarlos como tales. Entonces,
¿cómo la administración puede seguir justificando
una situación en la que los datos oscuros duplican los
datos críticos de la misión y del negocio, donde la
gobernabilidad de los datos es débil y los grandes
datos siguen dominando los medios? Por el
contrario, los muebles antiguos de oficina, que están
almacenados en un sótano, tienen asignado un
código de barra y se inventarían y se muestran como
activos en las cuentas contables.
Notas Finales
1 Gelbstein, E., “The Domains of Data and
Information Audits,” ISACA® Journal, vol. 6,
2016, www.isaca.org/journal/archives
2 The Data Management Association, DAMA-Data
Management Body of Knowledge Framework,
6 March 2014, https://www.dama.org/sites/
default/files/download/DAMA-DMBOK2-
Framework-V2-20140317-FINAL.pdf
3 ISACA®, COBIT® 5: Enabling Information, USA,
2013, www.isaca.org/COBIT/Pages/COBIT-5-
Enabling-Information-product-page.aspx
 4 La Grotte Chauvet-Pont d’Arc, Ardeche,
http://archeologie.culture.fr/chauvet/
5 Robinson, A.; The Story of Writing: Alphabets,
Hieroglyphs & Pictograms, Thames & Hudson,
UK, 2007
6 Op cit, ISACA
7 Buzan, T.; B. Buzan; The Mind Map Book:
How to Use Radiant Thinking to Maximize Your
Brain’s Untapped Potential, Plume, USA, 1996
8 Hubbard, D. W.; How to Measure Anything:
Finding the Value of “Intangibles” in Business,
Tantor Audio, USA, 2014
9 Croy, M.; “The Business Value of Data,” Disaster
Recovery Journal, 22 November 2007,
www.drj.com/journal/summer-2004-volume-17-
issue-3/the-business-value-of-data.html
10 White, A.; “Dark Data Is Like That Furniture You
Have in That Dark Cupboard,” Gartner Blog
Network, 11 July 2012, http://blogs.gartner.com/
andrew_white/2012/07/11/dark-data-is-like-that-
furniture-you-have-in-that-dark-cupboard/
11 Jones, S.; A. Ball; C. Ekmekcioglu; “The Data
Audit Framework: A First Step in the Data
Management Challenge,” International Journal
of Data Curation, vol. 3, no. 2, 2008
12 Jones, S.; S. Ross; R. Ruusalepp; “Data
Audit Framework Methodology,” Humanities
Advanced Technology and Information Institute,
University of Glasgow, Scotland, United
Kingdom, 2009, www.data-audit.eu/DAF_
Methodology.pdf
13 Op cit, ISACA

Pinpoint your next job opportunity

with ISACA’s CareerLaser
ISACA’s CareerLaser newsletter offers monthly updates on the latest jobs, top-of-mind industry news,
events and employment trends to help you navigate a successful career the information systems industry.
Let CareerLaser become your top resource for quality jobs matched specifically to your talents in audit,
assurance, security, governance, risk management and more.

Subscribe today by visiting www.isaca.org/careerlaser

Visit the ISACA Career Centre at www.isaca.org/careercentre to

find additional career tools, including access to top job candidates.

ISACA JOURNAL VOL 3 11

 Q: ¿Cómo piensas
que el rol de los
profesionales de
seguridad de la
información está
cambiando o ha
cambiado?
A: En el cambio de
siglo, la seguridad de
TI era un rol que estaba
comenzando a volverse
más predominante. Sin
embargo, mucha gente
en estos roles tenía pocas
cualificaciones externas.
Los equipos de seguridad
eran parte de la función
de TI teniendo a otros
profesionales de TI como
principales clientes para
asesorar, y muchas de
estas personas eran
entusiastas tecnológicos
(techies). Cualquier factor
de riesgo de seguridad
de TI solo era parte de un
registro de riesgos de TI.
Las compañías ahora
requieren que sus
profesionales de seguridad
tengan cualificaciones
externas para demostrar
su conocimiento y
profesionalismo. En
varias organizaciones
la seguridad de TI ya
no se encuentra dentro
de la organización de
TI sino integrada con
otros equipos de riesgos
del negocio. Dentro del
equipo de seguridad
los profesionales están
teniendo que desarrollar
un entendimiento más
amplio del liderazgo y
habilidades de negocio,
regularmente teniendo
conversaciones con
líderes de negocio y
miembros del directorio
explicando amenazas,
Jane Whitgift, CISM, MBCS riesgos y acciones
es una profesional de seguridad de la información con más mitigantes. La mayoría
de 30 años de experiencia en TI y 15 años de especialidad de las compañías ahora
en seguridad de TI. Ella es la dueña y principal consultora tienen el riesgo asociado
de Whitgift Security, la cual fundó en 2013. Su experiencia con amenazas de
previa incluye haber trabajado como oficial ejecutivo ciberseguridad en sus
de seguridad de la información con responsabilidades 10 factores de riesgo
globales de riesgos en seguridad de TI e implementación del negocio, con los
de programas para mejorar la seguridad y los roles de las miembros del directorio
compañías del índice FTSE 100. discutiéndolos varias
veces al año.
12 ISACA JOURNAL VOL 3
Q: ¿Cómo es que
desarrollaste tu carrera
en ciberseguridad y
has logrado un balance
entre tu vida laboral y
tu vida personal como
un padre trabajador?
A: Como principal
proveedor para mis hijos,
cuando ellos nacieron las
aspiraciones de mi carrera
se pausaron. Cuando mis
hijos tuvieron la edad de
prescolar, fue más fácil
trabajar tiempo completo.
Durante este tiempo me
he esforzado duro para
minimizar los viajes de
trabajo, comúnmente bajo
viajes de todo el día a los
Estados Unidos.
A medida que mis hijos se
hicieron grandes, regresar
del trabajo a las 7 p.m.
no funcionó. Tras mucha
deliberación, pregunté
si podía trabajar tiempo
parcial. Tuve un empleador
empático y convenimos un
acuerdo flexible.
Durante la etapa escolar
trabajé días cortos que
coincidieran con el día
de escuela. Y durante
las vacaciones escolares
trabajé días normales, solo
que menos. A través de
los ocho años que trabajé
tiempo parcial, me moví de
un 60 por ciento a un 90
por ciento a medida que
mis hijos fueron creciendo
y pasaban más tiempo
en la escuela. Mientras
colegas y gerentes
cercanos sabían que yo
trabajaba tiempo parcial,
yo dudo que los clientes
con los que trabajé se
dieran cuenta que estaba
trabajando tiempo parcial.
Durante la primera mitad
de mi carrera corporativa,
tuve un rango de roles
estándares de TI. Al
moverme a tiempo
parcial, me convertí
en un consultor de
operaciones, tomando
tres roles relacionados de
coordinador de seguridad
de TI, gestor TI de
cambios y coordinador de
planificación de desastres.
Cuando la compañía para
la que trabajé estableció
su función de seguridad
de TI, fui invitada a formar
parte de este equipo. Sin
conocer mucho al equipo
senior de gestión de
seguridad, ellos estaban
inciertos de qué hacer con
una persona que trabajaba
tiempo parcial.
Fui nombrada el gerente
del conocimiento—
responsable de diseñar,
implementar y dar soporte
a la seguridad de TI del
sitio web para su uso a
través de la compañía
y diseñé cursos de
capacitación para los
usuarios finales. A medida
que la administración
entendió mi compromiso
y capacidades, me moví
a un rol de consultor
de seguridad, y al poco
tiempo me nombraron
oficial en jefe de seguridad
de la información (CISO
por sus siglas en inglés)
para las funciones del
negocio. Por los primeros
tres años que estuve
desempeñando el rol,
trabajé de tiempo parcial.
Mi último rol en la vida
corporativa fue oficial en
jefe de seguridad de la
información para la parte
más alta del negocio,
entregando un programa
global de seguridad en
línea con el apetito de
riesgo.
Q: ¿Cuáles sientes que
son las habilidades de
liderazgo críticas para
que una mujer sea
exitosa en el campo
de la seguridad de la
información?
A: Una de las principales
habilidades es la
confianza. Necesitamos
tener confianza en
nosotras mismas y
ganar la confianza de
todas nuestras partes
interesadas (stakeholders)
—los clientes a todos los
niveles en la organización,
incluyendo los miembros
del directorio; compañeros

líderes en la jerarquía toma una y no mires hacia
organizacional; y el equipo atrás. Una resuelta mala
que nos apoya. decisión frecuentemente
conlleva a mejores
Y entonces, debemos resultados de largo
tener confianza para plazo que una decisión
aplicar y solicitar por los
roles que queremos.
intrascendente que resulte
estar bien.
Q: ¿Cuál es la mejor
manera para que
alguien desarrolle esas
habilidades?
A: Desarrollar una fuerte
red tanto dentro como
fuera de tu organización.
Uno necesita tener
personas de apoyo
que nos conozcan y
que conozcan nuestras
capacidades, aquellos
quienes te ayudarán a
obtener las oportunidades
que te mereces. Uno tiene
que saber quiénes son los
especialistas en quienes
puede uno depender y
con quienes en conjunto
se puede entregar
cosas extraordinarias.
Mantenerse expandiendo
los límites de uno. Si
uno se siente incómodo,
debe recordar que es
un resultado natural de
expandir sus propios
límites. La incomodidad
equivale a crecimiento.
Crear una reputación
de uno mismo de una
persona que entrega
conforme a lo prometido.
Muy temprano en mi
carrera, tuve un gran
gerente quien me dio dos
invaluables consejos:
uno, asegúrate que las
malas noticias le llegaran
rápido a ella. Proveerle un
estado de reporte honesto
de manera temprana
le daba la oportunidad
de tomar acciones para
minimizar el impacto.
Las malas noticias de
último minuto no te dan
la oportunidad de tomar
acciones evasivas con
todo el mundo de mala
manera. Y dos, cuando las
decisiones se necesiten,
la
red
Ellas lideran TI
Q: ¿Cómo es que las
certificaciones que
has obtenido te han
ayudado a avanzar o
potenciar tu carrera
profesional?
A: Cuando me comencé
en roles de seguridad, aun
siendo una profesional
de Ti experimentada, no
tenía las cualificaciones
para estos roles. Mi
entrenamiento formal
comenzó con un curso de
seguridad esencial de la
institución SANS, llamado
GIAC Security Essentials.
En los siguientes años
obtuve mucha experiencia
en el trabajo y conseguí
la certificación de
administrador de seguridad
de la información
certificado (CISM® por sus
siglas en inglés). A medida
que obtuve cualificaciones
profesionales mis roles
cambiaron de consultor de
seguridad a CISO.
Q: ¿Cuáles piensas
que son las formas más
efectivas de atender el
problema de la falta de
mujeres en el ámbito
laboral de seguridad de
la información?
A: Todas necesitamos
convertirnos en mejores
embajadoras, cambiando
la percepción que todos
aquellos que trabajan en
ciberseguridad son todos
altamente técnicos y
fanáticos por la tecnología
(geeks).
El campo es amplio
y requiere gente con
muchas y diferentes
habilidades y pasiones.
Ciertamente, existe
1

www.sheleadsit.org
¿Cuál es el mayor desafío de
seguridad que será enfrentado
en 2017? ¿Cómo debiera ser
enfrentado?
el extremo de las Lograr que las PyMEs reconozcan que los riesgos de
operaciones de TI, pero seguridad necesitan considerarse desde el principio. Los
no todo se trata de unos factores de riesgo necesitan ser resueltos mediante educación
y ceros. Y, ¿qué sucede y siendo alarmistas.
con la investigación,
auditoría y cumplimiento,
la administración del
riesgo y la educación?
Explorar los aspectos
2
 ¿Cuáles son tus tres metas para
2017?
más emocionantes— • Mejorar la seguridad en línea de 10 organizaciones de caridad
nosotros frecuentemente
conocemos acerca de • Crear un ambiente de apoyo para ayudar a mujeres a
cosas que potencialmente alcanzar sus metas
pueden tirar abajo a una
compañía y eventual y • Pasar unas vacaciones de 6 semanas en Navidad visitando a
seriamente también a mi hija en Australia
personas que estén muy
alto en la organización.
Promover el prestigio que
los roles pueden brindar. 3
¿Qué está sobre tu escritorio
en este momento?
Q: ¿Qué desafíos • Muchos accesorios (una cámara web externa, unos
enfrentaste cuando auriculares)
comenzaste tu propio • Una pila de tarjetas de presentación, de la última reunión de
negocio y cómo los
redes de contacto, esperándome a que les dé seguimiento
enfrentaste?
• Un marco fotográfico con un montaje de fotos de la familia
A: Cambiar de ser hecho por mi hija
empleada a convertirse
en dueña de un negocio • Una plantilla de mis últimos proyectos de cerámica
requiere un cambio
de mentalidad. Como
empleada, era valorada
como una experta,
4
¿Cuál es tu blog favorito?
El sitio Barkly blogs. https://blog.barkly.com/. Siempre de
podía enfocarme en mi actualidad, fácil de leer y de jerga limitada.
experiencia con el trabajo
que me era asignado.
Como dueña de un
negocio, necesito tener
5
 ¿Cuál es tu consejo número
uno para otros profesionales en
Seguridad de la Información?
un amplio conocimiento Nunca digas no a las oportunidades hasta que entiendas qué
de cómo funciona un es lo que estás rechazando.
negocio y dar seguimiento
a todas las partes que se
mueven. Necesito priorizar
lo que es importante que
yo haga por mi cuenta
6
 ¿Qué haces cuando no estás en el
trabajo?
Soy una aficionada a la cerámica. Durante el último par de
y aquello que se puede
externalizar. Al principio años, en lugar de llenar alacenas con platos y tazones, he
necesité encontrar estado creando murales de cerámica dimensional de 2½. Pasé
oportunidades para noches sin dormir tratando de resolver los desafíos de trabajar
intercambiar habilidades. con arcilla!
Y al mismo tiempo,
necesité convertirme una
vendedora competente,
convertirme en mi propio
fan y vender mi negocio
en toda oportunidad,
mostrar la misma clase de
confianza requerida para
ser un líder. Yo necesité
tener mucha confianza en
mí misma.
ISACA JOURNAL VOL 3 13
 Mitigación de los factores de riesgo
de fracaso de un proyecto de TI
En cualquier camino de la vida, dos cosas son verdad
acerca de los fracasos: son comunes y a nadie le
¿Tienes algo
gusta. No pueden ser evitados enteramente por varias
que comentar
razones. No todos los fracasos son absolutos. De
sobre
hecho, la mayoría de los fracasos son relativos. Los
este artículo?
éxitos no enseñan mucho, si es que enseñan algo; es
Visita las páginas del
el fracaso lo que proporciona lecciones para hacerlo
Journal en el sitio web
mejor en el futuro. Por lo tanto, no haber fallado en
de ISACA® website
ningún momento es probablemente una pretensión
(www.isaca.org/
sin fundamento y, si es cierto, sugiere potencialmente
journal), encuentra el
muy poco cambio positivo en la organización. La ironía
artículo y hace click
es que los fracasos vienen con costos asociados. En
en el link Comments
proyectos de TI, por ejemplo, el costo puede ser en
para compartir tus
términos de no cumplir con el alcance, no alcanzar el
pensamientos.
plazo o superar el costo monetario presupuestado.
En el lado humano, los fracasos pueden ser
desmoralizantes y pueden afectar negativamente la
productividad de los empleados en todas las áreas
funcionales involucradas en el proyecto fallido.
Un fallo indica que se ha materializado algún riesgo.
Dos aspectos de riesgo dominantes de los proyectos
de TI tienen que ver con:
1. Inversión (fallar en agregar valor a pesar de la
inversión)
Vasant Raval, DBA, CISA, ACMA
Es profesor de contabilidad en la Universidad
de Creighton (Omaha, Nebraska, EE.UU.).
Coautor de dos libros sobre sistemas de
información y seguridad, sus áreas de
enseñanza e investigación incluyen la
seguridad de la información y el gobierno
corporativo. Puede ser contactado en
vraval@creighton.edu.
14 ISACA JOURNAL VOL 3
2. Propiedad del proyecto (fallo debido a la
responsabilidad)1.
En una encuesta mundial del 2004 a 200
profesionales de TI de empresas con ingresos
anuales superiores a US $50 millones, el 71 por
ciento y el 72 por ciento de los encuestados,
respectivamente, consideraron que los factores de
riesgo de inversión y de propiedad del proyecto
eran “muy significativos”2. Numerosas encuestas
inequívocamente han hecho eco de un resultado
relacionado: La tasa de fracaso de los proyectos
de TI es alarmantemente alta a pesar de las
posibles mejoras en las técnicas de gestión de
proyectos a lo largo del tiempo3.
Incluso una pequeña mejora en la tasa de falla
del proyecto resultaría en un impresionante
avance. Los proyectos de TI han ganado un papel
cada vez más importante en la mayoría de las
organizaciones. No sólo es un habilitador genérico
de casi cualquier cosa (por ejemplo, mejoras en
la cadena de suministro), sino que también es
clave para la innovación y el crecimiento. Por lo
tanto, el desarrollo exitoso de proyectos de TI es
importante. Cualquier atraso en el cronograma, por
ejemplo, puede resultar en una demora en la fecha
de lanzamiento al mercado, y cualquier acotación
en el alcance puede desencadenar una cascada de
revisiones que frustren tanto al desarrollador como
a la comunidad de usuarios.
Anatomía de un proyecto de
tecnologías de la información
Un proyecto de TI es la culminación de tres
subsistemas:
• Proceso (planificación y entrega del proyecto)
• Contexto (sistema a ser provisto)
• Contenido (sistema que entrega el servicio)
Rajesh Sharma, Ph.D., ITIL-F, Six Sigma
Black Belt
Es una oficina de gestión de calidad (QMO) en
los Servicios de Ingeniería de Software. Cuenta
con más de 19 años de experiencia en el
establecimiento y gestión de una oficina de gestión
de proyectos, un QMO, un programa de métricas
y como líder para proyectos independientes de
verificación y validación (IV&V). Como líder de QMO
y IV&V, ha realizado auditorías de calidad, mejora
de procesos y evaluaciones de IV&V. Puede ser
contactado en rajsharmane@gmail.com.

El principal influenciador del proceso es el gerente
de proyectos (PM), con el apoyo de la alta gerencia;
el principal influenciador del contexto es la
administración corporativa y los usuarios; y para el
contenido, son los profesionales de TI/SI. El primero
es responsable de crear la sinergia entre el contenido
y el contexto, alineando los dos subsistemas para
trabajar juntos; el segundo es responsable del “por
qué” del cambio, incluyendo la cultura, el liderazgo
y los asuntos organizativos; y la tercera aborda el
“cómo” del cambio.
Cualquier falta
de alineación
entre estos tres
subsistemas
significará
degradación de algún
tipo, posiblemente
teniendo como
consecuencia de un
resultado menos que
óptimo.
Cuando se introduce una intención en esta tríada,
los resultados se materializan. Evidentemente,
cualquier resultado deficiente puede tener que ver
con el hecho de que el proceso, el contexto o el
contenido no funcionaron como se esperaba y,
como consecuencia, el resultado es deficiente (por
ejemplo, defectuoso, tardío, caro). La complejidad
del éxito o fracaso radica en estos tres subsistemas
relativamente independientes: su propia madurez y
desempeño, su cultura y la eficacia de la interacción
a través de ellos4.
Con esta cantidad de complejidad, los problemas
de comunicación, la claridad en la visibilidad de los
objetivos y la responsabilidad del propio rol (hecho
bien, a tiempo y dentro del presupuesto) son factores
clave en las fallas del proyecto. Cualquier falta de
alineación entre estos tres subsistemas significará
una degradación de algún tipo, posiblemente
teniendo como consecuencia un resultado menos
el
aspecto práctico
que el óptimo. La cultura, las estructuras de poder e
incluso el lenguaje a través de estos sistemas difieren
tanto que, mantener en equilibrio toda la iniciativa del
proyecto puede ser abrumador.
La causa principal del fracaso de un proyecto en
general, puede provenir de cualquiera de los tres
subsistemas entrelazados. Por ejemplo, la falta de
madurez de los procesos o la falta de disciplina
del proyecto, se manifiesta en la planificación
del proyecto y su entrega y la traducción y
ejecución de los requerimientos del negocio en las
especificaciones técnicas, están arraigados en el
contenido. Una empresa que tenga incluso el nivel
más alto de posicionamiento en el CMMI, Integración
de modelos de madurez de capacidades (del inglés:
Capability Maturity Model Integration), puede fallar
porque los subsistemas responsables del contexto y
el contenido no son desarrollados con eficacia.
Esta visión de la gestión de proyectos puede ser
bastante útil en el seguimiento de los primeros
gatilladores de fallas y para evaluar la mejor forma
de recuperarse del fracaso. Si falta un usuario líder
influyente y un agente de cambio (en el subsistema
de contexto), los resultados pueden degradarse a
través de varios factores clave. O bien, procesos
de planificación inmadura en el subsistema de
planificación y entrega pueden resultar en un
análisis de riesgo inadecuado para el proyecto. Y
el subsistema de contenido puede estar en falta
cuando elige un software débil o inadecuado para la
ejecución del proyecto5.
Por último, es importante reconocer que los
proyectos pueden variar mucho. Tamaño,
importancia, duración, costo, profundidad
tecnológica, comunidad de usuarios, importancia
estratégica—estos son algunos de los factores que
conducen la diferenciación entre los proyectos en
una organización. En consecuencia, los fallos del
proyecto pueden tener un impacto diferente en la
organización y en su respuesta al nivel de la falla.
Casos de estudio
Para determinar las causas del fracaso y
recomendar medidas de mitigación, se pueden
examinar tres proyectos fallidos en diferentes
organizaciones.
Caso A
Un proyecto de varios años y multimillonario
ha sobrepasado las fechas de vencimiento. Se
determinó que el subsistema de planificación y
entrega del proyecto era responsable del atraso.
ISACA JOURNAL VOL 3 15
 La oficina de gestión de proyectos (PMO) falló
un informar sistemáticamente sobre el progreso
¿Te gusto este del proyecto. Incluso en el limitado esfuerzo por
artículo? reportar el progreso, la PMO describió 14 factores
de éxito del proyecto, pero algunos no pudieron ser
• Lea IT Risk cuantificados. Además, la lista de indicadores para
Management medir el logro de los objetivos y metas del negocio
Audit/Assurance fue incompleta, lo que condujo a un seguimiento
Program. mediocre del progreso real.
www.isaca.org/
En términos generales, si un subsistema de
auditprograms
planificación y entrega es la fuente de las fallas, los
problemas surgirán en muchos, si no en todos los
• Aprenda más proyectos, debido a que la debilidad reside en la
acerca, discute ausencia de madurez y disciplina en la planificación
y colabora sobre y entrega. Esto podría afectar a muchas partes
gestión de riesgos interesadas en el subsistema de contexto y también
en el Centro de frustrar a los profesionales de TI competentes en el
Conocimiento. subsistema de contenido.
www.isaca.org/risk-
management En el subsistema de contexto, se encontró
que, mientras que el personal de soporte del
área funcional era dedicado, hubo confusión con
respecto al gerente funcional responsable de
las decisiones clave. En consecuencia, ciertas
decisiones se demoraron o no se realizaron. Además,
hubo diferencias significativas entre las áreas
funcionales respecto del enfoque de la gestión de
proyectos. Entre otros factores, esto contribuyó a la
desconfianza entre las áreas funcionales, dando lugar
a una gran cantidad de problemas.
Los siguientes pasos muestran las acciones
recomendadas:
• Definir claramente al gestor responsable con
autoridad de tomar decisiones para cada área
funcional.
• Asegurar una participación, coordinación y
comunicación que sean completas y abiertas
entre todas las partes interesadas, incluidos
los proveedores, para reforzar las expectativas,
aprovechar la experiencia de cada uno y crear
confianza y credibilidad en el proyecto.
Caso B
Un proyecto multimillonario de varios años sufrió la
demora en la ejecución de las decisiones, causando
un efecto en cascada en el costo, el calendario y
el alcance del proyecto. La razón clave: socavar
la autoridad del PM y de la PMO. Cuando la
disciplina y la autoridad respecto de la gestión de
los proyectos son marginados, los proyectos sufren.
Por ejemplo, se elaboró y se informó un documento
de toma de decisiones de alojamiento de servidores
fuera de la estructura de gobierno definida para el
proyecto6. La oportunidad de ejecución también
se vio obstaculizada por la falta de sincronización
en el calendario entre la negociación de contratos
de proveedores y los procesos de aprobación
de proyecto. El factor subyacente fue la limitada
autoridad del PM y de la PMO para tomar decisiones
16 ISACA JOURNAL VOL 3
relacionadas con el proyecto, escalando muchas
decisiones hacia los ejecutivos.
Para resolver la situación, se sugirieron los
siguientes pasos:
• Revisar la autoridad en la toma de decisiones del
PM, de la mesa de control de cambios, del comité
directivo y de los patrocinadores ejecutivos, y
ajustarla cuando sea conveniente.
• Establecer un proceso de cambio de contrato,
con límites de tiempo claramente definidos para
una aprobación de cambio expedita, bajo ciertas
circunstancias.
• Asegurar que cada uno comprenda su
autoridad y la estructura de gobierno definida, y
responsabilizar a los individuos y departamentos
de adoptar la estructura de gobierno.
Claramente, este caso apunta a los problemas de
madurez y disciplina de los procesos y a la falta
de influencia del liderazgo en el subsistema de
planificación y entrega. Como resultado, todos
y cada uno de los proyectos iniciados por la
organización corren el riesgo de un bajo desempeño.
Caso C
Un proyecto multimillonario de varios años sufrió
de una identificación débil respecto del riesgo del
proyecto. Algunas de las observaciones realizadas
durante el análisis de causa raíz incluyeron:
• Los requerimientos del negocio que se definieron
carecían de claridad, entendimiento común,
completitud y calidad. Esto afectó la definición y
comprensión del alcance del proyecto y, a su vez,
impactó en las expectativas de desempeño y en
la estimación del calendario, del esfuerzo y de los
costos.
• Las partes interesadas no entendieron sus
compromisos.
• La revisión, verificación, validación y aprobación
de los requerimientos fue inmadura.
• La trazabilidad de los requerimientos fue
inconsistente.
• La omisión de la funcionalidad crítica y los
atributos de calidad, probablemente causó un
diseño inexacto o incompleto.
Para resolver la situación, la empresa debe
considerar los siguientes pasos:
• Establecer un proceso formal de desarrollo
de requerimientos que incluya la revisión, la
aceptación y los compromisos asociados a los
requerimientos.
• Establecer un proceso de gestión de
requerimientos maduro para mejorar la
trazabilidad (por ejemplo, funcional, técnico,
interfaz, hardware y software).
• Asegurar que el proceso de revisión de pares de
los requisitos realmente agregue valor.
Auditorías de proyectos de TI
El papel de los auditores en los proyectos
de TI tiene que ver con asegurar de que los
proyectos críticos de la organización se gestionan
adecuadamente para lograr el éxito7. Los proyectos
de TI definen esencialmente el futuro de la
organización; asumiendo que fueron priorizados
y seleccionados correctamente, su éxito es
fundamental para construir un futuro próspero.
Los proyectos de TI, en este sentido, son los
precursores de que se espera del futuro. El rol del
auditor de SI en proporcionar una opinión experta
sobre el estado de los proyectos de TI, incluyendo
el riesgo emergente y sin mitigar, debe ser valorado
por la organización.
Los proyectos
de TI definen
esencialmente
el futuro de la
organización;
asumiendo que
fueron priorizados
y seleccionados
correctamente, su
éxito es fundamental
para construir un
futuro próspero.
Implicaciones prácticas
El “triángulo de hierro” de la PMO (personas, procesos
y tecnologías)8 y recursos (por ejemplo, CMMI for
Development V1.3)9 demuestran que un tema clave
que impacta el desempeño y el éxito del proyecto es la
gente. Los casos descritos aquí ponen a la luz el hecho
de que incluso la madurez del proceso y la adopción
de las mejores prácticas de la industria a lo largo del
tiempo puede ser insuficiente para resolver problemas
culturales.
Organizaciones con énfasis en los procesos invierten
fuertemente en el establecimiento de plantillas e
instrucciones, y, aun así, la institucionalización de estos
procesos puede ser débil. Una alta tasa de fallas en
los proyectos sugiere que no se percibe en todos los
niveles que los procesos asociados a los proyectos
agregan valor, ni se alinean con la cultura organizacional.
La dirección (en los casos discutidos anteriormente)
implementó posteriormente las recomendaciones
basadas en las áreas de procesos específicas del
CMMI, lo que a su vez resultó en una mejora medible
en la tasa de éxito de los proyectos y en un cambio
favorable en la cultura organizacional hacia los procesos,
como se evidencia en evaluaciones posteriores de
aseguramiento de calidad.
Finalmente, debido a que la capacidad de recordar
en la organización es limitada, es difícil aprovechar las
lecciones aprendidas de los fracasos a menos que las
causas y los remedios de todos los errores importantes
de los proyectos sean debidamente documentados.
Cuando se comparten con las partes interesadas, este
historial de casos reales y específicos de la organización
podría minimizar los fallos futuros.
Nota del autor
Las opiniones expresadas en esta columna son de
los propios autores y no de sus empleadores.
Notas Finales
1 The Economist Intelligence Unit, Global Study on
Information Risk Management, 2002
2 IT Governance Institute, Information Risks:
Whose Business Are They?, USA, 2005, p. 9
3 See, for example, The State of Project
Management Survey, Wellingtone Project
Management, 2016, www.wellingtone.co.uk/
state-of-project-management-survey-2016
4 Yeo, K. T., “Critical Failure Factors in Information
Systems Projects,” International Journal of
Project Management, vol. 20, iss. 3, April 2002,
p. 241–246
5 Op cit, Yeo
6 IBM, Global Making Change Work Study, 2008,
https://www-07.ibm.com/au/pdf/making_change_
work.pdf
7 Ibid.
8 Project Management That Works, “The Iron
Triangle of the PMO: People, Processes, and
Technology,” 3 June 2011, www.pmthatworks.
com/2011/06/iron-triangle-of-pmo-people-
processes.html
9 Chrissis, M. B.; M. Konrad; S. Shrum; CMMI for
Development: Guidelines for Process Integration
and Product Improvement, 3rd Edition, Addison
Wesley, USA, 2011
ISACA JOURNAL VOL 3 17
2017GRC
Where Governance and Risk Management Align for Impact

Keynote John Sileo to Share His Story of

Dramatic Transformation
Hear first-hand the extraordinary experiences of John Sileo, keynote
speaker at the 2017 Governance, Risk, and Control (GRC) EARN UP TO
Conference, Aug. 16–18, in Dallas-Ft. Worth, Texas, USA. Sileo 18 CPE HOURS.
is an award-winning author and cyber security expert who has
appeared on 60 Minutes, Anderson Cooper and Rachael Ray.
He also spent two years working to stay out of jail. SAVE US$200
WHEN YOU REGISTER
Learn why he was in this predicament, as Sileo focuses BY JUNE 12, 2017!
on managing privacy and reputation in an economy
plagued by digital overexposure.

Register Soon—space is limited and previous

events have sold out!
www.isaca.org/GRC17-jv3
 artículo
artículo
Gestionar el riesgo de IoT
Regulaciones, marco de referencia, seguridad, riesgo y
analítica
salud, que no tiene beneficios que son transparentes
Também disponível em português de inmediato para el usuario final y tiene mayor riesgo. ¿Tienes algo que
www.isaca.org/currentissue comentar sobre
Seguridad IoT—El plan del juego este artículo?
Visita las páginas del
¿El reciente ataque de denegación de servicio El plan de juego para la seguridad IoT proporciona Journal en el sitio web
distribuido (DDoS) en Dyn1 marca oficialmente el paso una visión general del ecosistema IoT y aborda las de ISACA® website
de la etapa de temor, incertidumbre y duda (FUD) de normas, marcos y propuestas de regulación que se (www.isaca.org/
las cosas de Internet (IoT), o es aún el comienzo de han desarrollado recientemente. La figura 1 journal), encuentra el
¿el escenario? IOT FUD se refiere a vulnerabilidades artículo y hace click
representa un ecosistema de IoT en el que la
de IoT que conducen a la pérdida de datos, servicio en el link Comments
seguridad de la información forma parte integral.
para compartir tus
y posiblemente vida. Tradicionalmente, FUD sobre
pensamientos.
un incumplimiento de la seguridad o incumplimiento Normas IoT y desarrollo del marco
de la normativa es el principal impulsor para que la Una repercusión positiva del ataque Dyn DDoS
administración invierta en seguridad de la información. fue el lanzamiento de principios y directrices para
El mismo FUD se aplica a la seguridad de IoT, asegurar el IoT por el Departamento de Seguridad
aunque involucra múltiples variables que deben ser Nacional (DHS) de los Estados Unidos, en 20165, 6.
consideradas. La resolución de abordar la seguridad Estas directrices no son legalmente obligatorias,
de dispositivos IOT en varios niveles—hardware pero son sin duda un signo de un buen comienzo
y software, gobierno y empresa, servicios—es hacia la seguridad del dispositivo IoT.
generalizada. Esta resolución en aumento se debe
principalmente a la gran cantidad de dispositivos IoT Algunas de estas directrices son mantras bien
que están disponibles y la facilidad con la que estos conocidos para la mayoría de los profesionales de
seguridad en el juego: Indrajit Atluri,
dispositivos pueden ser comprometidos y convertidos
CRISC, CISM, CEH,
en thingbots. Thingbots son botnets de dispositivos • Aprovechar la seguridad de la fase de factibilidad. CISSP, CSSLP,
IoT infectados que pueden ser utilizados para lanzar
• Aplicar actualizaciones de seguridad, HCISPP, ITILv3
ataques que son como el ataque Dyn, que afectó
correcciones y gestión de vulnerabilidades. Es un profesional de
a más de un millón de dispositivos, de los cuales ciberseguridad con
alrededor del 96 por ciento eran dispositivos IoT2, 3 . • Seguir las prácticas de seguridad probadas. experiencia en gobierno
de TI, gestión de
El problema principal es con el hardware del •P
 riorizar los controles basados en la magnitud o riesgos y cumplimiento.
dispositivo IoT, que se fabrica principalmente fuera de el impacto. Sus áreas de
los Estados Unidos y necesita ser regulado4. El sector • Proporcionar supervisión y adecuada gobernanza enfoque actuales
de la industria del retail ha sido el principal adoptante incluyen la seguridad
de la IOT.
de tecnologías
de la tecnología IoT porque llega directamente a
• Conecte el dispositivo fuera de la red si no hay emergentes, tales
numerosos clientes, a diferencia del sector de la
una necesidad absoluta de negocio. como Internet de las
cosas, análisis de
Figura 1— Ecosistema IoT datos y seguridad, y
sus implicaciones en el
SEGURIDAD DE INFORMACIÓN riesgo de información
y la privacidad. Atluri
es socio en la empresa
CHIP DISPOSITIVO CONECTIVIDAD PLATAFORMA INTEGRACION de seguridad de la
información Secur80.
Puede ponerse en
COMPUTACION EN LA NUBE Y ANALITICAS contacto con él en
iatluri@secur80.com.
Fuente: I. Atluri. Reimpreso con permiso

ISACA JOURNAL VOL 3 19

 También en 2016, se aprobaron exenciones a la
Ley de Derecho de Autor de EEUU que permiten a
los investigadores independientes ser capaces de
hackear casi cualquier dispositivo IoT 7. Aunque se
aplican numerosas limitaciones a las exenciones,
se concedieron durante dos años. Esto ayudará
a los investigadores a desbloquear software para
su investigación sin ninguna implicación legal. Las
intenciones son correctas, pero el impacto de este
cambio, positivo o negativo, está por verse.
Si no hay un beneficio o costo
beneficio para el fabricante
para que aplique un parche a un
producto menos frecuentemente
reemplazado, no hay un impulso
para que el fabricante aplique
parches con regularidad; Por lo
tanto, debe ser regulado.
El Consorcio Industrial de Internet, compuesto
principalmente por empresas relacionadas con
IoT, desarrolló el IISF (Industrial Internet Security
Framework), que describe las mejores prácticas
para ayudar a los desarrolladores y usuarios
finales a evaluar el riesgo de IoT y posiblemente
defendiendo contra este riesgo8. A principios de
2017, la Comisión Federal de Comercio de los
Estados Unidos (FTC, por sus siglas en inglés)
anunció que está otorgando premios en dinero a
cualquier persona que desarrolle una herramienta
innovadora que detecta y protege los dispositivos
del hogar de vulnerabilidades del software9.
Otro desarrollo reciente en la seguridad IoT es
el marco de seguridad Sigma Designs S2, que
formará parte de cada dispositivo IoT certificado
por Z-Wave que se fabrique después de marzo de
2017 y sea compatible con versiones anteriores en
los chipsets Z-Wave IoT existentes, lo que hace
que los dispositivos sean más seguros10.
Propuestas Regulatorias
El investigador de seguridad cibernética y profesor
de la Universidad de Harvard, Bruce Scheiner,
propuso recientemente una industria de IOT más
20 ISACA JOURNAL VOL 3
regulada en una reunión con dos subcomités de la
Cámara de Representantes de Estados Unidos: el
Subcomité de Comunicaciones y Tecnología y el
Subcomité de Comercio, Manufactura y Comercio11.
Presentó la comparación del costo frente al incentivo
y el impulso para que los fabricantes de dispositivos
IoT corrigieran las vulnerabilidades periódicamente.
Scheiner señaló que la mayoría de los dispositivos
IoT ofrecen beneficios más bajos y que los
dispositivos más frecuentemente reemplazados,
como los teléfonos inteligentes, son parchados con
más frecuencia, en comparación con los dispositivos
que rara vez se reemplazan, como termostatos
y refrigeradores. Los coches inteligentes y los
reproductores de Blu-ray se encuentran entre estos.
Los termostatos de IoT y los refrigeradores que no
es probable de ser reemplazados tienen un mayor
riesgo, si no se parchan. Si no hay un beneficio o
costo beneficio para el fabricante para que aplique
un parche a un producto menos frecuentemente
reemplazado, no hay un impulso para que el
fabricante aplique parches con regularidad; por
lo tanto, debe ser regulado. El otro lado de este
argumento es que la regulación de la industria de IoT
frenaría el crecimiento de la innovación.
La Administración de Alimentos y Medicamentos de
los Estados Unidos (FDA, por sus siglas en inglés) ha
estado proporcionando alguna guía a los fabricantes
sobre las mejores prácticas para construir seguridad
en dispositivos médicos desde octubre de 2014.
En diciembre de 2016, la FDA agregó una guía que
enumera las mejores maneras para asegurar los
dispositivos médicos después de que entren en la
mano del consumidor, principalmente para prevenir
cualquier daño a los pacientes. La guía también
indica que los fabricantes de dispositivos de IoT
deben informar a la FDA si el uso de un dispositivo ha
resultado, o puede resultar, en cualquier tipo de daño
grave o la muerte de una persona. La notificación a la
FDA se renuncia sólo si los clientes y usuarios de los
dispositivos son notificados acerca de la vulnerabilidad
en el dispositivo en un plazo de 30 días, el dispositivo
se arregla en 60 días y esta información se comparte
con la Organización de análisis y compartición de
información (ISAO)12, 13. La premisa es algo similar a
las sanciones de reconocimiento óptico de caracteres
(OCR) en las violaciones de la Ley de Portabilidad y
Responsabilidad del Seguro Médico (HIPAA por sus
siglas en inglés), pero la diferencia es que las guías de
la FDA son solo recomendaciones y no son legalmente
vinculantes. Se cree que estas guías conducirán
eventualmente a la legislación, como en el caso de
HIPAA.
Más recientemente, el Comité de Comercio del dos categorías: un tipo de dispositivo interactúa
Senado de los EEUU aprobó la Ley de Desarrollo de con un pórtico y el otro tiene un pórtico integrado ¿Te gusto este
la Innovación y Crecimiento de Internet de las Cosas en el dispositivo. La segunda categoría de
(DIGIT). Actualmente está esperando la aprobación
artículo?
dispositivos incluye principalmente dispositivos
del pleno del Senado. La Ley DIGIT crea un grupo de que necesitan estar en movimiento constante, por
trabajo que se centrará en la seguridad, la privacidad
• Lea Internet of
ejemplo, coches inteligentes y artículos de fitness.
y otras cuestiones relacionadas con IoT14.
Things: Risk
and Value
Defensa
Consideration.
El juego de la seguridad IoT La defensa comienza a nivel de chip o hardware. El
www.isaca.org/
hardware en el que se construye el dispositivo IoT
Se calcula que el número de dispositivos IoT internet-of-things
constituye la base para un dispositivo IoT robusto
conectados alcanzará los 200 mil millones en y seguro. Esto es como establecer una base sólida
202015. Asimismo, se calcula que aproximadamente • Aprenda más
para una casa para asegurar un producto final
4 mil millones de personas estar en línea para acerca, discute
estable y sostenible.
202016. La exposición en línea aumenta múltiple en y colabora sobre
2020 por la simple razón de que las interacciones gestión de riesgos
Nivel del fabricante del dispositivo
hombre-máquina (H2M) aumentan junto con las en el Centro de
Como se muestra en la figura 1, el chip y el
interacciones máquina-máquina (M2M). Conocimiento.
hardware del dispositivo IoT es donde comienza
www.isaca.org/risk-
el ciclo de vida de un dispositivo IoT y es también
La Arena de IoT management
el momento adecuado para dirigir el proceso en el
La figura 2 muestra una arquitectura IOT conceptual. camino correcto.
Los dispositivos IoT caen generalmente en una de

Figura 2—Arquitectura Conceptual IoT

Sensores y Dispositivos Puerta Plataforma Nube Aplicaciones

Actuadores IoT IoT Análisis
IoT IoT/Servicios

Dispositivos IoT Dispositivo Servicios

Sensores comunicarse transmisión de datos
de puerta IoT
Acústico con gateway

Vibración Análisis y
Servicios de descanso visualización

Humedad

Vaho
DB
Fluir Base de datos

Proximidad
Servidores de
Electricidad almacenamiento

Magnético Mensajería

Radio
Gestión de dispositivos
Químico Dispositivos IoT
comunicarse con
la nube

Actuadores Automatización de
procesos IoT
Hidráulico

Neumático

Eléctrico
Motor de reglas
Mecánico

Fuente: I. Atluri. Reimpreso con permiso

ISACA JOURNAL VOL 3 21

 Hardware
Las principales amenazas a un dispositivo IoT en
el nivel de hardware son que puede ser robado,
modificado físicamente, reemplazado y clonado.
Los ejemplos de vulnerabilidad de hardware
incluyen las contraseñas predeterminadas débiles
pre-configuradas o las credenciales codificadas
con código de seguridad y los circuitos integrados
falsificados.
Hoy en día, no hay implicaciones
legales para no seguir las Normas,
pero puede haber un rechazo a
nivel empresarial en adoptar un
dispositivo IoT de calidad inferior de
un fabricante.
La Fundación para la Seguridad de Internet de
Cosas (IoTSF), una organización sin fines de
lucro, ayuda a todos los fabricantes, vendedores
y usuarios finales de IOT a ayudar a proteger
los dispositivos IoT17. Sin embargo, la mejor
contramedida para combatir las vulnerabilidades de
hardware es regular el proceso de fabricación de
un dispositivo IoT. Los fabricantes de dispositivos
IoT deben ser responsables de no adherirse a
las normas regulatorias de IoT (no hay normas al
momento de escribir este documento), las normas
industriales y/o directrices. Hoy en día, no hay
implicaciones legales para no seguir los estándares,
pero puede haber un retroceso en el nivel de la
empresa en la adopción de un dispositivo IoT de
calidad inferior de un fabricante. Este rechazo
puede evitar la mayoría de las vulnerabilidades de
hardware y debilidades de software que pueden
estar disponibles de forma inherente en dispositivos
IoT. Si las vulnerabilidades de hardware no se
mitigan, el resto de los controles, metodologías,
marcos, tiempo, recursos e inversiones para que los
dispositivos IoT sean seguros no puede ser eficaz.
22 ISACA JOURNAL VOL 3
Algunos de los reglamentos y el rechazo deben ser
impulsados por los respectivos gobiernos, con la
ayuda de la comunidad de seguridad.
Software
Las principales amenazas al software o al firmware
en los dispositivos IoT son que el software
puede modificarse o descompilarse para extraer
credenciales y apalancarse para realizar los ataques
DDoS. Las vulnerabilidades en el nivel de
software son:
• Código inseguro
• Contraseñas predeterminadas codificadas en
disco duro
• Pruebas inadecuadas de software que conducen
a puertas traseras
• Ausencia de autenticación fuerte durante M2M
H2M y las interacciones entre máquinas (M2H) El
Proyecto de Seguridad de Aplicaciones Web Abiertas
(OWASP) ayuda a los fabricantes de IOT a construir
software IoT seguro y clasifica periódicamente las 10
vulnerabilidades de software IoT.
Nivel de empresa/red
Al igual que otros dispositivos de red, las amenazas
de dispositivos IoT más comunes a nivel de empresa/
red son los ataques de escucha espontánea, los
ataques de man-in-the-middle (MiTM) y el robo de
ancho de banda. Los tres pasos sugeridos para
proteger contra estas amenazas son18.
1. Identificar e inventariar los dispositivos IoT
en la empresa y asegurarse de que estén
integrados en el programa de gestión de activos
empresariales.
2. Definir estándares y líneas de base para la
seguridad del dispositivo IoT basada en políticas
y estándares empresariales.
3. Implementar los controles de seguridad
necesarios para mitigar el riesgo de IoT.
Se recomienda la segmentación de todos los
dispositivos IoT en una zona de red separada,
lo que facilita la cuarentena de toda la zona IoT
en caso de una violación19. El resto de TI puede
continuar sus operaciones sin ningún impacto
importante.
Si la segmentación y la zonificación no son
factibles, se sugiere adoptar un modelo de red
de software definido (SDN) que no sólo mejora
la seguridad de IoT, sino que también ayuda a
identificar la ubicación de la brecha20.
Otros controles comunes que deben implementarse
para dispositivos IoT son los mismos controles que
se aplican a la mayoría de la infraestructura de TI de
hoy. Son autenticación de dos factores, contraseñas
más fuertes o autenticación basada en claves.
Es de suma importancia darse cuenta de que la clave
para que estas metodologías de defensa funcionen
como se espera es asegurar los dispositivos IoT y la
red desde el día en que se introducen en la red. Si no,
la posibilidad es alta de que estos dispositivos IoT son
hackeable para siempre y no podrán ser parchados
y protegidos. Si se detecta un dispositivo IoT pícaro,
debe ser reemplazado inmediatamente21.
Los dispositivos IoT deben ser capaces de llevar a
cabo una autenticación multifactorial, por ejemplo,
llamar al usuario/propietario humano del dispositivo
IoT, antes de que el usuario/propietario realice la
actualización de seguridad.
La autenticación de infraestructura de claves públicas
(PKI) para la comunicación entre dispositivos IoT
y pórticos es una contramedida recomendada
para evitar que un dispositivo IoT sea interrumpido
para instalar software no autorizado. Sólo se debe
permitir instalar software certificado durante las
actualizaciones y parches.
Se están introduciendo marcos que pueden ayudar
a implementar un robusto modelo de seguridad para
dispositivos IoT. El producto KeyScaler 5.0 de Device
Authority ofrece el aprovisionamiento de certificados
y claves específicamente para dispositivos IoT
durante el proceso de registro22.
Ofensiva
La mejor defensa siempre comienza con una buena
ofensiva. La detección temprana y la prevención de
ataques en tiempo real es la prioridad de los equipos
de seguridad y se ha convertido en el nuevo mantra.
Muchas infracciones recientes ocurrieron hace
meses o en algunos casos años atrás (por ejemplo, la
violación de Yahoo), antes de que fueran detectadas
y los procesos de respuesta comenzaron23.
Pruebas
Las pruebas de calidad del software IoT son
totalmente diferentes de las pruebas de software
tradicionales. Autonomía, conectividad e impulso
son los tres factores que hacen que las pruebas
de calidad de software IoT difieran de las pruebas
de software tradicionales24. El concepto de que la
seguridad es un proceso y no un complemento
es bien conocido. Las pruebas de software IoT
para contraseñas más débiles, vulnerabilidades de
desbordamiento de búfer, etc., deben seguir las
mejores prácticas de OWASP. Los dispositivos IoT
también deben probarse en puertos de bus serie
universal (USB) para vulnerabilidades. La clave
es reducir la superficie de ataque del dispositivo
IoT en la máxima medida posible. Además, al
igual que cualquier otro sistema de TI que esté
cerca de Internet, se debe almacenar, transmitir y
procesar sólo la cantidad mínima de información
confidencial25.
La clave para que estas
metodologías de defensa funcionen
como se espera es asegurar los
dispositivos IoT y la red desde el
día en que son Introducido en la
red.
Gestión de riesgos de IOT
Forescout categoriza los dispositivos IoT en tres
niveles:
• Desastroso—Dispositivos conectados a IP que
conectados directamente a Internet están en
alto riesgo. Pueden causar daños a la empresa
al obtener acceso a información confidencial o
causar deterioro de la infraestructura crítica.
• Disruptivo—Los sistemas interconectados, como
los teléfonos e impresoras de voz sobre Protocolo
de Internet (VoIP), pueden provocar interrupciones
en las operaciones del negocio.
• Perjudicial—Los dispositivos tales como bombillas
y refrigeradores inteligentes pueden usarse para
husmear alrededor de la red de la empresa para
obtener acceso a Metadatos sobre la red26.
La orientación de la FDA recomienda que los
fabricantes de dispositivos formen o se unan a
una organización de intercambio y análisis de
ISACA JOURNAL VOL 3 23
 información (ISAO), que es similar a los centros
de intercambio de información y análisis que
existen hoy en día. Un ISAO puede ayudar a
las organizaciones participantes compartiendo
amenazas y riesgos de seguridad en tiempo real y
diseñando respuestas oportunas.
El gobierno de
los dispositivos IoT
debe ser manejado
por separado, pero
bajo el paraguas de
gobierno de TI.
Análisis y detección
Los recientes avances en el análisis de datos
improvisan la métrica de inteligencia accionable para
la seguridad. Productos como Adaptive Defense
no sólo proporcionan a los equipos de seguridad
información sobre los ejecutables que entran en la
red, sino que también confirman de forma proactiva
un incidente, en lugar de simplemente alertar sobre
todos los eventos sospechosos27. PatternEx combina
la inteligencia artificial (AI) con la intuición del
analista para ofrecer una plataforma de predicción
de amenazas que detecta las amenazas actuales
y emergentes en tiempo real en toda la empresa.
Esto va a ser y debe ser la tendencia hacia adelante,
especialmente con los limitados recursos y analistas,
monitoreo continuo, presupuestos de seguridad, y
más dispositivos que se agregan a la red creando
aún más formas de ser hackeado. Determinar el
punto en el que realmente ocurrió una intrusión
después de detectar que sucedió es la clave. AI
(inteligencia artificial) puede, con suerte, reducir el
tiempo y los recursos que se necesitan para detectar
una intrusión pronto.
Gobernanza del equipo IOT
El riesgo de un dispositivo IoT inseguro es relativo
en función del dominio en el que se opera y de la
jurisdicción en la que se desarrolla. Por ejemplo, la
privacidad está en mayor riesgo cuando el dispositivo
maneja información de salud protegida (PHI),
en comparación cuando está en una instalación
24 ISACA JOURNAL VOL 3
industrial, en la que la infraestructura o los servicios
están en riesgo. La geografía de donde opera el
dispositivo de IoT también es importante porque las
fijaciones legales y regulatorias pueden diferir de un
lugar a otro. El gobierno de los dispositivos IoT debe
ser manejado por separado, pero bajo el paraguas de
gobierno de TI. Los cuatro factores críticos de éxito
que contribuyen a un proyecto eficaz de IOT son un
equipo de gestión de proyectos de IOT eficiente, un
stakeholder del proyecto que tiene la autoridad para
impulsar el proyecto IoT, datos e Infraestructura de
telecomunicaciones para apoyar IoT, y expertos en
la materia para mantener la alta calidad de datos y
problemas de integración28.
A nivel de gestión de proyectos, los ocho pasos29
que pueden ayudar a las empresas a implementar
un programa de seguridad IOT sostenible son:
1. Identificar información
2. Priorizar los dispositivos
3. Evalúe el riesgo de pérdida de datos
4. Evalúe el riesgo de acceso de IoT
5. Realizar planificación de respuesta a incidentes
de IOT
6. Formular una gran estrategia de datos para
gestionar la vasta cantidad de datos de IoT
generados
7. Elaborar políticas para la privacidad de los datos
de los sensores
8. Proteja los dispositivos IoT
Conclusión
La huella de IoT variará en tamaño según la
industria vertical. A medida que las empresas
avanzan en el carro de IoT para ser más rentables
y poder llegar a un cliente extendido base,
necesitan tener una estrategia IoT que abarque
todo el ciclo de vida del dispositivo IoT (desde la
adquisición hasta el final de la vida útil) en su lugar.
Las empresas necesitan construir una estrategia
de riesgo de IoT que evalúe y maneja el riesgo.
Considerar IoT como parte de la cartera general de
seguridad y gestión de riesgos y tener un enfoque
dedicado a evaluar continuamente y monitorear
el riesgo de IoT. La adopción temprana de la
seguridad en el ciclo de vida del dispositivo IoT, a
nivel de hardware y software, es la mejor práctica.
El factor FUD mencionado anteriormente continuará
impulsando a la administración a invertir en seguridad
de la información y, más específicamente, seguridad
de IoT en un futuro próximo, al menos hasta que el
riesgo de brechas se reduzca.
Notas Finales
1 York, K.; “Dyn Statement on 10/21/2016
DDoS Attack,” Oracle, 22 October 2016,
http://dyn.com/blog/dyn-statement-on-
10212016-ddos-attack/
2 Ibid.
3 Martin, C.; “U.S. to Issue IoT Principles After
Internet Cyberattack,” MediaPost, 26 October
2016, www.mediapost.com/publications/
article/287614/us-to-issue-iot-principles-after-
internet-cybera.html
4 Atluri, I.; “The Rewards and Risks of Our
Smarter Future,” InfoSecurity Professional,
International Information Systems Security
Certification Consortium, Inc. November/
December 2014, www.isc2.org/uploadedfiles/
(isc)2_member_content/member_resources/
infosecurity_professional_magazine/infosecurity-
professional-magazine-nov-dec-2014.pdf
5  Op cit, Martin
6 Martin, C.; “U.S. Issues Guidelines for IoT
Security,” MediaPost, 18 November 2016,
www.mediapost.com/publications/
article/289288/us-issues-guidelines-for-iot-
security.html
7 Armerding, T.; “Feds Provide Legal Loophole
to Hacking IoT Devices,” CSO, 28 November
2016, www.csoonline.com/article/3144648/
internet-of-things/feds-provide-legal-loophole-
to-hacking-iot-devices.html
8 Lawson, S.; “Industrial IoT Inches Toward
Consensus on Security,” ComputerWorld,
19 September 2016, www.computerworld.com/
article/3122244/internet-of-things/industrial-iot-
inches-toward-consensus-on-security.html
9 Federal Trade Commission, “FTC Announces
Internet of Things Challenge to Combat
Security Vulnerabilities in Home Devices,” USA,
4 January 2017, www.ftc.gov/news-events/
press-releases/2017/01/ftc-announces-internet-
things-challenge-combat-security
10 Zurier, S.; “Z-Wave Alliance Ups IoT
Security,” SC MEDIA, 12 December 2016,
www.scmagazine.com/z-wave-alliance-
ups-iot-security/article/578656/
11 Gross, G.; “US Lawmakers Balk at Call for IoT
Security Regulations,” CSO, 16 November
2016, www.csoonline.com/article/3141920/
security/us-lawmakers-balk-at-call-for-iot-
security-regulations.html
12 CNBC, “New Cybersecurity Guidelines for
Medical Devices Tackle Evolving Threats,”
The Verge, 29 December 2016, www.cnbc.
com/2016/12/29/new-cybersecurity-
guidelines-for-medical-devices-tackle-evolving-
threats.html
13 Food and Drug Administration, “Postmarket
Management of Cybersecurity in Medical
Devices: Guidance for Industry and Food
and Drug Administration Staff,” USA,
28 December 2016, www.fda.gov/downloads/
MedicalDevices/DeviceRegulationandGuidance/
GuidanceDocuments/UCM482022.pdf
14 Zurier, S.; “No Clear Policy,” SCMagazine,
March 2017, https://media.scmagazine.com/
documents/287/0317_digital_edition_71636.pdf
15 Sun, L.; “IoT Stocks: What to Watch in 2017,”
The Motley Fool, 23 November 2016, www.fool.
com/investing/2016/11/23/iot-stocks-what-to-
watch-in-2017.aspx
16 Microsoft Secure Blog Staff, “The Emerging Era
of Cyber Defense and Cybercrime,” Microsoft
Secure Blog, 27 January 2016, http://blogs.
microsoft.com/microsoftsecure/2016/01/27/
the-emerging-era-of-cyber-defense-and-
cybercrime/
17 Dickson, B.; “Why IoT Security Is So
Critical,” TechCrunch, 24 October 2015,
https://techcrunch.com/2015/10/24/why-iot-
security-is-so-critical/
18 Moyle, E.; “Three Steps to Better Security in
IoT Devices,” TechTarget, July 2016, http://
internetofthingsagenda.techtarget.com/tip/
Three-steps-to-better-IoT-device-security-in-
the-enterprise
ISACA JOURNAL VOL 3 25
 19 Kerravala, Z.; “How Network Segmentation
Provides a Path to IoT Security,” NetworkWorld,
17 December 2015, www.networkworld.
com/article/3016565/security/how-network-
segmentation-provides-a-path-to-iot-security.html
20 D’Abreo, C.; “What CIOs Need to Know About
IoT and Security Risks,” Masergy Blog,
21 October 2015, www.masergy.com/blog/
what-cios-need-know-about-iot-and-
security-risks
21 SecureRF, “Why Dyn Suffered a DDoS Attack
and How Consumer IoT Device Security
Vulnerabilities Can Be Addressed,” 23 October
2016, www.securerf.com/dyn-suffered-ddos-
attack-consumer-iot-device-vulnerabilities-
can-addressed/
22 Stephenson, P.; “Access Control,” SC Magazine,
14 December 2016, www.scmagazine.com/
access-control/article/577086/2/
23 Cross, K.; “This Is the New Reality for
Cyber Security: Accept That Hackers Will
Get In,” MarketWatch, 10 December 2016,
www.marketwatch.com/story/this-is-the-new-
reality-for-cyber-security-accept-that-hackers-
will-get-in-2016-12-09
ISACA GLOBAL CONFERENCES
CONNECT FACE TO FACE WITH
A WORLD OF EXPERTISE.
Gain insights from industry experts and thought leaders. Network face to face with fellow IT professionals.
Earn CPEs by attending an ISACA conference. Embrace a world of expertise at ISACA International Conferences
in some of the globe’s most exciting cities. ISACA’s upcoming conferences include:
2017
29 – 31 May
Munich, Germany
www.isaca.org/eurocacs
2017
2 – 4 October
Washington, D.C., USA
www.isaca.org/csxna
26 ISACA JOURNAL VOL 3
24 Lawton, G.; C. McKenzie; S. Raman; “IoT
Applications Pose New Problems for
Developers,” TechTarget, February 2016,
http://internetofthingsagenda.techtarget.
com/ehandbook/IoT-applications-pose-new-
problems-for-developers
25 Sullivan, D.; J. Sullivan; “IoT Security Testing:
Cover All Your Bases,” TechTarget, May 2016,
http://internetofthingsagenda.techtarget.com/
feature/IoT-security-testing-Cover-all-your-bases
26 ForeScout Technologies, Inc., How Hackable Is
Your Smart Enterprise?, USA, 2016,
https://www.forescout.com/wp-content/
uploads/2016/10/iot-enterprise-risk-report.pdf
27 Zurier, S.; “When It Comes to IoT, More Security
Is Needed,” SC Magazine, 12 December 2016,
https://www.scmagazine.com/when-it-comes-
to-iot-more-security-is-needed/article/578654
28 Schulz, Y.; “Critical Success Factors for IoT
Projects,” ITWorldCanada Blog, 25 June 2015,
www.itworldcanada.com/blog/critical-success-
factors-for-iot-projects/375399
29 O’Donnell, L.; “8 Strategic Steps for Long-Term
IoT Security,” ITbestofbreed.com, 20 March
2015, www.itbestofbreed.com/slide-shows/8-
strategic-steps-long-term-iot-security/page/0/2
2017
2017 AFRICA ASIA PACIFIC
CACS
AN ISACA EVENT
TM CACS
AN ISACA EVENT
TM
11 – 12 September 29 – 30 November
Accra, Ghana Dubai, UAE
www.isaca.org/africacacs www.isaca.org/asiacacs
2017 2017
30 October – 1 November TBD
London, United Kingdom Singapore
www.isaca.org/csxeurope www.isaca.org/csxasia

IoT necesita una mejor seguridad
Também disponível em português
www.isaca.org/currentissue
El Internet de las cosas (IoT) es un ecosistema de
cosas conectadas (dispositivos estacionarios o
móviles). Un informe del Business 2016 informó que
habrá 34 mil millones de dispositivos conectados a
Internet en 2020, frente a 10 mil millones en 2015.
Además, los dispositivos IoT representarán 24 mil
millones de ellos, mientras que los dispositivos
informáticos tradicionales (por ejemplo, smartphones,
smartwatches) será de 10 mil millones. Y cerca de US
$ 6 billones se gastarán en soluciones IoT durante los
próximos cinco años1.
¿Por qué necesitamos seguridad IoT?
La industria está cambiando rápidamente y los
nuevos casos de uso de IOT están madurando.
Se está agregando cada vez más funcionalidad a
los sistemas IoT para obtener ventajas y ventajas
funcionales de primer nivel, mientras que la
seguridad de los dispositivos del sistema IoT se
suele ignorar durante el diseño. Esto es evidente a
partir de hackeos recientes:
• La Administración de Alimentos y Medicamentos
de los EE. UU. Emitió consejos de seguridad
para dispositivos cardíacos sobre la amenaza de
hacking, y el Hospital de Investigación St. Jude
para Niños corrigió los dispositivos médicos
vulnerables a dispositivos IoT2.
• Los piratas informáticos demostraron un ataque
inalámbrico en el automóvil modelo S de Tesla3.
• Los investigadores hackearon los TVs Vizio Smart
para acceder a una red doméstica4.
Otras fuentes de agujeros de seguridad ocurren
durante la instalación de IoT y la configuración
posterior a la instalación. Una encuesta de
seguridad ForeScout IoT declaró que “los
encuestados, que inicialmente pensaban que no
tenían dispositivos IoT en sus redes, en realidad
tenían ocho tipos de dispositivos IoT (cuando se
les pidió que eligieran de una lista de dispositivos)
artículo
artículo
y sólo 44 por ciento de los encuestados tenían una
política de seguridad conocida Para IoT”5.
¿Tienes algo que
comentar sobre
este artículo?
Sólo el 30 por ciento está seguro de que realmente Visita las páginas del
saben lo que los dispositivos IoT están en su red6. Journal en el sitio web
de ISACA® website
Estos hackeos y sus implicancias de los resultados (www.isaca.org/
de la encuesta de ForeScout indican que la seguridad journal), encuentra el
de IoT debe ser implementada holísticamente. Esto artículo y hace click
requiere entender la arquitectura IoT. en el link Comments
para compartir tus
Arquitectura IoT pensamientos.
El Zachman Framework7 responde por qué, cómo, qué,
quién, dónde y cuándo preguntas alrededor de IoT.
Respuestas a cómo y qué preguntas se explican en
las cuatro capas de arquitectura. La Figura 1 muestra
“La arquitectura de seguridad de IoT explicada a través
de” preguntas que se deben responder a través del
enfoque de Zachman Framework.
Figura 1—Arquitectura contextual de
Zachman Framework para la seguridad IoT
Preguntas Seguridad IoT
¿Porqué? Ejemplos de infracciones de seguridad,
modelado de amenazas
¿Cómo? Configuración e integración de dispositivos,
estándares, procesos
¿Qué? Lista de componentes y sus relaciones
¿Quén? Usuario, administrador, proveedor, organismos
de la industria
¿Donde? En cada capa y componente de la arquitectura
¿Cuándo? Diseño, configuración/implementación y
operaciones
Fuente: H. Patel. Reimpreso con permiso.
Hemant Patel, CISM, ITIL, PMP, TOGAF
Es un asesor principal de Computer Sciences Corporation, SC, como
parte del equipo de Chief Technology Officer de los Estados Unidos.
Su experiencia incluye arquitectura empresarial de TI, seguridad de la
información, planificación de carteras, grandes datos, web y comercio
electrónico, análisis, planificación de recursos empresariales y sistemas de
gestión de relaciones con clientes. Su experiencia global incluye trabajar en
las industrias de defensa, manufactura, salud, servicios públicos, banca y
seguros. Patel puede ser contactado en hpatel63@csc.com o mr.hemant.
patel@hotmail.com.
ISACA JOURNAL VOL 3 27
 Una comprensión conceptual de alto nivel de IoT software de gestión de IoT hub y Gateways, y hay
¿Te gusto este implica entender los requisitos de seguridad de IoT. una plétora de estándares. Organizaciones como
La información fluye de la capa de borde (es decir, Microsoft, IBM y Allegro han hecho un buen trabajo
artículo? dispositivos IoT, ensamblajes/máquinas) a la capa al envolver la seguridad basada en dispositivos en
de datos a la capa de inteligencia empresarial (BI) interfaces de programación de aplicaciones (API) y
• Lea Internet of
a la capa de operaciones y estrategia (OpS), como herramientas de nivel superior. Los componentes
Things: Risk
se muestra en la figura 2. Una red local o una WAN básicos de la arquitectura de seguridad de la capa
and Value
conectan dispositivos y capas. A menudo, muchos de borde se representan en la figura 3. El hub o el
Consideration.
dispositivos se agrupan para soportar un conjunto Gateway soportan administración de seguridad,
www.isaca.org/
de componentes o una máquina. La comunicación administración de almacenamiento y componentes de
internet-of-things
entre dispositivos puede o no estar presente en comunicaciones relacionados con la seguridad de IoT.
una máquina. Los dispositivos y conjuntos se
• Aprenda más
conectan a una puerta de enlace para encapsular Los dispositivos pueden interconectarse o
acerca, discute
características únicas del dispositivo y para una comunicarse con hub, y como software de
y colabora
mejor estandarización y gestión. comunicación necesita una huella o footprint con
sobre políticas
capacidad de encolamiento.
de seguridad y
Un enfoque holístico incluye seguridad para cada
procedimientos
capa y seguridad de las comunicaciones entre
en el Centro de
las capas. Las capas distintas de la capa de
Conocimientos.
borde pueden alojarse en locales o en la nube. Es Un enfoque de
www.isaca.org/
information-security-
importante entender los requisitos de seguridad en
cada una de las capas.
seguridad holístico
policies-and-
procedures
incluye seguridad
Seguridad de la capa de borde
para cada capa y
La seguridad de IoT debe ser parte de los temas
relevantes de la seguridad de la información. Los
seguridad de las
dispositivos/sensores de borde producen datos que comunicaciones
son procesados por componentes ascendentes de la
arquitectura IoT. El volumen de datos producidos por entre las capas.
estos dispositivos es mucho más que el volumen de
datos producidos por la actividad de los usuarios de
Internet. El protocolo TCP (Transmission Control Protocol)
basado en socket, la comunicación peer-to-peer
Hay una competencia significativa en la seguridad utilizado anteriormente, se ha mejorado incluyendo
basada en dispositivos y un amplio espectro de mejores protocolos como:

Figura 2—IOT Arquitectura Conceptual

Capa de Borde Capa de Dato Capa BI Capa OpS

Capa de gestión de la seguridad de la información

Fuente: H. Patel. Reimpreso con permiso.

28 ISACA JOURNAL VOL 3

 Figura 3—IoT Arquitectura seguridad conceptual de la capa de borde

Sensores Capa de Datos

Almacenamiento
Encolamiento
MQTT Cubo
Encriptación
CoAP
Administración Seguridad Almacenamiento
Comunicación
Provisionamiento de dispositivos Encolamiento
Encriptación
Gestión de Accesos Encriptación HTTPS
Lista Blanca
Cable Políticas del dispositivo
Comunicación
o
Wi-Fi
Diagnóstico Remoto
Encriptación Administrador
Parche Remoto
Respuesta Lista Blanca
Configuración Remota
Realimentación
Switch
Válvula
....

Fuente: H. Patel. Reimpreso con permiso.

• Message Queuing Telemetry Transport
(MQTT)—Un protocolo basado en TCP
que admite la autenticación del dispositivo,
encriptación SSL (Secure Sockets Layer),
seguridad en la capa de transporte (TLS), encola
publica/suscribe capacidades
• Constrained Application Protocol (CoAP)—
Protocolo de transporte basado en protocolo
de datagramas de usuario (UDP), soporta micro
dispositivos y tiene una huella mucho menor
que HTTP. Soporta cifrado Advanced Encryption
Standard (AES )8.
debido a una violación de seguridad o por otras
razones. Un mal funcionamiento puede provocar
que un dispositivo vuelva a intentar acceder a los
datos, y sin una configuración adecuada que limite
el número de reintentos, puede haber un número
infinito de reintentos. Cuando cada reintento envía
un mensaje de error al hub, el concentrador puede
terminar recibiendo mensajes de error infinitos (similar
a un ataque distribuido de denegación de servicio
[DDoS]) y el concentrador de IoT podría dejar de
operar debido a una carga excesiva, afectando así
Disponibilidad del centro.

Un mal funcionamiento puede impedir que un

Una red de área local inalámbrica (WLAN) se utiliza en
muchos sectores con seguridad WPA2. La seguridad
Wi-Fi es más comúnmente hackeada debido a la
configuración de seguridad inadecuada y la mala
elección de contraseñas.
Una puerta de enlace puede conectarse a varios
concentradores y proporcionar protocolos de
transferencia de datos de nivel superior como
HTTPS, que admite el cifrado TLS y la mensajería de
Representational State Transfer (REST)-Simple Object
Access Protocol (SOAP).
Los proveedores de dispositivos y hub necesitan
soportar protocolos de seguridad y administración,
como se describe aquí, y este soporte puede
complicarse debido a múltiples protocolos y
aseguramiento de la autenticación.
Otro problema a vigilar es el mal funcionamiento del
dispositivo IoT. Un mal funcionamiento puede ocurrir
dispositivo IoT genere datos. Esto hace que el
concentrador no reciba ningún dato, lo que afecta
la integridad del concentrador. Por lo tanto, un mal
funcionamiento del dispositivo puede afectar la
disponibilidad y la integridad (cualidades básicas de la
seguridad de la información) de la seguridad IoT.
Seguridad de la capa de datos
La capa de datos incluye actividades como
la ingesta de datos, la ingeniería de datos y la
transformación de datos mediante SQL (Structured
Query Language) o tecnologías NoSQL con bases
de datos/almacenes tradicionales o grandes
tecnologías de datos. Las bases de datos basadas
en SQL ofrecen títulos de fila y columnas. Las
grandes tecnologías de datos anteriores sólo
ofrecían seguridad de nivel de sistema operativo
o de sistema operativo (OS), pero ahora ofrecen
seguridad de nivel inferior, por ejemplo, Apache
Sentry9 con autorización basada en roles.

ISACA JOURNAL VOL 3 29


Las subcapas de seguridad en esta capa incluyen
seguridad de red, autenticación y autorización,
enmascaramiento y/o cifrado estándar de
la industria de almacenamiento de datos y
administración de datos. La administración de
datos requiere una discusión aparte, pero incluye
la arquitectura de datos empresariales, el linaje
de datos, la auditoría y el gobierno. Una mala
arquitectura de datos y/o una mala gestión del
linaje de datos podría comprometer la consistencia
y disponibilidad de los datos.
La confidencialidad debe ser mantenida por
adherirse a varios estándares de la industria tales
como la Ley de Portabilidad y Responsabilidad
de los Seguros de Salud de los Estados Unidos
(HIPAA) y los Datos de la Industria de Tarjetas de
Pago Norma de seguridad (PCI DSS) que rige el
almacenamiento, el acceso y la transmisión de
datos. Un artículo anterior de ISACA® Journal,
titulado “Regreso al futuro en la seguridad
de los dispositivos: aprovechar las FIPP para
gestionar proactivamente la privacidad y el riesgo
de seguridad de IoT”10, explica el diseño de
consideraciones de privacidad en el procesamiento
de datos generados a partir de componentes IoT.
Capa de seguridad BI
El enmascaramiento de datos, la autorización
basada en funciones y el inicio de sesión único (SSO)
proporcionan seguridad en esta capa, además de
la seguridad de la red y los firewalls. La gestión del
modelo BI (predictivo, prescriptivo) es un tema de
gobernanza de la información. Se requieren pruebas
y validación suficientes para estos modelos. El
uso de inteligencia defectuosa puede conducir a
decisiones de negocios mal informadas, que pueden
arruinar la Reputación y credibilidad.
30 ISACA JOURNAL VOL 3
Tecnologías de prevención de pérdida de datos (DLP)
y respaldo deben también ser considerados para
mayor seguridad.
Seguridad de la capa de OpS
Existe de retroalimentación desde las aplicaciones/
sistemas de operación a los dispositivos. La
seguridad de red tradicional y los firewalls, el
acceso y las autorizaciones de las aplicaciones
basadas en funciones y el SSO proporcionan
seguridad en esta capa.
Las herramientas de DevOps minimizan el riesgo
de una construcción incorrecta y/o Configuración
incorrecta, lo que podría afectar la disponibilidad
del sistema.
Un mal
funcionamiento del
dispositivo puede
afectar la disponibilidad
e integridad (cualidades
básicas de la seguridad
de la información) de la
seguridad de IoT.
Una estrategia puede decidir un curso de acción
basado en los resultados de BI. Una estrategia puede
ser simplemente monitorear los datos recibidos
de los dispositivos IoT, o puede incluir procesar
datos recibidos de dispositivos IoT y alterar el
comportamiento de los dispositivos IoT basados
en límites aceptables de lecturas de datos de los
dispositivos. Tanto la estrategia (requisito y diseño)
como el ciclo de retroalimentación (implementación)
necesitan ser validados/probados.
Modelado de amenazas y gestión de
riesgos
La Figura 2 muestra un ciclo de realimentación
opcional de la capa OpS a la capa de borde. En
los casos en que falta el ciclo de retroalimentación
y los datos de los dispositivos se consideran no
sensibles, se puede reducir el acceso a los datos y
la seguridad de cifrado de acuerdo con la gestión
de riesgos adecuada.
Las estrategias de mitigación y respuesta al riesgo
pueden basarse en las siguientes preguntas:
• ¿Puede un dispositivo comprometido comprometer
otros dispositivos o el concentrador?
• ¿Con qué rapidez puede detectarse y aislarse un
dispositivo comprometido?
• ¿Cuál es el impacto de un dispositivo
comprometido?
Seguridad IoT
no significa sólo
seguridad a nivel de
dispositivo; Debe
aplicarse a todos los
componentes y capas
del sistema IoT.
Estas preguntas no son exhaustivas y deben
utilizarse como guía inicial para la gestión del
riesgo.
Conclusión
La seguridad de IoT a menudo carece de
consideración prioritaria cuando se están diseñando
e implementando sistemas basados en IoT.
Seguridad IoT no significa sólo seguridad a nivel de
dispositivo; debe aplicarse a todos los componentes
y capas del sistema IoT. La seguridad debe ser
abordada en todas las etapas del ciclo de vida
del sistema IoT incluyendo las fases de diseño,
instalación, configuración y operación.
Adicionalmente, las contraseñas fuertes y las claves
de certificados, los identificadores y nombres de
dispositivos o host difíciles de adivinar, el monitoreo
y análisis de registros, la administración proactiva
de usuarios y dispositivos y la adhesión a guías
industriales y recomendaciones de seguridad
de organizaciones como el US National Institute
of Standards and Tecnología y la Organización
Internacional de Normalización complementarán la
seguridad del sistema IoT.
Notas Finales
1 BI Intelligence, “Here’s How the Internet of
Things Will Explode by 2020,” Business Insider,
31 August 2016, www.businessinsider.com/iot-
ecosystem-internet-of-things-forecasts-and-
business-opportunities-2016-2
2 Bacon, M.; “St. Jude Medical Finally Patches
Vulnerable Medical IoT Devices,” TechTarget, 13
January 2017, http://searchsecurity.techtarget.
com/news/450410935/St-Jude-Medical-finally-
patches-vulnerable-medical-IoT-devices
3 Golson, J.; “Car Hackers Demonstrate
Wireless Attack on Tesla Model S,” The
Verge, 19 September 2016, www.theverge.
com/2016/9/19/12985120/tesla-model-s-hack-
vulnerability-keen-labs
4 Zorz, Z.; “Researchers Hack Vizio Smart TVs to
Access Home Network,” Help Net Security,
12 November 2015, https://www.
helpnetsecurity.com/2015/11/12/researchers-
hack-vizio-smart-tvs-to-access-home-network/
5 ForeScout, IoT Security Survey Results, https://
www.forescout.com/iot-security-survey-results/
6 Ibid.
7 Zachman, J.; “The Concise Definition of the
Zachman Framework,” Zachman International
Enterprise Architecture, 2008, https://www.
zachman.com/about-the-zachman-framework
8 Eclipse, MQTT and CoAP, IoT Protocols,
www.eclipse.org/community/eclipse_
newsletter/2014/february/article2.php
9 Sentry, Apache Sentry, http://sentry.apache.org/
10 Rotman, D.; C. Kypreos; S. Pipes; “Back to the
Future in Device Security: Leveraging FIPPs to
Proactively Manage IoT Privacy and Security
Risk,” ISACA® Journal, vol. 6, 2015,
https://www.isaca.org/Journal/archives
ISACA JOURNAL VOL 3 31
 Aseguramiento de la seguridad
en el SDLC para la internet de
las cosas
Durante el Internet of Things (IoT) Village celebrado en que estén libres de defectos de seguridad. En este
¿Tienes algo la conferencia de seguridad DEF CON en agosto de artículo se describen las técnicas y procesos de
que comentar 2016, 47 nuevas vulnerabilidades que afectaron a 23 aseguramiento involucrados para asegurar dichas
sobre dispositivos IoT de 21 fabricantes fueron revelados1. aplicaciones y proporcionar orientación sobre la
este artículo? Entre estas 47 vulnerabilidades se encontraban implementación en todo el entorno de IoT.
Visita las páginas del vulnerabilidades relacionadas con software, por
Journal en el sitio web ejemplo, fallas de diseño, contraseñas codificadas, Componentes de software IoT
de ISACA® website secretos de configuración, problemas criptográficos
(www.isaca.org/ y Defectos de codificación comunes, tales como Cada componente IoT tiene su propio software.
journal), encuentra el desbordamientos de búfer, entradas invalidadas e ¿Cómo se puede asegurar que, mientras se
artículo y hace click inyección de comandos. ejecuta en un entorno real, el componente no
en el link Comments está permitiendo a las personas malintencionadas
para compartir tus El software que se ejecuta en los dispositivos, los hackear el software y tener acceso a los datos e
pensamientos. pórticos, las aplicaciones móviles y de centro de información recopilados por los dispositivos? El ciclo
datos y las interfaces de programa de aplicación (API) de vida de desarrollo de software seguro (S-SDLC) es
de interfaz desde las que se consumen los servicios la respuesta a la seguridad de software. La Figura 1
deben estar sujetos a una garantía para garantizar representa los componentes IoT típicos.

Figura 1—Componentes típicos de IoT

Móvil
Dispositivo 1 aplicaciones

Dispositivo 2
Nodo de la Aplicaciones en
pasarela o del la nube y
Dispositivo 3 controlador data center

Bluetooth, MQTT, Wi-Fi

Mantenimiento Zigbee, 6LOWPAN, Zwave
físico
Dispositivo n Cableado, Wi-Fi, 3G / 4G
Wi-Fi, 3G/4G
Serial, Optical Ports
Fuente: S. Subramanian and B. Swaminathan. Reimpreso con permiso.

Sivarama Subramanian, CISA Balaji Swaminathan M., CISA, CISSP

Es arquitecto de seguridad principal en Cognizant
Technology Solutions, donde lidera la entrega e
investigación de evaluación de vulnerabilidades
integradas, permitiendo nuevas implementaciones
de servicios y alineando las nuevas tendencias
de seguridad con las necesidades de los clientes.
Subramanian puede ser alcanzado en
sivaramasubramanian.kailasam@cognizant.com.
. balajiswaminathan.m@cognizant.com.
32 ISACA JOURNAL VOL 3
Es arquitecto de seguridad en Cognizant
Technology
Solutions, donde está gestionando la entrega
e investigación de evaluación de vulnerabilidad
integrada, permitiendo nuevos despliegues de
servicios y alineando las nuevas tendencias
de seguridad con las necesidades de los
clientes. Swaminathan puede ser contactado en

La seguridad debe estar integrada en el ciclo
de desarrollo de los componentes IoT, ya sean
el firmware del dispositivo, el código fuente del
pórtico de enlace, el código fuente de la aplicación
o el código fuente de la API.
Las aplicaciones en un entorno IoT típico pueden
caer en una de las siguientes categorías:
1. Aplicaciones de dispositivos que residen en los
nodos y pórticos, por ejemplo, una aplicación
basada en node.js o Python que se ejecuta en un
medidor de energía inteligente
2. Controlar aplicaciones que controlan y regulan el
entorno IoT, por ejemplo, aplicaciones basadas
en web o no basadas en web, creadas en Java,
Dot Net, Perl o PHP, que habitualmente residen
en el centro de datos o en el sistema operativo
de aplicaciones móviles, desde donde los
dispositivos pueden ser controlado
3. Consumir aplicaciones que reciben datos de los
dispositivos para procesamiento adicional, por
ejemplo, aplicaciones web o no basadas en web,
que habitualmente residen en el centro de datos,
que realizan análisis sobre los datos recibidos
4. Servicios de retransmisión que formatean y
transfieren datos entre diferentes componentes,
por ejemplo, API, servicios web que transportan
los datos a través de dispositivos, aplicaciones y
otros componentes IoT
Hay dos categorías de vulnerabilidades relacionadas
con el software. Esos son:
1. U
 na interfaz web insegura, que podría permitir que
se produzcan algunos de los siguientes ataques
comunes:
•A
 taque de inyección—Ejecución maliciosa
de scripts, consultas de bases de datos,
comandos de nivel de sistema inyectados a las
aplicaciones
•S
 ecretos no protegidos—Secretos de
configuración de texto claro/no encriptado,
llaves y contraseñas
•E
 scalamiento de privilegios—Elevación
de privilegios de usuario y suplantación de
usuarios
2. Software/firmware inseguro que permite a los
usuarios malintencionados cambiar el software
o comprometer el dispositivo, que puede usarse
como un dispositivo BOT (robot de software):
artículo
artículo
• Corrupción de firmware—Envío de firmware
malintencionado que podría formatear
incorrectamente la Lógica del dispositivo o
instalar una puerta trasera
• Firmware no firmado—Obligar a los
dispositivos a descargar firmware de fuentes no
autorizadas sin validación
Seguir un enfoque seguro de SDLC mitigaría
las fallas comunes de codificación y las
vulnerabilidades de software relacionadas con los
componentes de IoT.
Pasos seguros para solucionar
defectos de codificación comunes y
vulnerabilidades de software
El costo de corregir un error de seguridad varía
dependiendo de dónde se descubre. Si se descubre
en el entorno de producción, el costo de su corregirlo
incluiría los costos tangibles del esfuerzo del
desarrollador, el esfuerzo del probador, el esfuerzo
de prueba de aceptación del usuario y el esfuerzo de
despliegue, y el costo intangible de la reputación y la
confianza del cliente. Si se descubre durante la fase
de diseño, entonces es muy fácil corregir la falla de
diseño e introducir una medida de seguridad durante
la fase de desarrollo. El costo de corregir un defecto
postproducción es aproximadamente cuatro veces
más que corregirlo en la etapa de desarrollo2.
El costo de corregir un defecto
postproducción es aproximadamente
cuatro veces más que corregirlo en
la etapa de desarrollo.
La seguridad del software IoT es el nivel de confianza
de que el software está libre de vulnerabilidades (ya
sea intencionalmente diseñadas dentro del software
o insertadas accidentalmente en cualquier momento
durante su ciclo de vida) y el software funciona de la
manera prevista. El aseguramiento de la seguridad
de las aplicaciones de IoT puede lograrse mejor
mediante la adopción de una estrategia de defensa
en profundidad que, a su vez, garantiza tener una
práctica segura de SDLC (figura 2). La intención
ISACA JOURNAL VOL 3 33
 Figura 2—A SDLC seguro

Análisis de Arquitectura Estado

Comienzo Requisitos y Desarrollo Prueba Despliegue Estable
Diseño

Establezca su Derivar los Desarrollar Entrenamiento Realización de Protección Realización de

necesidad de requerimientos diseño de de codificación pruebas del ambiente evaluación
seguridad en de seguridad directrices de segura durante dinámicas de contínua
SDLC sus Políticas el desarrollo seguridad de Realización de
Identificar los revisión las aplicaciones pruebas de Gestión de
Sesiones requerimientos Modelo de equipos penetración configuración
conciencia de de cumplimiento Amenazas y parches Incorporación
la seguridad de seguridad Uso de listas de de seguridad
(SOX, PCI DSS, Arquitectura verificación y Monitoreo de en todas las
HIPAA, GLBA) de seguridad lineamientos log y amenazas fases del
y revisión ciclo de vida
del diseño Prueba de Incidentes
rendimiento y
seguridad de
las aplicaciones

Fuente: S. Subramanian and B. Swaminathan. Reimpreso con permiso.

principal es construir la seguridad dentro del ciclo
de vida de estas aplicaciones desde el punto cero
que potencialmente y gradualmente reduce las fallas
en seguridad, diseño, Implementación y despliegue.
El cumplimiento adecuado de estas mejores
prácticas de aseguramiento dará lugar a aplicaciones
carentes de vulnerabilidades que pudieran haber
sido introducidas accidental o intencionalmente en
cualquier punto de tiempo en su ciclo de vida.
Comienzo y requisitos
La gestión eficaz de la seguridad de los
componentes involucrados es un área de enfoque
crítico porque un entorno IoT típico se difunde
ampliamente, tanto físicamente (con numerosos
dispositivos) como lógicamente (con múltiples
tecnologías y aplicaciones). Esta gestión eficaz sólo
Las sesiones de concienciación
puede lograrse con un inventario adecuado de lo
que se va a gestionar, como es:
• Categoría por tipo de desarrollo—La categoría
por tipo de desarrollo depende de dónde se
desarrolló el software/API, por ejemplo, desarrollo
interno, desarrollo de proveedores/socios,
comercial/comercial empaquetado o de código
abierto. Esto también es vital para derivar la
gobernanza de la seguridad y las políticas con las
que se adhieren para cada uno de estos tipos.
• Categoría por tipo de aplicación—La categoría
según el tipo de aplicación depende de dónde
resida el software o la API, por ejemplo,
dispositivo (nodos o pórticos), servidores de la
nube/data center, móviles o equipos de escritorio.
Esto dictaría las guías de codificación seguras,
listas de comprobación, configuración de
seguridad aplicable a cada uno de los tipos de
aplicación en consonancia con las políticas de
seguridad.

sobre la seguridad de las Las puertas de control S-SDLC, como la revisión

aplicaciones, las amenazas y las de diseño/modelado de amenazas en la fase de
diseño o las pruebas de seguridad de aplicaciones
brechas recientes deben realizarse estáticas en la fase de desarrollo, tienen que ser
obligatorias. Todo el ciclo SDLC tiene que ser
temprano en el ciclo de vida y monitoreado y administrado para una mejora
en forma regular para impartir continua en la entrega de software rápido
pero seguro a la producción. Estas soluciones
la necesidad de hacer cumplir la administradas son vitales para facilitar el proceso

seguridad en las aplicaciones en de seguridad y son altamente recomendables.

todas las etapas del ciclo de vida. Dependiendo de los niveles de riesgo percibidos
para las aplicaciones, las puertas de control pueden
ser derivadas. Las implementaciones incrementales

34 ISACA JOURNAL VOL 3

y rápidos requieren supervisión a lo largo del ciclo
Figura 3—Amenazas específicas por
de vida del desarrollo hasta su funcionamiento, Industria
especialmente en el caso de mejorar mediante
DevOps, junto con un criterio de aceptación bien Industria Amenzas
definido desde el punto de vista de la seguridad. Automovil Seguridad humana, control no
autorizado de los vehículos
Las sesiones de concientización sobre la seguridad autodirigidos, uso del sistema
de posicionamiento global
de las aplicaciones, las amenazas y las brechas
(GPS)
recientes deben realizarse temprano en el ciclo de
vida y en forma regular para impartir la necesidad Cuidado de la salud El robo de datos médicos,
la manipulación de
de hacer cumplir la seguridad en las aplicaciones
dispositivos médicos (por
en todas las etapas del ciclo de vida. ejemplo, marcapasos,
monitor de presión arterial,
Fase de diseño desfibriladores) que podrían
funcionar mal y representar
Durante la fase de diseño, la arquitectura y el una amenaza para la vida de
diseño de la solución IoT se revisarán utilizando los pacientes
técnicas de modelado de amenazas. Los actores Energía Robo de energía, calibración
de amenaza y los posibles escenarios de amenaza de datos de medición no
deben ser enumerados para cada uno de los autorizada, apagado de la red
componentes de IoT. Por ejemplo, un escenario Dispositivos electrónicos Mal funcionamiento del
de amenaza podría ser un posible problema de dispositivo electrónico que
integridad de datos debido a la falta de controles podría conducir a amenazas
de autenticación en el dispositivo. Después de la en la vida del consumidor o
enumeración de las amenazas, las contramedidas consumo de dispositivos no
autorizados
pueden ser clasificadas y recomendadas.
Fuente: S. Subramanian and B. Swaminathan. Reimpreso con permiso.

El enfoque estándar para el modelado de amenazas

utilizando los modelos STRIDE y DREAD es el
siguiente:
• STRIDE—Categorización de amenazas
considerando spoofing, adulteración, repudio,
revelación de información, denegación de servicio
y elevación de privilegios
• DREAD—Atributos de clasificación de amenaza
considerando la posibilidad de descubrir,
reproducir, explotar, usuarios afectados y
potencial de dañol
Este método será suficiente para revisar la
arquitectura IoT, con una amenaza adicional
centrada en la seguridad física de los dispositivos.
Las amenazas comunes aplicables a la seguridad
física son el robo de dispositivos, la clonación
de dispositivos y el acceso físico no autorizado.
La principal diferencia en el análisis del modelo
de amenaza estándar y revisiones de diseño es
la aplicación del conocimiento de las amenazas
específicas de la industria. La Figura 3 muestra
algunas de estas amenazas únicas de la industria.
Los controles que se deben incorporar en las
aplicaciones IoT y las API son:
• Validación de entrada—Manejo de datos de
entrada de usuarios, aplicaciones y servicios
• Autenticación—Identificación y verificación de
usuarios y tráfico
• Autorización—Reforzar el control de acceso para
todas las solicitudes a la aplicación
• Gestión de la configuración—Protección de
datos de configuración y metadatos, acceso a la
consola
• Seguridad de datos y privacidad—Seguridad
de datos sensibles y confidenciales, como
información de salud protegida u otra información
de identificación personal
• Gestión de sesiones—Iniciar, gestionar y finalizar
las sesiones de una aplicación con seguridad
• Criptografía—Uso de algoritmos de encriptación,
hash y de intercambio de claves fuertes,
certificados digitales y firmas

ISACA JOURNAL VOL 3 35

 • Gestión de excepciones—Manejo seguro de
excepciones de las aplicaciones
• Auditoría y registro —Registro de todos los
eventos con los atributos necesarios para la
rendición de cuentas
• Seguridad de la comunicación—Seguridad del
tráfico hacia y desde la aplicación
• Disponibilidad—Manejo seguro de cargas en las
aplicaciones
Los resultados de la revisión de diseño y las
actividades de modelado de amenazas deben
hacer cumplir la incorporación de estándares
y marcos autorizados, módulos, API y
especificaciones de diseño, por ejemplo, Spring
Security para control de acceso o AES 256 o
superior para el cifrado. Esto asegura una línea de
base segura en el diseño, que fluirá a través del
SDLC, lo que reduce considerablemente el número
de defectos de seguridad en fases posteriores.
Los marcos o APIs no autorizados o no verificados
que se extraen de los repositorios públicos deben
ser evitados. En caso de que exista una necesidad
comercial para el uso de dichos módulos, se deben
realizar los siguientes pasos:
• Enumerar si existen vulnerabilidades y
explotaciones conocidas asociadas con la base
de código.
• Asegúrese de que sólo se utiliza la versión
actualizada.
• Analizar minuciosamente el código y corregir las
vulnerabilidades (fase de desarrollo).
Las soluciones de diseño de seguridad para
las amenazas percibidas y estándar tienen que
ser cuidadosamente pesadas y proporcionadas
basadas en múltiples factores, por ejemplo,
casos de uso involucrados, entrada y salida, tipo
de aplicación y tecnología, y especificaciones
del dispositivo. Educar a los arquitectos y
desarrolladores de aplicaciones en las directrices
de diseño seguro e incorporar estas directrices en
el diseño también mejorará en gran medida la línea
base de seguridad.
Fase de desarrollo
Durante la fase de desarrollo, ya se trate de un
desarrollo ágil o de cascada, se debe impartir
formación sobre codificación segura basada en
el proyecto de seguridad Open Web Application
(OWASP) Top 103 o Top 9,4 SANS Top 25,5 o CERT6 a
36 ISACA JOURNAL VOL 3
todos los desarrolladores y tiene que ser obligado a
intervalos regulares para mantenerse al tanto de los
últimos avances contra nuevos ataques y amenazas.
Los desarrolladores también deben ser entrenados
en la programación de sistemas embebidos, o los
programadores de sistemas integrados se utilizan
para diseñar las aplicaciones que están integradas
específicamente en los dispositivos/hardware. Tales
aplicaciones pueden ser completas o mejoras a las
aplicaciones existentes.
Integración
continua de
mejores prácticas
de seguridad,
herramientas y
evaluaciones para
ayudar en la entrega
continua debe
ser practicada e
implementada con la
automatización.
Además de las vulnerabilidades estándar y prácticas
de codificación inseguras en los lenguajes de
programación comunes (por ejemplo, Java, J2EE,
PHP, .NET), las especificaciones específicas
de código de hardware y código que rigen los
sistemas embebidos (Embedded C/C ++) deben
ser inspeccionados sobre la base de las normas de
codificación segura mencionadas anteriormente.
Las firmas de vulnerabilidad personalizadas y los
casos de prueba también pueden desarrollarse
dependiendo de la naturaleza de la lógica
implementada, las API y las librerías que se
encuentran en los dispositivos que gobiernan el
hardware subyacente, el almacenamiento persistente
y no persistente, el ciclo de vida del firmware, las
técnicas de codificación y los defectos que residen
en fuentes abiertas.
La concientización también debe ser impartida a los
desarrolladores en el ataque de IoT y las superficies
de amenaza, porque el software que se espera
ellos desarrollen se supone que interactúan con los
objetos del mundo real. Los entornos de desarrollo
integrados de software (IDE) deben estar habilitados
con plugins de revisión de código seguro para realizar
comprobaciones de seguridad durante el tiempo de
check-out. Un analista de seguridad independiente
podría revisar el código estable para cualquiera de
las fallas de seguridad mencionadas anteriormente,
acceso no autorizado a secretos y problemas de
sesión de clave secreta.
Para los despliegues rápidos e incrementales, el
ejercicio de puertas de control formales (como en
los modelos de cascada tradicionales) podría no
ser prácticamente factible. La integración continua
de mejores prácticas de seguridad, herramientas
y evaluaciones para ayudar en la entrega continua
debe ser practicada e implementada con la
automatización. En otras palabras, el desarrollo
continuo es y siempre debe ir acompañado de
evaluaciones automatizadas continuas para
asegurar que todos los cambios de software y API
sean sometidos a un control de seguridad y solo
una construcción autorizada se implemente en la
siguiente fase. Las construcciones erróneas se
deben devolver automáticamente para solucionar las
vulnerabilidades.
Evaluar un software o una API puede lograrse más
eficazmente cuando el código fuente está disponible,
ya que puede ser inspeccionado directamente
en busca de vulnerabilidades. Cuando se utilizan
productos de blackbox, cuyo diseño y código
fuente no están disponibles, sólo se puede realizar
una evaluación de vulnerabilidad estándar en las
aplicaciones o API en la fase de prueba. Debe
prestarse la debida atención al software de código
abierto no estándar y las API que se aprovechan
de los repositorios públicos, como se especifica en
la fase de diseño. Dado que tal software y API no
pueden haber sido sometidos a un desarrollo seguro,
deben ser examinados a fondo por vulnerabilidades
conocidas y personalizadas. Este examen debe
utilizar herramientas que están especializados en
la identificación de vulnerabilidades en software de
código abierto.
Mientras que los requisitos sirven como historias de
usuarios (en los modos Agile), los desarrolladores
pueden aprovechar los complementos y las
herramientas que se integran con los servidores de
compilación (por ejemplo, Jenkins, Bamboo) y realizar
evaluaciones sobre la marcha basadas en registros.
Los casos de prueba y la lista de vulnerabilidades
deben ser revisados continuamente y devueltos al
ciclo, y el ciclo debe pasar a las siguientes fases
basándose en los criterios de aceptación. El mismo
modo de suministro continúo potenciado mediante
evaluaciones continuas puede aprovecharse también
para la fase de prueba.
La evaluación de
un software o API
puede lograrse más
eficazmente cuando
el código fuente
está disponible,
ya que puede ser
inspeccionado
directamente por
vulnerabilidades.
Fase de prueba
Dependiendo del tipo de aplicación de IoT y de las
API en vigor, la necesidad y el tipo de evaluaciones
de seguridad que se realizarán se pueden decidir
como corresponde. Algunas evaluaciones típicas
que tienen que ser realizadas incluyen.
• Evaluación de la vulnerabilidad o prueba
dinámica de seguridad de aplicaciones
(DAST)—Asegurar la entrada y el tráfico de/a la
aplicación se prueben a fondo para enumerar las
vulnerabilidades que prevalecen según lo dictado
por estándares tales como OWASP (Web Top 107,
IoT Top 108, Móvil Top 109, grueso cliente),
Web Application Security Consorcio (WASC)10
y SANS Top 2511. Estos deben realizarse en
todas las aplicaciones siguientes utilizadas
en el entorno IoT:
– Aplicaciones web
- Aplicaciones móviles
- Aplicaciones de dispositivo
- Thick Clients
- Servicios Web y API (sencillos y transferencia de
estado representacional)
• Ingeniería inversa y depuración—Invierte las
aplicaciones desde sus binarios; Interpretar
ISACA JOURNAL VOL 3 37
 cualquier lógica oculta, controles y secretos; y
volver a su estado original después de pasar
por alto y alterar la lógica oculta. Esto será
más aplicable a las aplicaciones móviles y las
aplicaciones de dispositivos, donde se alojan gran
parte de la lógica y los controles de la aplicación.
Como con cada fase SDLC, la fase de prueba
asociada con las aplicaciones debe consistir en
las actividades de evaluación relacionadas con
los puntos finales físicos (por ejemplo, sensores
y nodos). El riesgo físico puede variar entre
cualquier extremo dependiendo de los casos de
uso involucrados. Algunos ejemplos de casos de
abuso son:
• Anulación de la inscripción y registro de
dispositivos
• Clonación y robo de dispositivos
• Simulación de movimientos físicos para evadir
Sensores y actuadores
• Abuso de protocolos, por ejemplo, ZigBee,
Z-wave, 6LoWPAN
Dependiendo de los casos de uso o de los flujos
funcionales percibidos para cada dispositivo y
aplicación, los casos de prueba de vulnerabilidad
deben diseñarse según corresponda. La metodología
de la prueba debe considerar todos los casos de
uso pertenecientes al IoT, y cada caso de uso debe
tener uno o más casos de uso indebido (caso de
prueba de seguridad) asociados con él. Siempre que
sea posible, los casos de pruebas de vulnerabilidad
y los scripts de prueba deben iniciarse a través de
Figura 4—Enfoque de pruebas de seguridad
Estudio de
dispositivos
y medio ambiente
Preparación de
evaluación
metodología
Configuración de
entorno de prueba
Integración con el ciclo de lanzamiento de la aplicación
Fuente: S. Subramanian and B. Swaminathan. Reimpreso con permiso.
38 ISACA JOURNAL VOL 3
la automatización, a medida que las aplicaciones se
desactiven mediante la funcionalidad y las pruebas
de rendimiento. Casos de uso más lógicos y de
negocios deben ser apuntados manualmente en
paralelo. El enfoque estándar para las pruebas de
seguridad se detalla en la figura 4.
El entorno de prueba debe ser lo suficientemente
escalable como para tener en cuenta la generación
de datos y la agregación que se alimentará y
consumirá por estas aplicaciones para imitar el
mundo real. El entorno en el que se desplegarán
las aplicaciones y los dispositivos se extenderá y
recibirá datos de muchos puntos finales.
Vale la pena señalar que las pruebas de seguridad
para un entorno de IoT no se detienen sólo con
las aplicaciones. El alcance es tan amplio como el
número de componentes implicados, por ejemplo,
sensores, actuadores, pórticos y la infraestructura
subyacente. Las principales áreas de interés deben
incluir:
• Dispositivos inteligentes—Desmontaje y revisión
de dispositivos, extracción de memoria, ataques a
buses y fuzzing a través de puertos físicos
• Firmware—Análisis estático y dinámico,
reversión, inyección de firmware malicioso y firma
• Comunicación—Análisis de tráfico,
decodificación y fuzzing de protocolos,
repeticiones de paquetes y ataques criptográficos
• Infraestructura (fase de despliegue)—Evaluación
de la vulnerabilidad, pruebas de penetración y
endurecimiento
Identificacion de Aplicación -
Hacks relevantes análisis de
casos de uso
Identificacion de Derivación de la
herramientas prueba Casos
(automatización
aplicables Y manual)
Ejecución
Informes
de pruebas
Fase de implementación
Mientras que la mayoría de las aplicaciones
fuera del dispositivo se adhieren a las directrices
comunes de endurecimiento del entorno y se
someten a pruebas de penetración, las aplicaciones
en dispositivos requieren consideraciones
especiales para una implementación segura.
Al principio de
las fases iniciales,
una solución
centralizada de
gestión y monitoreo
es imprescindible
para rastrear el
entorno IoT y sus
componentes.
Los fabricantes de dispositivos deben cumplir
con las directrices de seguridad establecidas
por los respectivos grupos de consorcios
industriales (por ejemplo, el Instituto de Ingenieros
Eléctricos y Electrónicos [IEEE] para la energía,
la Administración de Alimentos y Medicamentos
de los Estados Unidos [FDA] la Sociedad de
Ingenieros Automotrices [SAE] para dispositivos
de automoción, la Asociación de Electrónica de
Consumo [CEA] para dispositivos electrónicos
de consumo). Los dispositivos comunes que
prevalecen en las industrias son:
• Energía—Red inteligente, medidores inteligentes,
relés, controladores lógicos programables (PLCs)
• Dispositivos médicos—Marcapasos inteligentes,
desfibriladores
• Vehículos automotores—Inteligentes o sin
conductor
• Electrónica de consumo—Electrodomésticos
inteligentes
Así como las API y las aplicaciones se someten a
un SDLC seguro, los fabricantes deben asegurarse
de que estos dispositivos se someten a un ciclo
de vida de desarrollo seguro, desde el diseño del
circuito del dispositivo, el montaje y la configuración
hasta el lanzamiento a clientes.
Los puertos lógicos y físicos no deseados deben
estar desactivados en dichos dispositivos y
servidores, y los procedimientos de seguridad
física deben emplearse estrictamente para detectar
y prevenir ataques como robo de dispositivos/
sensores, manipulación indebida y acceso no
autorizado. Todos estos intentos deben ser
monitoreados, alertados, registrados y defendidos
de manera efectiva.
Para aprovechar los servicios basados en la
nube (especialmente en el caso de Software as
a Service), donde las aplicaciones se exponen
como servicios y API, los clientes deben trabajar
con los proveedores de servicios para obtener
los resultados de la evaluación y auditoría de las
aplicaciones y la infraestructura en la que se confía
para proporcionar garantías.
La evaluación de la vulnerabilidad y las pruebas
de penetración deben llevarse a cabo en todos
los componentes del entorno IoT, especialmente
los servidores que alojan las aplicaciones y las
API para identificar y mitigar las vulnerabilidades
relacionadas con el sistema operativo y la
plataforma que podrían dar lugar a un compromiso.
Las pruebas de penetración en el mundo real
también deben centrarse en servir el tráfico de
carga a los dispositivos y las aplicaciones.
Operaciones y estado estable
Al principio de las fases iniciales, es imprescindible
una solución centralizada de gestión y
monitorización para rastrear el entorno IoT y sus
componentes (aplicaciones, dispositivos, sensores).
La automatización de la vulnerabilidad, la gestión
de parches y de la configuración debe ejercerse.
Cada aplicación y cada nodo debe ser sometido a
un monitoreo continuo para ayudar en la detección
automatizada de amenazas y ataques y respuesta,
lo que aumentará la confianza adicional en la
seguridad. Además, se deben realizar evaluaciones
continuas de la vulnerabilidad, pruebas de
penetración y mantenimiento de la seguridad para
hacer frente a los ataques y amenazas cada vez
mayores y defendido como corresponde.
Caso de uso de negocio
Un sistema típico de estacionamiento de vehículos
consistente en dispositivos y aplicaciones
ascendentes se sometió a un aseguramiento de
ISACA JOURNAL VOL 3 39
 seguridad a través de SDLC seguro. La arquitectura
de alto nivel de IoT se representa en la figura 5.
Los sensores del dispositivo identifican la
disponibilidad de un lugar de estacionamiento
detectando el campo electromagnético creado
por la presencia o ausencia de un vehículo. Estos
dispositivos alimentan los datos de estacionamiento
a un pórtico local a través del bus de datos
conectado desde ellos y, a continuación, el pórtico
se comunica con la aplicación del cliente en la nube.
Desde la nube, los usuarios pueden extraer, consultar
y reservar el lugar de estacionamiento mediante
aplicaciones móviles. Las aplicaciones que fueron
sujetas a garantía de seguridad son:
1. Aplicaciones del dispositivo—D1, D2, D3, D4
2. Clientes pesados basado en Node.js—Gestión
de los sensores electromagnéticos conectados
a ellos
3. Aplicación de Gateway—Lógica de middleware
Java
4. Aplicación en la nube—Java/J2EE web y móvil
5. Aplicaciones móviles—Aplicaciones para
Android e iOS
Todas las aplicaciones antes mencionadas fueron
sometidas a un SDLC seguro, y las vulnerabilidades
identificadas en cada etapa del ciclo de vida se
abordaron antes de pasar a la siguiente fase. Las
Figura 5—Sistema de estacionamiento inteligente
Puerta de enlace
local
Fuente: S. Subramanian and B. Swaminathan. Reimpreso con permiso.
40 ISACA JOURNAL VOL 3
aplicaciones móviles también fueron diseñadas de
forma inversa para desmontarlas y depurarlas para
enumerar las vulnerabilidades relacionadas con la
seguridad del almacenamiento de datos, el control
de acceso y los secretos confidenciales.
Los servidores de puerta de enlace y de nube que
contenían los niveles de aplicación se sometieron a
pruebas de penetración de red y el endurecimiento
de la configuración se llevó a cabo en los servidores
de puerta de enlace y de nube que alojaban los
niveles de aplicación para identificar y prevenir
las vulnerabilidades en las plataformas y sistemas
operativos.
Además, también se realizó la prueba de penetración
física, por ejemplo, engañar a los sensores, clonar
o suplantar a los sensores, y manipular el hardware.
Los casos de abuso fueron diseñados sobre la base
de las reglas de negocio establecidas por el cliente y
ejecutadas según corresponda en la fase de pruebas.
Los siguientes son el número de defectos de seguridad
enumerados en las respectivas etapas SDLC:
• Diseño: 41
• Desarrollo: 26
• Prueba: 17
• Implementación: 11
Aplicación en
la nube
Y Dashboard
Wired
Wi-Fi, 3G, 4G
GSM
Los siguientes son datos típicos de los rangos de
costo por defecto12 (en dólares EEUU):
• Requermientos: $250
• Diseño: $500
•C
 odificación, prueba e implementación: $1,250
• Post-implementación: $5,000
Costo total incurrido en la fijación de defectos:
(41 defectos * $ 250) + ([26 defectos + 17 fallas + 11
fallas] * $ 1.250) = $ 77.750.

Si las aplicaciones no hubieran sido sometidas a

un SDLC seguro, todos los defectos se habrían
propagado a la compilación final y se habrían
acumulado en la producción:
•N
 úmero total de defectos: 41+26+17+11 = 95
•C
 osto total que habría sido incurrido para arreglos
postproducción: 95 defectos *$5,000 = $475,000
Se han alcanzado los ahorros totales de costos
la automatización. Sólo deben utilizarse marcos,
$475,000 – $77,750 = $397,250
estándares y API autorizados, y se debe ejercer
el debido cuidado en los componentes de código
En otras palabras, el costo que se habría incurrido
abierto. Para contrarrestar las vulnerabilidades y
para corregir los defectos después de la producción
amenazas más recientes, las evaluaciones continuas,
sería aproximadamente cinco veces el costo de la
el seguimiento de amenazas y el parche de seguridad
corrección de los defectos en las fases individuales
deben realizarse una vez que los dispositivos IoT,
del SDLC. Obsérvese que las cantidades anteriores
las aplicaciones y las API estén expuestos a la
son un indicador aproximado de los costos
producción. Tener seguridad incorporada en el ciclo
involucrados y no de las cifras reales.
de desarrollo de IoT garantiza que los problemas
de seguridad conocidos son corregidos y los
Conclusión
nuevos se evitan con las medidas más eficaces,
El aseguramiento de la seguridad de las aplicaciones proporcionando así seguridad garantizada para los
IoT y las API debe integrarse en todas las etapas del usuarios finales.
SDLC y debe ser continuo. Es crítico mantener un
inventario y una configuración apropiados de todos Notas Finales
los componentes de la aplicación que construyen
1 Dark Reading, “IoT Village at DEF CON
el ambiente IoT. La supervisión o verificación de
24 Uncovers Extensive Security Flaws in
la seguridad debe formar parte de la etapa de
Connected Devices,” press release,
requisitos. Las medidas proactivas tales como las
16 September 2016, www.darkreading.com/
sesiones de capacitación y el uso de estándares de
attacks-breaches/iot-village-at-def-con-
seguridad, pautas y listas de verificación tienen que
24-uncovers-extensive-security-flaws-in-
ser obligatorias en todas las etapas aplicables, y las
connected-devices/d/d-id/1326928
medidas de validación se logran realizando revisiones
2 Jones, C.; Software Quality Metrics: Three
y evaluaciones en todas las etapas.
Harmful Metrics and Two Helpful Metrics,
Project Performance International, 6 June
Las herramientas de evaluación de la seguridad
2012, www.ppi-int.com/systems-engineering/
deben integrarse en los ciclos de desarrollo y
free%20resources/Software%20Quality%20
garantía de la calidad para activar las evaluaciones
Metrics%20Capers%20Jones%20120607.pdf
sobre la marcha y, siempre que sea posible, emplear

ISACA JOURNAL VOL 3 41

 3 Open Web Application Security Project, Top 10
2013-Top 10, https://www.owasp.org/index.
php/Top_10_2013-Top_10
4 Open Web Application Security Project,
The OWASP Code Review Top 9,
https://www.owasp.org/index.php/The_Owasp_
Code_Review_Top_9
5 Martin, B.; M. Brown; A. Paller; D. Kirby; 2011
CWE/SANS Top 25 Most Dangerous Software
Errors, The MITRE Corporation, 13 September
2011, http://cwe.mitre.org/top25/
6 Confluence, SEI CERT Coding Standards,
Software Engineering Institute at Carnegie
Mellon University, Pittsburgh, Pennsylvania,
USA, https://www.securecoding.cert.
org/confluence/display/seccode/
SEI+CERT+Coding+Standards
7  Op cit, OWASP Top 10 2013-Top 10
8 Open Web Application Security Project,
OWASP Internet of Things Project,
https://www.owasp.org/index.php/OWASP_
Internet_of_Things_Project#
tab=IoT_Vulnerabilities
9 Open Web Application Security Project, Mobile
Top 10 2016-Top 10, https://www.owasp.org/
index.php/Mobile_Top_10_2016-Top_10
10 Web Application Security Consortium, “The
WASC Threat Classification v2.0,” Threat
Classification Wiki, http://projects.webappsec.
org/w/page/13246978/Threat%20Classification
11  Op cit, Martin
12 Op cit, Jones

REGISTRATION
IS OPEN!
11 – 12 SEPTEMBER | ACCRA, GHANA
The Africa CACS Conference is the premier
conference for Audit/Assurance, Compliance, Risk,
Security and Strategy/Governance professionals.
This year’s programme will include sessions on:
• IS Audit & Assurance
• Security & Cybersecurity
• Governance, Risk & Controls
• Compliance/Privacy
Embrace new knowledge and inspiration you can
apply immediately to any role in information systems,
or IT roles in business and government.
Join us at Africa CACS 2017 and earn up to 14
Continuing Professional Education (CPE) credits—for
a conference total of 29 CPEs—by attending either of
our invaluable Cybersecurity Fundamentals or COBIT® 5
Foundation two-day, pre-conference workshops.
www.isaca.org/africacacs-jv3

42 ISACA JOURNAL VOL 3

 artículo
artículo

Protección de aplicaciones móviles

con un enfoque de ciclo de vida seguro
para el desarrollo
En la era actual es común traer su propio dispositivo
(BYOD), el teléfono inteligente es uno de los
dispositivos móviles preferidos para acceder a
la información de la empresa. El software es un
componente clave en cualquier activo de tecnología
de la información. Los dispositivos inteligentes están
incorporados con software de aplicación o permiten a
los usuarios instalar software en los dispositivos para
agregar funciones que logren los objetivos previstos.
Por lo tanto, las aplicaciones son vitales para los
dispositivos móviles. Asegurar estas aplicaciones
de las vulnerabilidades de seguridad y el riesgo es
fundamental1.
Este artículo se centra en las prácticas de desarrollo
seguras en el desarrollo de aplicaciones móviles
y sugiere algunas herramientas de seguridad de
código abierto para realizar una evaluación de la
seguridad de las aplicaciones para fortalecer las
aplicaciones móviles.
Los problemas de seguridad de
las aplicaciones web conducen a
infracciones a las empresas
web expuestas en Internet, las aplicaciones móviles
instaladas en dispositivos BYOD son puntos de ¿Tienes algo que
entrada a la red empresarial. comentar sobre
este artículo?
Las aplicaciones móviles instaladas, si no están Visita las páginas del
protegidas adecuadamente, pueden ser ingeniería Journal en el sitio web
de ISACA® website
inversa para obtener su código fuente, que está
(www.isaca.org/
en forma legible por humanos. Plataformas como
journal), encuentra el
iOS y Android, las dos plataformas móviles más
artículo y hace click
populares hoy en día, no son inmunes a la amenaza
en el link Comments
de la ingeniería inversa. Algunos pasos sencillos y para compartir tus
herramientas ampliamente disponibles (a menudo pensamientos.
gratuitas) hacen que sea fácil para un atacante:
• Extraer la aplicación instalada del dispositivo móvil
• Analizar o realizar ingeniería inversa del código
para encontrar información vital, por ejemplo,
lógica empresarial, interfaz de programación
de aplicaciones (API) utilizada e URL internas
incorporadas
• Modificar el código para cambiar el
comportamiento de la aplicación
• Inyectar código malicioso

En los últimos años se han producido violaciones

importantes de la seguridad de la información.
Los investigadores de seguridad examinaron de
cerca las razones subyacentes de algunas de estas
infracciones y sus estudios revelan que la seguridad
de una aplicación web es de suma importancia
para el perímetro de la empresa y la seguridad a
nivel de puerta de enlace2, 3, 4, 5, 6, 7, 8.

Una aplicación web insegura puede comprometer

los mejores arreglos de seguridad de la empresa
y puede ayudar a los adversarios a robar datos y
obtener un punto de apoyo en la red interna de la
empresa.

Problemas de seguridad de
aplicaciones móviles
Sakthivel Rajendran, CISA, CRISC, CISM, CEH, GMOB
Los problemas de seguridad no son diferentes Es un gestor de seguridad de la información en la India y trabaja con una
en el caso de aplicaciones móviles, en las que la importante empresa global de atención médica. Tiene más de una década
de experiencia en seguridad de TI. Su área de enfoque es la seguridad de las
aplicación se descarga desde Internet (por ejemplo,
tecnologías emergentes. Puede ser contactado en sakthiindian@gmail.com.
Apple Store o Google Play Store) e instalada en el
dispositivo del usuario. Al igual que las aplicaciones

ISACA JOURNAL VOL 3 43

 La ingeniería inversa de aplicaciones móviles es un
problema de seguridad que las empresas deben
tener en cuenta. La ofuscación del código es una
técnica bien conocida que dificulta la ingeniería
inversa de una aplicación móvil9, pero esta técnica
es a menudo ignorada por la comunidad de
desarrollo. Las aplicaciones móviles presentan las
siguientes debilidades de seguridad10:
• Falta de consideraciones de privacidad
• Falta de protección binaria
• Almacenamiento de datos inseguro
• Seguridad del transporte
• Controles del lado del servidor débiles
La corrección de las
vulnerabilidades de seguridad en las
etapas posteriores del ciclo de vida
de desarrollo de software (SDLC)
requiere mucho tiempo y es muy
costosa.
La investigación realizada por dos expertos en
seguridad que representan a diferentes empresas
de seguridad revela que las aplicaciones de banca
móvil de los bancos más influyentes de todo el
mundo tienen muchas vulnerabilidades de seguridad
comunes11, 12. Estos investigadores realizaron sus
pruebas en la aplicación móvil (cliente) y excluyeron
cualquier prueba del servidor (back end). El lado del
cliente representa sólo una pequeña porción de la
superficie de ataque de la banca móvil, porque la
mayoría de procesamiento ocurre en el back-end.
Los problemas de seguridad que los investigadores
revelaron no son lógica de negocios o problemas
específicos de la aplicación. Los problemas son
debilidades en el desarrollo de aplicaciones, es decir,
las tareas de seguridad que los desarrolladores
deben realizar, pero no lo están haciendo.
Las aplicaciones móviles que fueron probadas
durante la investigación estaban filtrando
información a través de codificación insegura. Por
ejemplo, estas aplicaciones eran vulnerables a:
• Ataque de Hombre en el Medio (MitM)
44 ISACA JOURNAL VOL 3
• Ataques de secuencias de comandos entre sitios
(XSS)
• Fuga de información confidencial a través de los
registros del sistema
• Credenciales codificadas en el código
• El uso de protocolo de capa de socket no
seguro (SSL) (HTTP) para transmitir información
confidencial entre el servidor remoto y el
dispositivo de usuario
Las recomendaciones de los investigadores para
mejorar la seguridad de las aplicaciones móviles
incluyen13:
• Asegúrese de que todas las conexiones entre las
aplicaciones móviles y los servidores back-end
se realizan mediante SSL. La verificación del
certificado SSL es reforzada por la aplicación
cliente para protegerse contra la intercepción y
MitM.
• Proteger los datos sensibles que se almacenan en
el dispositivo (cliente) con cifrado.
• Utilizar trucos de obfuscación de código y anti-
depuración para disuadir a los atacantes de la
ingeniería inversa del binario de la aplicación.
• Habilitar las protecciones proporcionadas por la
plataforma operativa móvil, tales como:
–Recuento automático de referencia (ARC)
– Ejecutable independiente de la posición (PIE)
– Protección de la pila en la plataforma iOS
– Utilizar el kit de desarrollo de software más
reciente (SDK)
– Deshabilitar la función de depuración en el
binario compilado
– El endurecimiento de permisos para
aplicaciones basadas en Android
Construyendo seguridad en el
desarrollo
Realizar evaluaciones de seguridad de las
aplicaciones e incorporar la seguridad en la
aplicación justo antes de la publicación del
software no es un enfoque ideal. La corrección de
las vulnerabilidades de seguridad en las etapas
posteriores del ciclo de vida de desarrollo de software
(SDLC) requiere mucho tiempo y es muy costosa.
El ciclo de vida de desarrollo seguro tiene como
objetivo incorporar la seguridad en todas las fases
del desarrollo de software, desde la recolección
de requisitos hasta la prueba, la liberación y el
mantenimiento (figura 1)14, 15.
 Figura 1—Incorporación de seguridad en el desarrollo de aplicaciones móviles
Seguridad en el Desarrollo
Determinar el nivel de riesgo
de la aplicación
Incorporar requisitos de seguridad
Minimizar las fallas de seguridad
Modelo de amenaza
Análisis de la revisión de la arquitectura
Análisis estático
Garantía de seguridad
Análisis dinámico
Monitoreo de seguridad
Vigilancia de la vulnerabilidadng
Fuente: S. Rajendran. Reimpreso con permiso.
Las siguientes secciones tienen como objetivo
proporcionar orientación al personal de desarrollo
y seguridad de aplicaciones para incorporar
actividades específicas de seguridad de la
información en cada fase del SDLC.
Recolección de requisitos
La incorporación de seguridad en el desarrollo de
aplicaciones comienza en la fase de recopilación de
requisitos. Aparte de los requisitos funcionales del
software, determine:
1. Requisitos de seguridad específicos del usuario
esperados en la aplicación. Esto puede incluir
confidencialidad, integridad, disponibilidad y
autenticación.
2. Importancia de los datos manejados por la
aplicación y requisitos de seguridad para proteger
los datos
3. Cumplimiento y mandatos reglamentarios
aplicables a los usuarios, la región donde se
utilizará la aplicación y la información manejada
por la aplicación
4. Uso y mal uso de los casos desde una perspectiva
de seguridad
5. Matriz de trazabilidad de requerimientos para
mapear requerimientos con riesgo de seguridad
Diseño
En la fase de diseño de la aplicación, los requisitos
funcionales se convierten en arquitectura. Es
importante incorporar controles de seguridad para la
Requisito
Reunión
Diseño
Y Codificación
Prueba y
Lanzamiento
Mantenimiento
seguridad de las aplicaciones en la fase de diseño.
La construcción de un diseño seguro minimiza la
mayoría de los problemas de seguridad, ya que los
problemas de nivel de código pueden identificarse
con análisis estáticos o revisión manual del código.
Además, las herramientas automatizadas no pueden
identificar inconsistencias de diseño a menos que
se realicen esfuerzos para realizar una revisión de
modelo y arquitectura de amenazas16. La estricta
observancia de los principios de diseño seguro
mejora en gran medida la seguridad.
Reconociendo la importancia del diseño en la
seguridad de las aplicaciones, el Instituto de
Ingenieros Eléctricos y Electrónicos (IEEE) lanzó la
iniciativa del Centro para el Diseño Seguro (CSD).
CSD identificó las 10 principales fallas de diseño y las
maneras de evitarlas17. La recomendación de la CSD
puede proporcionar valiosa guía para considerar en el
diseño de una aplicación.
Realizar el modelado de amenazas y el análisis de
riesgo de la arquitectura del diseño da una medida
de lo probable es que el software será atacado y la
extensión del daño que un ataque podría causar.
Iniciar el análisis mediante la elaboración de una
visión general de alto nivel del sistema propuesto;
luego, analizar el diseño desde la perspectiva de un
atacante, es decir, encontrar maneras de explotar la
aplicación.
Codificación
Durante la fase de codificación, los requisitos de
empresa/cliente/producto se convierten en una
aplicación. La entrada para esta fase proviene
ISACA JOURNAL VOL 3 45
 de las fases anteriores en SDLC (recopilación de
requisitos y diseño). Los desarrolladores convierten
¿Te gusto este
los documentos de diseño en software funcional. La
artículo? escritura incorrecta de un código produce errores
de software. Los errores de codificación pueden
• Aprenda más reducirse considerablemente cuando se aplican
acerca, discute directrices de codificación segura en el desarrollo
y colabora sobre de aplicaciones.
computación móvil
en el Centro de Las directrices de codificación pueden ser
Conocimiento cualquiera de las siguientes:
www.isaca.org/
• Generic, que se aplican en todos los entornos de
mobile-computing
desarrollo independientemente de la plataforma
elegida para construir una aplicación. El proyecto
de seguridad móvil de la aplicación web abierta
(OWASP)18 y las directrices para aplicaciones
móviles seguras de la Agencia de la Unión
Europea para la seguridad de las redes y la
información (ENISA) son pautas genéricas19.
• Directrices de codificación específicas de la
plataforma relacionadas con una plataforma de
desarrollo, por ejemplo, Android20 o iOS21
La construcción
de un diseño seguro
minimiza la mayoría
de los problemas
de seguridad, ya
que los problemas
a nivel de código se
pueden identificar
con análisis estáticos
o revisión manual del
código.
Uso de código de terceros
Otra consideración importante durante la
codificación es el uso de marcos de desarrollo y
bibliotecas de terceros, incluyendo componentes
de fuente abierta. Hoy en día, muchas aplicaciones
se forman a partir de múltiples conjuntos de
bibliotecas, la mayoría de las cuales son de
código abierto, permitiendo al desarrollador
centrarse en la aplicación principal Funciona al
46 ISACA JOURNAL VOL 3
tiempo que confía en código de terceros para
proporcionar capacidades de soporte. Aunque esto
es beneficioso para desarrollar la funcionalidad
rápidamente, algunas infracciones de seguridad
han ocurrido debido a las vulnerabilidades
encontradas en las bibliotecas. Los ejemplos
incluyen el defecto de OpenSSL que condujo a la
vulnerabilidad de Heartbleed22.
Se recomienda crear un inventario de opensource
y bibliotecas de terceros que se utilizan en la
aplicación que se está desarrollando y mantener
el inventario como parte de los artefactos de
desarrollo. Debido a que el código abierto proviene
de múltiples partes y se introduce en el código
de la aplicación por desarrolladores de socios
internos y/o tercerizados, es esencial que el
inventario rastree el componente de código abierto
en el código y determine si estos componentes
se ven afectados por vulnerabilidades conocidas.
Una ventaja del inventario de código abierto es
que cuando ocurre algún incidente de seguridad
que involucre a estas bibliotecas, la remediación
puede ser muy rápida, especialmente cuando la
empresa tiene varias aplicaciones en su cartera.
La falta de información sobre los componentes de
código abierto que se utilizan en las aplicaciones
puede dificultar la iniciación de actividades de
remediación23.
Otra ventaja del inventario de código abierto es el
monitoreo proactivo de las vulnerabilidades en los
componentes de código abierto al referirse a la
hoja de inventario (figura 2) y tomar las medidas
correctivas apropiadas cuando algo indeseable es
inminente.La hemorragia conduce a una situación
de crisis para aquellos que utilizan OpenSSL
cryptolibraries en su Las aplicaciones móviles, y la
actualización a la versión actual era un desafío24, 25.
En circunstancias como esta, tener una hoja de
inventario es útil. El personal responsable del
soporte y mantenimiento conoce los detalles de las
aplicaciones y puede usar la hoja de inventario para
encontrar dónde está el componente vulnerable y
luego planificar la remediación.
También vale la pena examinar las bibliotecas
de código abierto y de terceros. El objetivo de
examinarlas es minimizar vulnerabilidades, por
ejemplo, puertas traseras incrustadas en ellas u
otros problemas de seguridad. La seguridad del
código de código abierto de terceros se puede
abordar de dos maneras: incrustando controles
administrativos e incorporando controles técnicos a
través del SDLC.
 Figura 2—Modelo de plantilla de inventario para código de terceros y de código abierto
Validación de
código de terceros
para la existencia
de vulnerabilidades
(indique la
La versión más referencia a la
Módulo funcional reciente del información de
dentro de la componente verificación o el
aplicación donde Desde donde el y la fecha de seguimiento de
se utiliza la Nombre de Versión de código Proveedor/ componente de lanzamiento defectos, si se
biblioteca de biblioteca de de terceros y nivel proveedor de código de terceros (actualizaciones de trata de artículos
terceros terceros de revisión en uso código de terceros se obtuvo seguridad) abiertos)

Fuente: S. Rajendran. Reimpreso con permiso.

El primer enfoque consiste en controles de que el posible riesgo de seguridad se identifica y

administrativos, tales como políticas y administra adecuadamente.
procedimientos. Este enfoque puede incluir:
Herramientas gratuitas, como Androwarn26,
• Capacitación de concientización del desarrollador
LinkedIn Quick Android Kit de Revisión (QARK)27,
para educar cómo los desarrolladores heredan
FindBugs28 y Facebook Infer29 pueden utilizarse
inadvertidamente el riesgo de seguridad de los
para analizar el código.
componentes de código abierto a su aplicación
cuando el código de terceros no está validado
Pruebas de seguridad de aplicaciones estáticas
• Auditoría de cualquier software de código abierto Ejecutar análisis estáticos en el código fuente
en uso, especialmente en aplicaciones de alta temprano en el ciclo de vida ayuda a corregir errores
prioridad de nivel de código antes de que la aplicación se
libera para uso general. El análisis estático encuentra
• Creación y mantenimiento de una lista de códigos
la codificación incorrecta que puede potencialmente
de código abierto aprobados/listados en blanco
causar riesgo de seguridad. El análisis se realiza
y uso restringido de software no aprobado. Sin
sin ejecutar realmente el programa. En este tipo de
embargo, la lista blanca puede no ser útil
análisis se cubre todo el código fuente o binario.
cuando el volumen de aplicaciones que libera
Se puede construir en el proceso de desarrollo y se
una empresa es alto y cuando hay una mayor
realiza temprano en el ciclo de vida de desarrollo de
necesidad de utilizar código de terceros. En tales
software.
situaciones, la combinación de un enfoque de
lista blanca con los controles técnicos puede
Los desarrolladores pueden estar facultados para
ayudar a lograr un equilibrio fino.
realizar análisis estáticos de su código y corregir
la codificación incorrecta con regularidad. La
El segundo enfoque consiste en controles técnicos
integración del análisis estático con servidores de
y realizar análisis de código fuente y análisis de
integración continua, por ejemplo, Jenkins, minimiza
tiempo de ejecución en el código de terceros
la necesidad de intervención manual, reduce la
mediante herramientas automatizadas. Todos los
dependencia del equipo de seguridad y soluciona
códigos de terceros que se utilizan en la aplicación
errores que pueden convertirse en vulnerabilidades
deben someterse a estos análisis para asegurarse
de seguridad antes de que se vuelvan inmanejables.

ISACA JOURNAL VOL 3 47

 Las herramientas de seguridad, como Androwarn,
QARK, FindBugs e Infer, se pueden utilizar para este
análisis también.
Entrenamiento para desarrolladores
Una organización de TI que se esfuerza por ofrecer
aplicaciones seguras (incluido el móvil) debe
comprometer a sus desarrolladores y capacitarlos
en prácticas seguras de codificación. El enfoque
debe incluir la entrega de una aplicación sin riesgos
de seguridad aparte de las funcionalidades y
características.
En la fase de pruebas, es
importante realizar pruebas de
seguridad junto con pruebas
de garantía de calidad (QA)
para integrar continuamente la
seguridad en el desarrollo.
Por ejemplo, Damn Vulnerable iOS App (DVIA)30,
como su nombre indica, es una aplicación móvil
vulnerable. El principal objetivo de la aplicación
es enseñar a los desarrolladores y entusiastas de
la seguridad acerca de las vulnerabilidades en las
aplicaciones móviles iOS, basadas en los “Top 10
Mobile Risks”31 de OWASP. De forma similar, OWASP
GoatDroid proporciona un entorno de capacitación
para desarrolladores y probadores de Android.
Pruebas
En la fase de pruebas, es importante realizar
pruebas de seguridad junto con pruebas de garantía
de calidad (QA) para integrar continuamente la
seguridad en el desarrollo. QA asegura la calidad de
la aplicación para ofrecer la funcionalidad empresarial
necesaria. Las pruebas de seguridad ofrecen la
seguridad de que la aplicación procesa de forma
segura la información comercial.
El análisis dinámico de seguridad de aplicaciones
(DAST) o el análisis en tiempo de ejecución es
apropiado en esta fase del SDLC. El análisis dinámico
se realiza contra una instancia en ejecución de un
programa. Esta prueba mide con mayor precisión
cómo un usuario malintencionado puede atacar la
aplicación.
48 ISACA JOURNAL VOL 3
Al igual que las pruebas de seguridad de aplicaciones
web tradicionales, la evaluación de aplicaciones
móviles requiere un entorno de pruebas para llevar a
cabo la evaluación de manera efectiva. Sin embargo,
el entorno de pruebas de seguridad para móviles
varía porque la evaluación implica revisar varios
componentes, incluyendo cómo se comporta la
aplicación cuando se instala en el dispositivo móvil.
Configuración de un laboratorio de pruebas
móviles
Un laboratorio de pruebas móvil requiere los
siguientes elementos esenciales:
• Una conexión de red. Este entorno debe estar
aislado de la red corporativa o de producción.La
creación de un hotspot Wi-Fi mediante una tarjeta
de datos 3G/4G es una opción. Es importante
recordar que tanto el portátil de análisis como el
dispositivo en el que está instalada la aplicación
móvil deben conectarse a la misma red para
algunas de las pruebas.
• Un ordenador portátil Mac o Windows cargado
con software de seguridad opensource
• Un dispositivo jailbreak32 para las pruebas de
seguridad de aplicaciones iOS (iPhone, iPod o iPad)
• Para dispositivos Android, un SDK de Android
y un entorno de desarrollo integrado (IDE) de
Eclipse para configurar un emulador33
Casos mínimos de prueba de la seguridad base
Cuatro componentes principales del entorno de
aplicación móvil deben ser cubiertos en el análisis
dinámico:
• Dispositivo donde está instalada la aplicación móvil
• Solicitud
• Comunicación de red entre la aplicación y el
servidor de la empresa
• Datos manejados en la aplicación
Al establecer la capacidad de pruebas de seguridad
de aplicaciones móviles, es posible que no sea
posible concentrarse en todo. El mejor enfoque es
comenzar pequeño e iterar continuamente para
madurar la capacidad, incorporando las lecciones
aprendidas en el proceso a lo largo del camino.
Los “Top 10 Mobile Risks” de OWASP pueden
ser un buen punto de partida para la construcción
de los casos de prueba de seguridad móvil. Los
profesionales de seguridad que participan en la
seguridad de las aplicaciones voluntariamente
contribuyen a OWASP, que representa de manera
justa los principales problemas de seguridad con las
aplicaciones móviles.
“En la fase de pruebas, es importante realizar
pruebas de seguridad junto con pruebas de control
de calidad (QA) para integrar continuamente la
seguridad en el desarrollo”.
De forma alternativa, los casos de prueba de
seguridad de aplicaciones móviles pueden crearse
basándose en los cinco problemas de seguridad
destacados en el informe “Estudio de seguridad de
aplicaciones móviles” de Hewlett-Packard34. Los
problemas de seguridad identificados en el estudio
son una versión abreviada del Top 10 de OWASP,
debido a que los resultados de los estudios se
correlacionan con las principales cuestiones de
OWASP.
Los resultados previos de las evaluaciones de
seguridad de las aplicaciones desarrolladas/utilizadas
en la empresa son otros recursos valiosos a consultar
cuando se construyen los casos de prueba. Los
intentos de establecer una línea de base mínima de
casos de prueba de seguridad pueden resultar en
la identificación de objetivos de seguridad de alto
nivel. Estos objetivos son únicos y relevantes para
la seguridad de las aplicaciones móviles, como se
muestra en la figura 3.
El siguiente paso es dividir los objetivos de seguridad
en casos de prueba de seguridad. Mapear los
casos de prueba de seguridad con herramientas
de evaluación de seguridad es otra subactividad
en este esfuerzo. Las herramientas de seguridad
comercial para la evaluación de aplicaciones móviles
pueden no cubrir todos los escenarios de prueba.
La realización de pruebas manuales con algunas
de las herramientas de código abierto libremente
disponibles puede proporcionar una cobertura
razonable para identificar el riesgo de seguridad.
Las Figuras 4 y 5 desglosan los objetivos de las
pruebas de seguridad en casos de prueba y los
asignan a herramientas de evaluación de seguridad
para iOS y plataformas móviles Android.
Mantenimiento
La seguridad de las aplicaciones es una tarea
continua; sigue siendo importante incluso cuando la
aplicación se libera para uso público. El monitoreo
proactivo de las vulnerabilidades de seguridad
en el software del sistema de la plataforma y
los componentes integrados, y luego iniciar la
respuesta a incidentes y la remediación, según sea
apropiado, son cruciales.
Identificar vulnerabilidades de seguridad utilizando
fuentes acreditadas para obtener información de
seguridad es un ciclo continuo. Fuentes como

Figura 3—Objetivos de seguridad relevantes para la seguridad de aplicaciones móviles

Objetivo Seguridad
Almacenamiento de datos
inseguro
Manipulación en tiempo de
ejecución
Análisis del sistema de archivos
Análisis del tráfico de red
Criptografía insegura o rota
Divulgación de información
Improper session handling
Protección binaria
Violaciones de privacidad
Autenticación
Fuente: S. Rajendran. Reimpreso con permiso.
Cobertura Propósito
Dispositivo Para encontrar el almacenamiento de credenciales en archivos de
lista de propiedades o base de datos SQLite
Aplicación Para determinar si la aplicación es susceptible de modificación de
entrada para ser interpretada como una instrucción de código
Aplicación Para analizar si los datos de aplicación sensibles se almacenan de
forma insegura en el dispositivo
Red Para determinar si la aplicación confía en cualquier certificado SSL
presentado mientras se conecta con la infraestructura de TI de la
empresa, resultando en ataques MitM
Aplicación Para averiguar si un algoritmo de cifrado débil o defectuoso se utiliza
para proteger la información
Aplicación Para buscar fugas de información a través del registro, enviar datos
analíticos a proveedores externos
Aplicación Para averiguar si el tiempo de espera de sesión se establece en la
aplicación
Datos Para determinar si el binario de la aplicación móvil está protegido
contra el riesgo de ingeniería inversa
Datos Para averiguar si la aplicación utiliza más permiso de lo necesario
para recopilar y transmitir datos personales del usuario en otros
lugares
Aplicación de Para determinar si la autenticaciòn es efectuada en el lado del
redes servidor en vez del lado del cliente (dispositivo)

ISACA JOURNAL VOL 3 49

 Figura 4—Casos de prueba de seguridad de iOS
ID Nombre de la prueba Herramientas de seguridad
a utilizar
IOS-01 Almacenamiento de credenciales en el archivo de lista de propiedades PuTTY, WinSCP, iExplorer, Plist
IOS-02 Almacenamiento de credenciales en el archivo SQLite Editor
IOS-03 Error al utilizar el llavero para almacenar credenciales
IOS-04 Almacenamiento de datos de aplicaciones sensibles en el sistema de archivos
IOS-05 Cliente que confía en cualquier certificado SSL presentado-caducado o no válido Burp Proxy, Fiddler
IOS-06 La aplicación permite el ataque trivial de MitM
IOS-07 Conéctese a HTTPS una vez y retroceda
IOS-08 Registro de aplicaciones de datos de aplicaciones sensibles iPhone Configuration Utility
IOS-09 La aplicación almacena su imagen en una carpeta pública en lugar de sandbox de la PuTTY, WinSCP, iExplorer
aplicación (aplicación de fondo)
IOS-10 Datos analíticos enviados a terceros Burp Proxy, Fiddler
IOS-11 Las solicitudes de autenticación se realizan en el lado del servidor
IOS-12 La autenticación persistente, si se implementa, no almacena la contraseña de WinSCP, Python,
usuario en el dispositivo BinaryCookieReader.py
IOS-13 Código duro de criptokeys en cualquier constructo (texto sin formato, archivos de IDA, Clutch, Class-dump-z
propiedades, binarios compilados)
IOS-14 Uso de algoritmos inseguros y/o obsoletos
IOS-15 Uso de protocolos de cifrado personalizados
IOS-16 Invalidar sesiones en el extremo posterior Burp Proxy, Introspy
IOS-17 Restablecer las cookies durante los cambios de estado de autenticación
IOS-18 Protección de tiempo de espera adecuada en los componentes de back-end
IOS-19 Ofuscación de código IDA, Clutch, Class-dump-z
IOS-20 Eliminar declaraciones de depuración e información de desarrollo iRET
IOS-21 Implementación de la asignación aleatoria de la disposición del espacio de la iRET
dirección (ASLR) PIE y conteo automático de la referencia
IOS-22 Violaciones de privacidad: acceso a la ubicación, contactos, libreta de direcciones, Snoop-it, iRET
fotos
IOS-23 Acceso a datos privados Snoop-it, iRET
IOS-24 Análisis en tiempo de ejecución GDB, IDA, Hopper, ClutchMod
Fuente: S. Rajendran. Reimpreso con permiso.

sitios web de proveedores de software, la National El inventario de todos los frameworks/API de

Vulnerability Database (NVD) del EEUU National
Institute of Standards and Technology (NIST) y las
vulnerabilidades y exposiciones comunes de MITRE
Corporation (CVE) son fiables para la investigación
de vulnerabilidad.
terceros que se utilizan en la aplicación móvil
es útil para gestionar parches de seguridad.
Siempre que cualquier vulnerabilidad se convierta
en conocimiento público, debe realizarse una
actualización de seguridad correspondiente para
las aplicaciones móviles que utilizan estas API/
frameworks de terceros vulnerables.

Conclusión
La seguridad de las aplicaciones Las aplicaciones móviles y web que tratan con
información sensible, privada u otra en riesgo
es una tarea continua; sigue requieren un ciclo de vida de desarrollo seguro.
siendo importante incluso cuando Las aplicaciones sin consideraciones de seguridad
pueden presentar una vulnerabilidad inesperada
la aplicación se libera para uso a la privacidad. Para tratar los problemas de
seguridad de las aplicaciones, se anima a los
público. desarrolladores a comprender el riesgo potencial
de cada función de negocio, cambio de código
y uso de marcos y API de terceros, mientras

50 ISACA JOURNAL VOL 3

 Figura 5—Casos de prueba de seguridad de Android
ID Nombre de la prueba Herramientas de seguridad
a utilizar
AN-01 Almacenamiento de credenciales en el dispositivo AXMLPRINTER,
AN-02 Almacenamiento de credenciales en el archivo SQLite SQliteSpy,
AN-03 Error al utilizar keystore para almacenar credenciales Cookies Manager+
AN-04 Almacenamiento de datos de aplicaciones sensibles en el sistema de archivos
AN-05 Cliente que confía en cualquier certificado SSL presentado-caducado o no válido Burp Proxy, Fiddler
AN-06 La aplicación permite el ataque trivial de MitM
AN-07 Conéctese a HTTPS una vez y retroceda
AN-08 La aplicación registra datos de aplicaciones sensibles Burp Proxy
AN-09 Datos analíticos enviados a terceros Burp Proxy, Fiddler,
AN-10 Las solicitudes de autenticación se realizan en el lado del servidor secure code review
AN-11 La autenticación persistente, si se implementa, no almacena la contraseña de Manually review
usuario en el dispositivo
AN-12 Hardcode de criptokeys en cualquier constructo (texto sin formato, archivos de Dex2Jar, JD-GUI,
propiedades, binarios compilados) FindBugs, Androwarn
AN-13 Uso de algoritmos inseguros y/o obsoletos
AN-14 Hardcode de criptokeys en cualquier constructo (texto sin formato, archivos de
propiedades, binarios compilados)
AN-15 Uso de algoritmos inseguros y/o obsoletos Burp Proxy, Introspy
AN-16 Restablecer las cookies durante los cambios de estado de autenticación
AN-17 Protección de tiempo de espera adecuada en los componentes de back-end
AN-18 Ofuscación de código Dex2Jar, JD-GUI,
Proguard
AN-19 Eliminar declaraciones de depuración e información de desarrollo Dex2Jar, JD-GUI,
AN-20 Violaciones de privacidad: acceso a la ubicación, contactos, libreta de DroidBox, Drozer
direcciones, fotos
AN-21 Acceso a datos privados
AN-22 Análisis en tiempo de ejecución Drozer
Fuente: S. Rajendran. Reimpreso con permiso.

que los equipos de seguridad pueden ayudar a
mejorar la seguridad de las aplicaciones a través
del entrenamiento, compromiso proactivo con
los desarrolladores. Incorporar la seguridad en
todas las fases de SDLC en lugar de incorporar la
seguridad justo antes de la liberación del software
no sólo beneficia a la organización desde una
perspectiva económica y de eficiencia, sino que
también asegura que los servicios empresariales
estén habilitados de forma segura.
Nota del Autor
Las opiniones expresadas en este artículo son del
autor y de ninguna manera representan la postura
de su empleador.
Notas Finales
1 2014 Research Into Internet Systems LLC,
“Top 10 Mobile Security Risks,” Decompiling
Android, 2014, www.decompilingandroid.com/
mobile-app-security/top-10-mobile-security-
risks/?_sm_au_=iHVjTnqfJSv0F6Nj
2 Tung, L.; “Hackers Access 800,000 Orange
Customers’ Data,” ZDNet, 3 February 2014,
www.zdnet.com/article/hackers-access-
800000-orange-customers-data/
3 TrustedSec, “CHS Hacked via Heartbleed
Vulnerability,” TrustedSec Update,
19 August 2014, www.trustedsec.com/
august-2014/chs-hacked-heartbleed-
exclusive-trustedsec/
4 Mumsnet Limited, “The Heartbleed Security
Breed—And What To Do,” mumsnet,
www.mumsnet.com/info/the-heartbleed-
security-breach-to-do
5 Paganini, P.; “Vulnerabilities in Alibaba
Threatens Security of Million Users,”
Security Affairs, 11 December 2014, http://
securityaffairs.co/wordpress/31028/hacking/
vulnerabilities-in-alibaba.html
6 Mai-Duc, C.; “Alibaba Security Flaws Exposed
Data on Millions of Users, Analysts Say,” The
Los Angeles Times, 10 December 2014,
www.latimes.com/business/technology/la-
fi-tn-alibaba-security-breach-20141210
story.html
7 Whittaker, Z.; “Kindle Security Vulnerability Can
‘Compromise’ Amazon Accounts,” ZDNet,
16 September 2014, www.zdnet.com/article/
kindle-security-vulnerability-can-compromise-
amazon-accounts/

ISACA JOURNAL VOL 3 51

 8 Wallop, H.; “eBay Hacking: Online Gangs
Are After You,” The Telegraph, 23 May 2014,
www.telegraph.co.uk/technology/internet-
security/10849689/eBay-hacking-online-gangs-
are-after-you.html
9 Android Studio, “Shrink Your Code and
Resources,” http://developer.android.com/
tools/help/proguard.html
10 Hewlett-Packard Development Company L.P.,
Mobile Application Security Study, February
2014, www8.hp.com/h20195/V2/GetPDF.
aspx/4AA5-1057ENW.pdf
11 Sanchez, A.; “Personal Banking Apps Leak Info
Through Phone,” IOActive, 8 January 2014,
http://blog.ioactive.com/2014/01/personal-
banking-apps-leak-info-through.html
12 Higgins, K. J.; ”Weak Security in Most Mobile
Banking Apps,” InformationWeek DarkReading,
12 December 2013, www.darkreading.com/
vulnerabilities---threats/weak-security-in-most-
mobile-banking-apps/d/d-id/1141054
13  Op cit, Sanchez
14 Microsoft, “What Is the Security Development
Lifecycle?,” Security Development Lifecycle,
www.microsoft.com/en-us/sdl/
15 BSIMM, “What We Do,” www.bsimm.com/
16 Sareen, P.; “Updated: After Ola & ZopNow
Tech Screw Up, This Time Foodpanda
Becomes the Target of a New Hack for Getting
Free Food!!,” Inc42, 10 April 2015, https://
inc42.com/buzz/after-ola-zopnow-this-time-
foodpanda-becomes-target-of-a-new-hack-for-
getting-free-food/
17 IEEE Cybersecurity, “Avoiding the Top 10
Software Security Design Flaws,” 13 November
2015, http://cybersecurity.ieee.org/center-for-
secure-design/avoiding-the-top-10-security-
flaws.html
18 The Open Web Application Security Project,
“OWASP Mobile Security Project,” 18 July
2016, www.owasp.org/index.php/OWASP_
Mobile_Security_Project#tab=Mobile_Security_
Testing
19 Euopean Union Agency for Network and
Information Security, “Smartphone Secure
Development Guidelines,” 25 November 2011,
www.enisa.europa.eu/activities/Resilience-
and-CIIP/critical-applications/smartphone-
security-1/smartphone-secure-development-
guidelines
52 ISACA JOURNAL VOL 3
20 Android, “Security Tips,” http://developer.
android.com/training/articles/security-tips.html
21 Apple Inc., “Introduction to Secure
Coding Guide,” Mac Developer Library,
https://developer.apple.com/library/mac/
documentation/Security/Conceptual/
SecureCodingGuide/Introduction.html
22 For more information, see http://heartbleed.com/
23 BlackDuck, “Future of Open Source Survey,”
2016, https://info.blackducksoftware.com/
rs/872-OLS-526/images/FOOS_Infographic_
Security.pdf
24 Helppi, V.; “What Heartbleed Bug Means to
App Developers? Testdroid Has You Covered,”
bitbar.com, 10 April 2014, http://bitbar.
com/what-heartbleed-bug-means-to-app-
developers-testdroid-has-you-covered/
25 Acharya, S.; “Heartbleed Bug: How to Protect
Android Devices,” International Business Times,
12 April 2014, www.ibtimes.co.uk/heartbleed-
bug-how-protect-android-devices-1444508
26 GItHub, “Androwarn,” https://github.com/
maaaaz/androwarn
27 GItHub, “Qark,” https://github.com/linkedin/
qark
28 GItHub, “findbugs,” https://github.com/
findbugs/findbugs
29 GItHub, “Infer,” https://github.com/facebook/
infer
30 Damn Vulnerable iOS Application (DVIA),
http://damnvulnerableiosapp.com/
31  Op cit, OWASP
32 Gianchandani, P.; “iOS Application Security
Part 1—Setting Up a Mobile Pentesting
Platform,” 16 June 2013, http://
highaltitudehacks.com/2013/06/16/ios-
application-security-part-1-setting-up-a-
mobile-pentesting-platform/
33 The Open Web Application Security Project,
“SettingupMobileTestingLab,” 7 June 2013,
www.owasp.org/index.php/
SettingupMobileTestingLab
34 
Op cit, Hewlett-Packard Development
Company L.P.
 fuente de
ayuda
Q
Varias encuestas señalan que entre 20 y 50 mil
millones de dispositivos serán conectados
a través de Internet por 2020. ¿Cuáles son las
amenazas asociadas con el uso de la Internet de
las Cosas (IoT) y qué enfoque se debe tener en la
implementación de la seguridad para IoT?
A
Hasta ahora, las consideraciones de seguridad
de la información están bien establecidas.
Iniciativas para centrarse en la seguridad cibernética
debido a nuevas amenazas como la denegación
de servicio distribuida (DDoS), las amenazas
persistentes avanzadas Y los ataques dirigidos ya
están siendo implementados por las organizaciones.
La implementación de IOT presenta nuevos desafíos
de seguridad, especialmente a medida que esta
tecnología se vuelve más penetrante e integrada
en nuestra vida cotidiana. Esas preocupaciones
incluyen:
• ¿Pueden dispositivos conectados a través de
Internet ser sujetos a ataques de malware?
• ¿Pueden estos dispositivos ser usados para
lanzar DDoS ataques?
• ¿Los dispositivos mal asegurados servirán como
puntos de entrada para los ciberataques?
• ¿Se aprovechará la transmisión de datos de
estos dispositivos, dando como resultado fugas
de datos y problemas relacionados con la
privacidad?
Abordar estos retos para asegurar que los productos
y servicios de IOT tengan controles para mitigar el
riesgo debe ser considerado antes de implementar
estos servicios y productos. Las preocupaciones
se intensifican aún más debido a la complejidad
involucrada en el despliegue de productos y servicios
de IoT. Otras consideraciones, como el despliegue
masivo, los canales de comunicación de dispositivos
a dispositivos, la colocación de estos dispositivos
en entornos no seguros y otras vulnerabilidades
presentes en entornos back-end que generalmente
se implementan utilizando la tecnología de la nube
contribuyen a esta complejidad. Los dispositivos IoT
se despliegan en muchos lugares como hogares,
oficinas, tiendas, edificios, hospitales, fábricas,
lugares de trabajo, áreas de la ciudad.
El éxito de estos servicios y productos basados en
IOT depende de la pregunta: “¿Confiarán los usuarios
estos productos y servicios?”. Para establecer esta
¿Tienes algo que
comentar sobre
confianza, los proveedores de servicios deben este artículo?
Visita las páginas del
proteger los dispositivos IoT de vulnerabilidades.
Journal en el sitio web
Las preocupaciones de seguridad relacionadas con
de ISACA® website
IoT son: (www.isaca.org/
• El costo de los dispositivos puede aumentar
debido a la seguridad que debe implementarse.
journal), encuentra el
artículo y hace click
en el link Comments
• La interoperabilidad de los dispositivos es una para compartir tus
preocupación ya que hay muchas entidades a las pensamientos.
que los dispositivos necesitan ser conectados.
Estos pueden ser otro dispositivo de otro
fabricante, proveedor de servicios de pórticos,
proveedor de servicios de plataforma y usuarios de
datos.
• Actualización de dispositivos o parchear
dispositivos para abordar la vulnerabilidad
identificada después del despliegue. Los usuarios
no pueden seguir el proceso de actualización
necesario debido a inconvenientes.
• Corrección de vulnerabilidades después de la
implementación puede ser difícil y más costoso.
• Los dispositivos desplegados no se pueden
mantener debido a la falta de disponibilidad del
fabricante/contrato de mantenimiento, etc.
• Las cuestiones regulatorias y legales
transfronterizas pueden hacer más difícil
garantizar la seguridad de los dispositivos IoT.
Para abordar estas preocupaciones, es necesario
adoptar un enfoque de colaboración para la
seguridad. El enfoque clásico para la recopilación
de información y la seguridad cibernética ayudará
a proporcionar una seguridad razonable a los
usuarios. Se pueden considerar los siguientes
puntos:
Sunil Bakshi, CISA, CRISC, CISM, CGEIT, ABCI, AMIIB, BS 25999 LI,
CEH, CISSP, ISO 27001 LA, MCA, PMP
Ha trabajado en TI, gobierno de TI, auditoría de SI, seguridad de la información
y gestión de riesgos de TI. Tiene 40 años de experiencia en diversos cargos en
diferentes industrias. Actualmente, es consultor independiente y miembro del
profesorado visitante en el Instituto Nacional de Gestión de Bancos, India.
ISACA JOURNAL VOL 3 53

• Evaluación de riesgos—Mientras se planifica el
desarrollo de dispositivos y servicios relacionados
con la IOT, una evaluación detallada del riesgo
usando el negocio es el primer paso. Muchas
organizaciones adoptan un enfoque de evaluación
de riesgos basado en activos para la tecnología
de la información que puede no ayudar en
esta situación. Es necesario considerar la
“incertidumbre en la consecución de los objetivos
de negocio” y evaluar el riesgo sobre la base de
los posibles efectos no sólo en los negocios, sino
también en los usuarios de estos dispositivos
interconectados.
• Desarrollo seguro de aplicaciones—Los
dispositivos IoT se colocan en Internet y, por
lo tanto, están sujetos a riesgos relacionados
con Internet. Teniendo en cuenta el despliegue
masivo, será muy difícil y definitivamente no
es rentable monitorear estos dispositivos
para ataques cibernéticos conocidos como el
ambiente de TI interno sería capaz de hacer. Por
lo tanto, construir la seguridad en el diseño de los
dispositivos y las aplicaciones que controlarán
estos dispositivos mientras que desarrollan las
aplicaciones es el mejor acercamiento preventivo.
• Seguridad del canal de comunicación—Casi
todos los dispositivos IoT están conectados
a Internet en las conexiones Wi-Fi en la casa
de un usuario u oficina, o donde quiera que
se encuentre el dispositivo. Si esta conexión
es insegura, IoT puede verse comprometida.
Por ejemplo, un refrigerador desprotegido o un
televisor infectado con malware puede enviar
miles de correos electrónicos nocivos de spam
a los destinatarios de todo el mundo mediante la
conexión a Internet Wi-Fi del propietario1.
Los dispositivos IoT adoptan múltiples modelos
de comunicación2:
54 ISACA JOURNAL VOL 3
– Dispositivo a dispositivo
– Dispositivo a plataforma (nube)
– Dispositivo a puerta de enlace
– Compartición de datos back-end
El despliegue de estos modelos depende de
los productos y servicios proporcionados. La
seguridad de la comunicación depende de la
respuesta a la pregunta: “¿Cuán seguros son
estos canales?” El uso de encriptación en el
nivel de aplicación es una forma de asegurar la
comunicación; sin embargo, el problema aquí es
el de la interoperabilidad entre los proveedores
de servicios de los pórticos, los proveedores
de servicios en la nube o la plataforma, los
fabricantes de dispositivos y los usuarios
de datos back-end compartidos desde una
plataforma en la nube (cloud).
• Seguridad de la plataforma—Las
organizaciones que hospedan servicios de
plataforma deben adoptar las directrices de
seguridad en la nube.
• Métricas de rendimiento para los dispositivos
implementados—Dado que estos dispositivos
pueden comunicarse, es más fácil capturar
datos relacionados con el rendimiento. Sin
embargo, debe ser apoyado por el monitoreo del
desempeño e identificar los problemas, si los hay.
• Cumplimiento relacionado con la privacidad—
Puesto que los dispositivos IoT recopilan y
comunican los datos a dispositivos back-end u
otros, los usuarios deben ser conscientes de la
naturaleza y el tipo de datos que se comunican.
De acuerdo con los principios de privacidad, se
debe proporcionar aviso y elección de opción
antes de implementar el dispositivo.
• Supervisión de amenazas y gestión de
incidentes—Las amenazas a la plataforma de
back-end deben ser monitoreadas; Sin embargo,
debido a la extensión de los dispositivos IoT,
es imposible supervisar cada uno de ellos
individualmente y tomar medidas correctivas.
Q
Todavía estoy luchando con la auditoría del
entorno de la nube. También conozco recursos
como el Cloud Security Alliance Security Trust y
Assurance Registry (CSA STAR) y Cloud Controls
Matrix (CCM) y el cuestionario de la Iniciativa de
Evaluación de Consenso (CAIQ). También aprovecho
otros artefactos como el PCI DSS) (Por ejemplo, Ro’s,
etc.), auditorías de la organización de controles de
servicios (SOC), etc.
Sin embargo, sólo un subconjunto de los
proveedores de servicios en mi entorno, tienen estos
artefactos. ¿Cuáles son algunas de las mejores
prácticas para lograr esto-particularmente con
proveedores de servicios más pequeños que podrían
no saber qué son estas cosas?
A
Cualquier auditoría se planifica en función del
alcance de la auditoría. Ahora, ¿cuál es
el alcance de su auditoría? Supongo que está
auditando una organización que está utilizando
un proveedor de servicios de la nube (cloud) para
la tecnología de la información. Puede ser sólo
para infraestructura (IaaS); o plataformas (PaaS),
incluyendo sistemas operativos, bases de datos,
middleware excepto la aplicación; o puede utilizar
aplicaciones alojadas en la nube (SaaS). Los
objetivos de la auditoría cambiarán dependiendo del
tipo de servicio.
Continuar la auditoría mediante la comprensión de
los objetivos de la organización siendo auditada.
Cuando se trata de auditoría de servicios en la
nube prestados por un proveedor de servicios
de terceros, utilizar técnicas de auditoría como
cualquier otro proveedor de servicios de terceros
con el enfoque en los objetivos de la organización.
Verificar el contrato para el tipo de aseguramiento
del proveedor de servicios. Tenga en cuenta que el
uso de servicios de la nube de terceros es el mismo
que el de tercerización en una ubicación de terceros.
(Puede consultar la gestión de proveedores utilizando
COBIT® 5. El libro tiene un capítulo sobre cómo
gestionar proveedores de servicios en la nube3.)
Podría haber dos opciones en el contrato.
1. El proveedor de servicios le permite, como
auditor, auditar el entorno de la nube.
2. El proveedor de servicios proporciona un informe
de auditor externo independiente.
En el caso de la primera opción, donde necesita
auditar al proveedor de servicios en la nube, los
recursos que mencionó son útiles. La principal
ventaja de estos recursos es que proporcionan una
referencia para seleccionar controles apropiados.
Tenga en cuenta que sólo los controles aplicables
del CCM de la CSA podrían requerirse para ser
auditados en función de los niveles de servicio.
La versión amistosa del CAIQ del CCM usando
preguntas sí/no puede también ayudar a una
evaluación rápida.
El registro STAR de CSA4 es una lista de proveedores
de servicios en la nube que cumplen con los requisitos
de seguridad de CSA. IT es lo mismo que la
certificación ISO 27001, que puede proporcionar una
garantía limitada de que el tercero ha implementado
los controles requeridos; sin embargo, su efectividad
en curso necesita ser verificada.
En el caso de la segunda opción, el proveedor de
servicios en la nube tiene muchos clientes y, por lo
tanto, puede no estar de acuerdo en ser auditado por
cada cliente. En este escenario, asegúrese de que
el informe del auditor independiente esté disponible.
Anteriormente, el informe de auditoría SAS70 era
el más común, el cual ahora ha sido sustituido por
SSAE16/SAE 34025. Tiene tres tipos de informes:
• El SOC 1 se centra en los controles pertinentes
sobre la información financiera.
• SOC 2 se refiere a la seguridad, disponibilidad,
integridad, confidencialidad y privacidad de los
sistemas de información.
• SOC 3 es como una certificación y no
proporciona detalles de las pruebas realizadas.
Algunos auditores expertos opinaron que el SSAE
16 es más estricto que el ISAE 3402, ya que
requiere que el auditor evalúe el riesgo asociado
con actos intencionales por parte del personal de la
organización de servicios.
Notas Finales
1 Starr, M.; “Fridge Caught Sending Spam Emails
in Botnet Attack,” CNET, 19 January 2014,
www.cnet.com/news/fridge-caught-sending-
spam-emails-in-botnet-attack/
2 Rose, K.; S. Eldridge; L. Chapin; The Internet of
Things: An Overview, October 2015,
www.internetsociety.org/sites/default/files/ISOC-
IoT-Overview-20151022.pdf
3 ISACA®, COBIT® 5, USA, 2012, www.isaca.org/
COBIT/pages/default.aspx
4 Cloud Security Alliance, CSA Security,
Trust and Assurance Registry (STAR),
https://cloudsecurityalliance.org/star/
5 International Standard on Assurance
Engagements, ISAE No. 3402, http://isae3402.
com/ISAE3402_overview.html
ISACA JOURNAL VOL 3 55
 crossword
puzzle by Myles Mellor
www.themecrosswords.com

ACROSS 1 2 3 4 5 6 7 8 9 10

1 General area of stopping cyberattacks before 11

they occur
8 Root ___, they enable illegal access to systems 12 13 14 15 16
11 One of Columbus’ ships
12 Time record 17
13 Data is this type of asset
17 Computer setting when not in use 18 19 20 21
18 Be onboard with
19 Binary digit 22
20 Less disciplined
23 Acronym for a section in ISACA’s COBIT® 5 23 24 25 26
family of products
25 Protected 27
28 Information that describes other information,
goes with 48 across 28 29 30 31
30 Made a list of commands for a program to
automate processes 32 33 34
32 Symbol for atomic number 18
33 Insect that is a symbol of business 35 36 37
35 Detect while in the act of committing a crime,
38 39
2 words
37 State where no hostile actions are occurring
40 41 42 43 44 45 46
40 Restoring data and systems after a cyberattack
43 These scans are used in some security systems
47 48 49 50
47 Vitamin measurement, abbr.
48 See 28 across
51 52
50 Thoroughly comb
51 Assessment, often numerical
52 Resources

24 Business degree
DOWN 26 Discovery of a cyberattack, as it occurs
27 Function
1 Multimedia file distribution 28 Computer brand
2 Added data 29 Wipe clean
3 Compete 31 Capital city
4 Means inside at the beginning of a word 34 French for and
5 Do perfectly 36 Providers of this storage service have a vested
6 Aim interest in having excellent security
7 Word before negotiable or partisan 37 Green goal, for many
9 Communication area subject to phishing attacks 38 Memory unit
10 Attempt to get financial information illegally, 39 This type of data is a storage vendor’s dream
____ phishing 40 Hook (up)
14 Prefix meaning new 41 Tom Clancy subject, for short
15 Imitate 42 Computer capacity, for short
16 Spur into action 44 Serpentine shape
17 Compass point 45  Top Gun star initials
21 Time before 46 13th Greek letter
22 Frequently used access criteria, 2 words 49 Airline, for short

Answers on page 58

56 ISACA JOURNAL VOL 3

quiz#172
Basado en Volume 1, 2017—Cognitive Technology
Value—1 Hour of CISA/CRISC/CISM/CGEIT Continuing Professional Education (CPE) Credit
VERDADERO O FALSO
ARTICULO ZONGO
1. De acuerdo a Bank of America Merrill Lynch
Research, la adopción de sistemas de
inteligencia artificial (IA) se esperara que se
mantenga estática durante los siguientes
años.
2. Tres preocupaciones relacionadas al riesgo
enfrentan los lideres cuando adoptan IA dentro
de sus empresas, estos son: (1) decisiones
críticas para el negocio basadas en errados o
mal utilizados algoritmos de IA, (2) resistencia
cultural por parte de empleados cuyos roles
son susceptibles a ser automatizados, y (3) se
ve aumentado el campo de acción de
las cyber amenazas en la medida que IA
reemplaza funciones más vitales del negocio
3. En el 2012, la empresa basada en EEUU
Knight Capital Group perdió más de $440
USD en 30 minutos, debido a un cambio en
un algoritmo que no fue probado previamente.
4. Para garantizar una resistencia a las cyber-
amenazas para los sistemas de IA, un
mecanismo disponible para los gerentes
es utilizar los estándares aceptados por la
industria, ya existentes, tales como: (1) Open
Web Application Security Project (OWASP)
Top 10, (2) Marco de trabajo para la Cyber
seguridad del Instituto Nacional de Estándares
y Tecnología de EEUU (NIST) , o (3) COBIT® 5
para la Seguridad de la Información
ARTICULO BISWAS AND MUKHOPADHYAY
5. Los ataques de phishing son dirigidos
a usuarios ingenuos, para instarlos que
divulguen involuntariamente información
critica
6. El modelo hibrido de phishing consiste en 3
módulos: (1) Analisys de riesgo para calcular
la probabilidad de que una URL pueda
conducir a un eventual ataque de phishing, (2)
calculo de Perdida, que consiste en determinar
la perdida estimada para los dueños, después
del ataque de phishing, (3) mitigación de
riesgo ofreciendo recomendaciones técnicas
y sociales para minimizar las perdidas
resultantes de un ataque de este tipo.
7. Las tres etapas de un ataque de phishing son:
(1) los usuarios leen, el o los correos, (2) los
usuarios hacen click en una URL legítima, y
(3) los usuarios comparten sus credenciales a
travez de esta URL legítima.
8. Si se cuenta mecanismos de reducción de
riesgo tales como herramientas tecnológicas,
ayuda a la alta gerencia y además con un
equipo de respuesta a incidentes (CERT),
entonces no hay necesidad de proveer
entrenamiento a los usuarios para que estos
estén en conocimiento del comportamiento
de los ataques de phishing y sus categorías.
ARTICULO PAL AND MUKHOPADHYAY
CPE
quiz
9. L a telemedicina es un componente de la
e-salud, que utiliza las comunicaciones y
tecnologías de la información (ICT) para
proveer servicios de salud y cuidados
superando las barreras de distancia,
conectando al proveedor de salud con el
paciente. Preparado por
10. El mercado de la telemedicina está creciendo Kamal Khan
globalmente en una tasa de crecimiento anual CISA, CISSP,
compuesta (CAGR) del 14.3 por ciento y, entre CITP, MBCS
el 2014 y el 2020, se espera que alcance los
US $36.3 trillones.
11. El servicio de despacho o entrega de
telemedicina no es adecuado o viable para
India, porque tiene regiones muy extensiones
vastas de montañas así como regiones de
tribus, e islas. En las cuales el 2 por ciento
de los doctores de desempeña en regiones
urbanas, 14 por ciento en áreas semi-urbanas
y solo el 23 por ciento en áreas rurales, donde
la gran mayoría de las personas habita.
ARTICULO ACOSTA
12. Restarle valor a la información pobremente
escrita de políticas de seguridad, puede ser
relativamente fácil ya que la gran parte de
estos documentos están basados en plantillas
genéricas, y rara vez son revisadas, no son Take the quiz online
adaptadas a la realidad y actualidad del
negocio de la organización, o adaptadas al
actual estados de su sistema de información,
y generalmente no incluyen procedimientos
para manejar excepciones.
13. Un control compensatorio de define como
un tipo de control interno o mecanismo
entendido para encontrar problemas dentro
de los procesos de una compañía.
14. Una vez que la política de seguridad es
desarrollada y aprobada, no hay necesidad
de revisar o actualizarla, y esto debiese ser
estipulado en la misma.
ARTICULO MOYLE
15. Cuando se trata de gobernabilidad en
tecnología, (gobernabilidad de empresa
TI [GEIT]), existe una gran variedad de
herramientas que pueden ayudar al
encargado.
16. La administración de activos es un desafío
de realizar a cabalidad, por consiguiente,
ayudarse con herramientas que apalanque
y ayuden a la administración de activos,
puede tener un beneficio de largo alcance en
distintas áreas.
ISACA JOURNAL VOL 3 57
 CPE
quiz#172
Formulario de respuestas
Basado en Volume 1, 2017

Verdadero o falso
ARTICULO ZONGO ARTICULO PAL AND Nombre
MUKHOPADHYAY PLEASE PRINT OR TYPE
1.
9.
2.
10. Dirección
3.
11.
4.

ARTICULO ACOSTA
ARTICULO BISWAS AND CISA, CRISC, CISM or CGEIT #
MUKHOPADHYAY 12.
5.
13.
6. Answers: Crossword by Myles Mellor
14.
See page 56 for the puzzle.
7.
1 2 3 4 5 6 7 8 9 10

8. ARTICULO MOYLE P R
11
E V E N T I O N K I T S
O N I N A N O N P

15.
12 13 14 15 16
D A T E I N T A N G I B L E
17
C E S L E E P A O A

16.
18 19 20 21
A G R E E O N E L A X E R
22
S E R T V V
23 24 25 26
T D M B O K G U A R D E D
27
B L U N E
28 29 30 31
M E T A E S C R I P T E D
32 33 34
A R B E E Z E C
Please confirm with other designation-granting professional bodies for their CPE qualification acceptance criteria. 35 36 37
Quizzes may be submitted for grading only by current Journal subscribers. An electronic version of the quiz is C A T C H A T P E A C E
available at www.isaca.org/cpequiz; it is graded online and is available to all interested parties. If choosing to submit S L S
38
B A T
39
D
using this print copy, please email, fax or mail your answers for grading. Return your answers and contact information 40 41 42 43 44 45 46
by email to info@isaca.org or by fax to +1.847.253.1755. If you prefer to mail your quiz, in the US, send your CPE R E C O V E R Y R E T I N A
Quiz along with a stamped, self-addressed envelope, to ISACA International Headquarters, 3701 Algonquin Rd., I
47
I U
48
D A T
49
A
50
S C O U R
#1010, Rolling Meadows, IL 60008 USA. Outside the US, ISACA will pay the postage to return your graded quiz. You 51 52
need only to include an envelope with your address. You will be responsible for submitting your credit hours at year- G R A D E M E A N S N K
end for CPE credits. A passing score of 75 percent will earn one hour of CISA, CRISC, CISM or CGEIT CPE credit.

Get Noticed!
Advertise in the ISACA® Journal

Journal
For more information, contact media@isaca.org

58 ISACA JOURNAL VOL 3

Guías y Estándares
herramientas y técnicas
Cumplimiento miembro de ISACA y portador de IS Audit and Assurance Guidelines
 as guías están diseñadas para apoyar directamente los estándares y ayudar a
L
una certificación los practicantes lograr su alineación con los estándares. Estas siguen la misma
categorización al igual que los estándares (también divididos en tres categorías):
Aseguramiento y las habilidades necesarias para efectuar este tipo de
compromisos requiere estándares que se apliquen específicamente a las auditorias
SI y aseguramiento. El desarrollo y diseminación de las auditorias de SI y • Guías Generales (series 2000)
estándares de aseguramiento son una piedra angular de la contribución profesional • Guías de Desempeño (series 2200)
de ISACA con la comunidad de auditoria. • Guías de Reportes (series 2400)
Auditorias SI y estándares de aseguramiento define los requisitos mandatorios para General
la auditoria SI. Ellos reportan e informan: 2001 – Estatuto de Auditoria
2002 – Independencia Organizacional
• Profesionales de Auditoria SI y aseguramiento del nivel mínimo aceptable del
desempeño requerido para cumplir con las responsabilidades establecidas en el 2003 – Independencia Profesional
Código de Ética de Profesionales de ISACA. 2004 – Expectación Razonable
• Gerentes y otras partes interesadas de las expectativas de la profesión 2005 – Debido Cuidado Profesional
relacionado con el trabajo de los practicantes.
2006 – Competencia
• Poseedores de la designación de “Certified Information Systems Auditor (CISA)
2007 – Afirmaciones
de requisitos. Si fallan en cumplir con estos estándares puede resultar en una
investigación de la conducta del poseedor de CISA por la Junta de Directores de 2008 – Criterio
ISACA o comité apropiado y finalmente en una acción disciplinaria.
Desempeño
2201 – Planificación de Trabajo
2202 – Evaluación de Riesgo en Planeación
ITAF , 3 Edition
TM rd
2203 – Desempeño y Supervisión
(www.isaca.org/itaf) provee un marco de referencia para múltiples niveles de guías: 2204 – Materialidad
Auditoria SI y Estándares de Aseguramiento 2205 – Evidencia
2206 – Utilizando el Trabajo de otros Expertos
Los estándares han sido divididos en tres categorías:
2207 – Actos irregulares e ilegales
• Estándares Generales (series 1000)—Son los principios guía bajo el cual 2208 - Muestreo
la profesión de aseguramiento de SI opera. Aplica a la conducta de todas
las asignaciones y hace frente con la auditoria SI y la ética del profesional
de aseguramiento, independencia, objetividad y al debido cuidado como al Reportes
conocimiento, competencia y habilidad.
2401 – Reportando
• Estándar de Desempeño (series 1200)—Hace frente a la conducta de la 2402 – Seguimiento Actividades
asignación, como ser planear y supervisar, determinación del alcance, riesgo
y materialidad, movilización de los recursos, supervisión y la gestión de Herramientas y técnicas de Auditoria SI y Aseguramiento
asignación, auditoria y evidencia de aseguramiento, y el ejercicio de su juicio
profesional y debido cuidado.
Estos documentos proveen de una guía adicional para los profesionales
• Estándares de Reportar (series 1400)—Abordar los tipos de reportes, medios de auditoria SI y aseguramiento y consiste, entre otras cosas, de white
de comunicación y la información comunicada. papers, programas de auditoria SI/aseguramiento, libros de referencia y la
familia de productos COBIT® 5. Herramientas y técnicas están listadas bajo
www.isaca.org/itaf.
Por favor tomar nota que las nuevas guías son efectivas a partir del 1 de
septiembre del 2014. Un glosario sobre términos utilizados en ITAF lo puede encontrar en línea en
www.isaca.org/glossary.
General Previamente de emitir cualquier nuevo estándar o guía, un borrador es
1001 – Estatuto de Auditoria emitido internacionalmente para consulta del público general.
1002 – Independencia Organizacional
1003 – Independencia Profesional Comentarios también pueden ser enviados a la atención del Director de
1004 – Expectación Razonable Privacidad y Practicas de Aseguramiento por correo (standards@isaca.org)
1005 – Debido Cuidado Profesional fax (+1.847.253.1443) o correo postal (ISACA International Headquartes,
3701, Algonquin Road, Suite 1010, Rolling Meadows, IL 60008-3105, USA).
1006 – Competencia
1007 – Afirmaciones Links a actuales y expuestos Estándares, Guías y Herramientas y Técnicas
1008 – Criterio de ISACA están posteadas en www.isaca.org/standards.

Disclaimer: ISACA ha designado esta guía como el nivel mínimo de

Desempeño desempeño aceptable requerido para cumplir con las responsabilidades de
1201 – Planificación de Trabajo profesionales expuestas en el Código de Ética Profesional de ISACA. ISACA
1202 – Evaluación de Riesgo en Planeación no garantiza que los usos de estos productos aseguraran un resultado
1203 – Desempeño y Supervisión exitoso. La orientación no debe ser considerada inclusive de cualquier
1204 – Materialidad procedimiento y pruebas propias o exclusivos de otros productos y pruebas
que son razonablemente dirigidos para obtener los mismos resultados. Para
1205 – Evidencia determinar la conveniencia de cualquier procedimiento o prueba específica,
1206 – Utilizando el Trabajo de otros Expertos los profesionales de control deben aplicar su propio juicio profesional a
1207 – Actos irregulares e ilegales las circunstancias específicas de control presentados por los sistemas
particulares o ambientes de SI.
Reportes
1401 – Reportando
1402 – Seguimiento Actividades

ISACA JOURNAL VOL 3 59

ISACA® Journal, formerly
Information Systems Control
Journal, is published by the
Information Systems Audit and
Control Association® (ISACA®),
a nonprofit organization
created for the public in 1969.
Membership in the association,
a voluntary organization
serving IT governance
professionals, entitles one to
receive an annual subscription
to the ISACA Journal.
Opinions expressed in the
ISACA Journal represent
the views of the authors and
advertisers. They may differ
from policies and official
statements of ISACA and/or
the IT Governance Institute
and their committees, and from
opinions endorsed by authors,
employers or the editors of the
Journal. ISACA Journal does
not attest to the originality of
authors’ content.
© 2017 ISACA. All rights
reserved.
Instructors are permitted to
photocopy isolated articles for
noncommercial classroom use
without fee. For other copying,
reprint or republication,
permission must be obtained
in writing from the association.
Where necessary, permission
is granted by the copyright
owners for those registered
with the Copyright Clearance
Center (CCC) (www.copyright.
com), 27 Congress St., Salem,
MA 01970, to photocopy
articles owned by ISACA,
for a flat fee of US $2.50 per
article plus 25¢ per page.
Send payment to the CCC
stating the ISSN (1944-1967),
date, volume, and first and
last page number of each
article. Copying for other
than personal use or internal
reference, or of articles or
columns not owned by the
association without express
permission of the association
or the copyright owner is
expressly prohibited.
ISSN 1944-1967
Subscription Rates:
US:
one year (6 issues) $75.00
All international orders:
one year (6 issues) $90.00.
Remittance must be made
in US funds.
websites
advertisers/
Tronixss
Hiscox
SCCE
supporters
leaders and
Editor
Jennifer Hajigeorgiou
publication@isaca.org
Managing Editor
Maurita Jasper
Contributing Editors
Sunil Bakshi, CISA, CRISC, CISM, CGEIT,
ABCI, AMIIB, BS 25999 LI, CEH,
CISSP, ISO 27001 LA, MCA, PMP
Sally Chan, CGEIT, CPA, CMA
Ed Gelbstein, Ph.D.
Kamal Khan, CISA, CISSP, CITP, MBCS
Vasant Raval, DBA, CISA
Steven J. Ross, CISA, CBCP, CISSP
Smita Totade, Ph.D., CISA, CRISC, CISM,
CGEIT
Advertising
media@isaca.org
Media Relations
news@isaca.org
Reviewers
Matt Altman, CISA, CRISC, CISM, CGEIT
Sanjiv Agarwala, CISA, CISM, CGEIT,
CISSP, ITIL, MBCI
Vikrant Arora, CISM, CISSP
Cheolin Bae, CISA, CCIE
Sunil Bakshi, CISA, CRISC, CISM, CGEIT,
ABCI, AMIIB, BS 25999 LI, CEH,
CISSP, ISO 27001 LA, MCA, PMP
Brian Barnier, CRISC, CGEIT
Pascal A. Bizarro, CISA
Jerome Capirossi, CISA
Anand Choksi, CISA, CCSK, CISSP, PMP
Joyce Chua, CISA, CISM, PMP, ITILv3
Ashwin K. Chaudary, CISA, CRISC, CISM,
CGEIT
Burhan Cimen, CISA, COBIT Foundation,
ISO 27001 LA, ITIL, PRINCE2
Ian Cooke, CISA, CRISC, CGEIT, COBIT
Foundation, CFE, CPTS, DipFM, ITIL
Foundation, Six Sigma Green Belt
Ken Doughty, CISA, CRISC, CBCP
Nikesh L. Dubey, CISA, CRISC,
CISM, CISSP
Ross Dworman, CISM, GSLC
Robert Findlay
John Flowers
Jack Freund, CISA, CRISC, CISM,
CIPP, CISSP, PMP
Sailesh Gadia, CISA
Amgad Gamal, CISA, COBIT Foundation,
CEH, CHFI, CISSP, ECSA, ISO 2000
LA/LP, ISO 27000 LA, MCDBA, MCITP,
MCP, MCSE, MCT, PRINCE2
Robin Generous, CISA, CPA
Anuj Goel, Ph.D., CISA, CRISC,
CGEIT, CISSP
www.rcap.online
hiscox.com/impossible
corporatecompliance.org/academies
Tushar Gokhale, CISA, CISM, CISSP,
ISO 27001 LA
Tanja Grivicic
Manish Gupta, Ph.D., CISA, CRISC,
CISM, CISSP
Mike Hansen, CISA, CFE
Jeffrey Hare, CISA, CPA, CIA
Sherry G. Holland
Jocelyn Howard, CISA, CISMP, CISSP
Francisco Igual, CISA, CGEIT, CISSP
Jennifer Inserro, CISA, CISSP
Khawaja Faisal Javed, CISA, CRISC, CBCP,
ISMS LA
Mohammed Khan, CISA, CRISC, CIPM
Farzan Kolini, GIAC
Abbas Kudrati, CISA, CISM, CGEIT, CEH,
CHFI, EDRP, ISMS
Shruti Kulkarni, CISA, CRISC, CCSK, ITIL
Bhanu Kumar
Hiu Sing (Vincent) Lam, CISA, CPIT(BA),
ITIL, PMP
Edward A. Lane, CISA, CCP, PMP
Romulo Lomparte, CISA, CRISC, CISM,
CGEIT, CRMA, ISO 27002, IRCA
Juan Macias, CISA, CRISC
Larry Marks, CISA, CRISC, CGEIT
Norman Marks
Tamer Marzouk, CISA, ABCP, CBAP
Krysten McCabe, CISA
Brian McLaughlin, CISA, CRISC, CISM,
CIA, CISSP, CPA
Brian McSweeney
Irina Medvinskaya, CISM, FINRA, Series 99
David Earl Mills, CISA, CRISC, CGEIT,
MCSE
Robert Moeller, CISA, CISSP, CPA, CSQE
David Moffatt, CISA, PCI-P
Ramu Muthiah, CISM, CRVPM, GSLC,
ITIL, PMP
Ezekiel Demetrio J. Navarro, CPA
Jonathan Neel, CISA
Nnamdi Nwosu, CISA, CRISC, CISM,
CGEIT, PfMP, PMP
Anas Olateju Oyewole, CISA, CRISC, CISM,
CISSP, CSOE, ITIL
David Paula, CISA, CRISC, CISSP, PMP
Pak Lok Poon, Ph.D., CISA, CSQA, MIEEE
John Pouey, CISA, CRISC, CISM, CIA
Steve Primost, CISM
Parvathi Ramesh, CISA, CA
Antonio Ramos Garcia, CISA, CRISC, CISM,
CDPP, ITIL
Michael Ratemo, CISA, CRISC, CISM,
CSXF, ACDA, CIA, CISSP, CRMA
Ron Roy, CISA, CRP
Louisa Saunier, CISSP, PMP, Six Sigma
Green Belt
Daniel Schindler, CISA, CIA
Nrupak D. Shah, CISM, CCSK, CEH,
ECSA ITIL
Shaharyak Shaikh
Sandeep Sharma
Catherine Stevens, ITIL
Johannes Tekle, CISA, CFSA, CIA
Robert W. Theriot Jr., CISA, CRISC
Nancy Thompson, CISA, CISM,
CGEIT, PMP
Back Cover
3
1
Smita Totade, Ph.D., CISA, CRISC,
CISM, CGEIT
Jose Urbaez, CISA, CISM, CSXF, ITIL
Ilija Vadjon, CISA
Sadir Vanderloot Sr., CISA, CISM, CCNA,
CCSA, NCSA
Manoj Wadhwa, CISA, CISM, CISSP,
ISO 27000, SABSA
Anthony Wallis, CISA, CRISC, CBCP, CIA
Kevin Wegryn, PMP, Security+, PfMP
Tashi Williamson
Ellis Wong, CISA, CRISC, CFE, CISSP
ISACA Board of Directors
(2016–2017)
Chair
Christos Dimitriadis, Ph.D., CISA, CRISC
CISM, ISO 20000 LA
Vice-chair
Theresa Grafenstine, CISA, CRISC, CGEIT,
CGAP, CGMA, CIA, CPA
Director
Zubin Chagpar, CISA, CISM, PMP
Director
Rob Clyde, CISM
Director
Leonard Ong, CISA, CRISC, CISM, CGEIT,
COBIT 5 Implementer and Assessor,
CFE, CFP, CGFA, CIPM, CIPT, CISSP
ISSMP-ISSAA, CITBCM, CPP, CSSLP,
GCIA, GCIH, GSNA, PMP
Director
Andre Pitkowski, CRISC, CGEIT,
COBIT 5 Foundation, CRMA, ISO
27kLA, ISO 31000 kLA
Director
R.V. Raghu, CISA, CRISC
Director
Edward Schwartz, CISA, CISM, CAP,
CISSP, ISSEP, NSA-IAM, PMP, SSCP
Director
Jeff Spivey, CRISC
Director
Jo Stewart-Rattray, CISA, CRISC,
CISM, CGEIT
Director
Tichaona Zororo, CISA, CRISC, CISM,
CGEIT, COBIT Assessor and Trainer,
CIA, CRMA
Director and Chief Executive Officer
Matthew S. Loeb, CGEIT, CAE, FASAE
Director and Past Chair
Robert E Stroud, CRISC, CGEIT
Director and Past Chair
Tony Hayes, CGEIT, AFCHSE, CHE, FACS,
FCPA, FIIA
Director and Past Chair
Greg Grocholski, CISA