Seguridad de Aplicaciones y Datos

Objetivo de aprendizaje 5.1.A: Explicar cómo los adversarios pueden explotar vulnerabilidades en aplicaciones y archivos para causar pérdida, daño, interrupción o destrucción.

• 5.1.A.1 Un adversario puede leer cualquier archivo no cifrado si tiene acceso al dispositivo o a la unidad donde se almacenan los archivos.
• 5.1.A.2 Las computadoras tienen usuarios estándar y usuarios administrativos. Los usuarios administrativos tienen acceso para controlar la configuración del sistema y generalmente pueden acceder a cualquier archivo o aplicación en un sistema. Si a los usuarios regulares se les otorgan privilegios administrativos en una computadora y un adversario compromete la cuenta de un usuario, entonces el adversario tendrá privilegios elevados en el sistema.
• 5.1.A.3 Cuando la configuración del control de acceso es débil, muchos usuarios suelen tener permiso para ver e incluso editar archivos en un sistema. Los adversarios pueden aprovechar las configuraciones débiles de control de acceso para robar o destruir archivos o interrumpir una aplicación.

Objetivo de aprendizaje 5.1.B: Explicar cómo los ataques a aplicaciones explotan vulnerabilidades.

• 5.1.B.1 Las aplicaciones son programas que ejecutan instrucciones en computadoras; son datos ejecutables. Algunas aplicaciones se ejecutan localmente en la computadora de un usuario, mientras que otras aplicaciones, como las aplicaciones web, se ejecutan en un servidor y son accedidas por los usuarios a través de una red.
• 5.1.B.2 Muchas aplicaciones reciben entrada del usuario a través de campos de entrada abiertos donde los usuarios pueden escribir caracteres (por ejemplo, letras, números, puntuación). Los desarrolladores deben incluir comprobaciones de entrada del usuario en sus aplicaciones, como validar entrada numérica cuando se solicita una cantidad de elementos, para asegurar que la entrada del usuario coincida con lo esperado; la aplicación debe rechazar entradas fuera de los parámetros esperados. Este proceso de verificar que la entrada del usuario cumple con los criterios esperados antes de procesarla se denomina validación de datos. Las aplicaciones que no validan la entrada del usuario son vulnerables a ataques de tipo inyección, donde los adversarios insertan cadenas de caracteres inesperadas en los campos de entrada para alterar el comportamiento de un programa.
• 5.1.B.3 El lenguaje de consulta estructurado (SQL) es un lenguaje informático utilizado para solicitar información de bases de datos y realizar cambios en bases de datos o entradas en bases de datos. Las aplicaciones que consultan una base de datos utilizando entrada no validada o no sanitizada de los usuarios son vulnerables.
• 5.1.B.4 Un ataque de inyección SQL coloca comandos SQL y caracteres de control en un campo de entrada del usuario en una aplicación, lo que puede provocar una violación de la confidencialidad haciendo que la aplicación devuelva más información de la debida, o una violación de la integridad modificando o eliminando datos en la base de datos.
• 5.1.B.5 Los sitios web se escriben utilizando lenguaje de marcado de hipertexto (HTML), y muchos sitios web utilizan Javascript para crear contenido dinámico en sitios web o aplicaciones web. Debido a que los comandos de Javascript se ejecutan en el navegador del usuario que visita el sitio web, esos comandos pueden acceder a datos sensibles almacenados en el navegador, como nombres de usuario, contraseñas y claves criptográficas.
• 5.1.B.6 Un ataque de script entre sitios (XSS) inyecta código malicioso en un sitio web que luego ejecuta el navegador del usuario. El código malicioso puede estar incrustado en un enlace que hace clic el usuario (un ataque XSS reflejado de Tipo I o Reflected XSS) o puede ser insertado en un sitio web a través de un campo de comentarios, publicación de foro o registro de visitantes, lo que afectaría a cualquier usuario que visite ese sitio web (un ataque XSS almacenado de Tipo II o Stored XSS).
• 5.1.B.7 Cuando las aplicaciones toman entrada del usuario, esa entrada se escribe en un búfer. Un búfer es una sección designada de la memoria de la computadora con un tamaño fijo. Si la cantidad de datos que ingresa el usuario excede el tamaño del búfer, puede desbordarse en ubicaciones de memoria adyacentes y sobrescribir otras partes de la memoria de la computadora.
• 5.1.B.8 Un ataque de desbordamiento de búfer introduce más datos en la memoria de lo asignado, lo que puede causar que un sistema se bloquee o ejecute código fuera del alcance de la política de seguridad de un programa, permitiendo efectivamente que el adversario realice acciones no autorizadas en una computadora, como acceder, modificar o eliminar archivos.
• 5.1.B.9 Los archivos que ejecutan aplicaciones web se almacenan en directorios en servidores. Cuando los usuarios acceden a aplicaciones web, sus navegadores envían solicitudes GET utilizando el protocolo de transferencia de hipertexto (HTTP). Una solicitud GET accede a un archivo en algún lugar del sistema de archivos del servidor.
• 5.1.B.10 En un ataque de navegación de directorios, los adversarios modifican las URL y las solicitudes GET para intentar acceder a datos sensibles (por ejemplo, nombres de usuario y contraseñas) en el sistema de archivos de un servidor.
  • Ejemplos ilustrativos para 5.1.B.10:
    • Un servidor web almacena imágenes para un sitio web que aloja en el directorio /var/www/images/. Un adversario modifica una URL que solicita una imagen a ../../../etc/passwd. Los .. mueven un directorio hacia arriba en el sistema de archivos; por lo tanto, los tres puntos suspensivos consecutivos .. devuelven la ruta a la raíz, y desde allí el adversario intenta acceder al archivo passwd que devolvería una lista de todos los nombres de usuario autorizados en el dispositivo.

Objetivo de aprendizaje 5.1.C: Evaluar y documentar riesgos derivados de vulnerabilidades de aplicaciones y datos.

• 5.1.C.1 Los riesgos de seguridad de datos pueden implicar una compromiso de confidencialidad cuando personas no autorizadas pueden acceder a datos sensibles, integridad cuando los datos pueden ser manipulados o alterados desde su estado previsto, y disponibilidad cuando los datos pueden ser destruidos o cifrados para impedir que otros accedan a ellos.
• 5.1.C.2 Los riesgos altos por vulnerabilidades de datos a menudo involucran datos altamente sensibles (por ejemplo, datos regidos por leyes o regulaciones) que podrían ser comprometidos mediante una explotación muy probable.
  • Ejemplos ilustrativos para 5.1.C.2:
    • La empresa que desarrolla el próximo motor de reacción que será utilizado por la Fuerza Aérea en sus aviones está almacenando las especificaciones técnicas del motor en una unidad no cifrada.
• 5.1.C.3 Los riesgos moderados por vulnerabilidades de datos a menudo involucran datos sensibles que no tienen un cifrado suficientemente fuerte o controles de acceso lo suficientemente estrictos.
  • Ejemplos ilustrativos para 5.1.C.3:
    • Una empresa almacena la información personal identificable (PII) de sus clientes en una hoja de cálculo, y la hoja de cálculo está cifrada utilizando una clave pequeña.
• 5.1.C.4 Los riesgos bajos por vulnerabilidades de datos a menudo involucran información menos sensible que está cifrada con claves más cortas o que tiene controles de acceso que no son lo suficientemente estrictos.
  • Ejemplos ilustrativos para 5.1.C.4:
    • El CEO de una organización almacena sus memorandos privados dirigidos a su personal ejecutivo en una unidad compartida de la empresa que no está cifrada y no tiene controles de acceso.

Objetivo de aprendizaje 5.2.A: Explicar cómo el estado o la clasificación de los datos impacta en el tipo y el grado de seguridad aplicado a esos datos.

• 5.2.A.1 Las organizaciones implementan controles de seguridad específicos para cumplir con los requisitos legales basados en los tipos de datos que recopilan, almacenan, procesan y transmiten.
• 5.2.A.2 Los datos pueden clasificarse según su estado.
  • Los datos en reposo están almacenados en una unidad. Es importante proteger la unidad física que almacena los datos contra la destrucción o el robo. Los datos en reposo también pueden cifrarse para que, si un adversario los roba, no pueda leerlos inmediatamente.
  • Los datos en tránsito se están enviando de un dispositivo a otro. Si los datos se transfieren a través de medios físicos (p. ej., cables), es importante proteger dichos medios. Los datos en tránsito también pueden cifrarse para que, si un adversario los intercepta, no pueda leerlos inmediatamente.
  • Los datos en uso se están procesando mediante software o una persona. Los controles de acceso pueden utilizarse para limitar quién o qué tiene la capacidad de usar los datos de diferentes maneras (p. ej., ver o editar). Los datos deben estar descifrados para poder usarse.
• 5.2.A.3 Las organizaciones suelen categorizar los datos según su sensibilidad y priorizan un mayor grado de seguridad para la información más sensible.
• 5.2.A.4 Las leyes y regulaciones pueden exigir que ciertos tipos de datos se almacenen, transmitan y manejen de acuerdo con reglas específicas.
  • La información de identificación personal (PII) es cualquier dato que permite identificar a alguien e incluye (pero no se limita a): nombre, firma, número de teléfono, dirección, datos biométricos (p. ej., huellas dactilares), número de seguro social, fecha de nacimiento y dirección de correo electrónico. La protección de estos datos está cubierta por muchas leyes, pero destacan la Ley de Privacidad de 1974 y, para menores de 13 años, la Ley de Protección de la Privacidad en Línea para Niños de 1998.
  • La información médica protegida (PHI) es cualquier dato relacionado con la salud, el tratamiento o el pago de atención médica de una persona en cualquier momento e incluye (pero no se limita a): resultados de pruebas, registros de tratamiento, registros hospitalarios, notas de visitas al médico y registros de pagos del proveedor de salud. La protección de la PHI está incluida en la Ley de Portabilidad y Responsabilidad del Seguro Médico de 1996.
  • La información de tarjetas de pago (PCI) son los datos recopilados por las organizaciones para procesar pagos mediante tarjetas (p. ej., tarjetas de crédito) e incluyen lo siguiente: nombre, número de cuenta, fecha de vencimiento, dirección y código CVV. La protección de estos datos está regulada por el Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI-DSS).
• 5.2.A.5 Las organizaciones que recopilan datos regulados los etiquetan y tienen políticas que cumplen con los requisitos legales o regulatorios para el almacenamiento, transmisión y manejo seguros de estos datos.

Objetivo de aprendizaje 5.2.B: Identificar controles gerenciales relacionados con la seguridad de aplicaciones y datos.

• 5.2.B.1 Una política de criptografía describirá los protocolos de cifrado aceptables y los parámetros de clave para una organización y puede incluir:
  • Una lista de algoritmos de cifrado aprobados para usos específicos
  • Longitudes mínimas o máximas de las claves
  • Requisitos y parámetros de generación de claves criptográficas
  • Requisitos de almacenamiento de claves criptográficas
• 5.2.B.2 Una política de seguridad de aplicaciones web delineará los requisitos y parámetros para probar y mitigar vulnerabilidades de aplicaciones web en una organización, y puede incluir:
  • Parámetros sobre cuándo una aplicación está sujeta a una evaluación de seguridad
  • Plazos para remediar vulnerabilidades según el nivel de riesgo
  • Parámetros sobre cómo debe llevarse a cabo una evaluación de seguridad de la aplicación (p. ej., utilizando herramientas específicas o de acuerdo con marcos de trabajo específicos)

Objetivo de aprendizaje 5.2.C: Determinar un modelo de control de acceso adecuado para proteger aplicaciones y datos.

• 5.2.C.1 El control de acceso aplica qué usuarios o aplicaciones (llamados sujetos) pueden acceder, modificar, agregar o eliminar (llamadas operaciones) qué archivos o aplicaciones (llamados objetos). Los modelos de control de acceso describen cómo determinar qué sujetos tienen qué tipo de acceso a qué objetos.
• 5.2.C.2 El control de acceso basado en roles (RBAC) asigna cada sujeto a un rol y define qué roles tienen qué tipos de acceso a qué objetos.
  • Ejemplos ilustrativos para 5.2.C.2:
    • Un ejemplo de un rol en una empresa podría ser "contador", y un tipo de objeto podría ser el software de nómina. El control de acceso basado en roles podría utilizarse para garantizar que solo los sujetos asignados al rol de "contador" tengan acceso al objeto de software de nómina.
• 5.2.C.3 El control de acceso basado en reglas (RuBAC) verifica un conjunto de reglas para determinar qué tipo de acceso debe tener un sujeto para un objeto específico y luego permite o deniega tipos de acceso basándose en esas reglas. Este modelo de control de acceso suele superponerse a otro modelo de control de acceso.
  • Ejemplos ilustrativos para 5.2.C.3:
    • Existe una regla que prohíbe a los sujetos (incluso aquellos que normalmente tendrían acceso) acceder a una base de datos determinada (el objeto) fuera del horario laboral local. Cuando un sujeto intenta acceder a la base de datos, incluso si está autorizado para hacerlo, se le denegará el acceso si está fuera del tiempo designado por la regla.
• 5.2.C.4 El control de acceso discrecional (DAC) otorga a los sujetos individuales la capacidad de establecer el tipo de acceso que otros sujetos tienen sobre los objetos que poseen. En los modelos DAC, algunos sujetos son designados como administradores o usuarios privilegiados, y tienen la capacidad de anular los controles de acceso establecidos por otros sujetos.
  • Ejemplos ilustrativos para 5.2.C.4:
    • Bob crea un archivo (un objeto) y decide dar a Alice permiso para editar el archivo, conceder a Frank permiso solo para ver el archivo y denegar a todos los demás el acceso al archivo por completo.
• 5.2.C.5 El control de acceso obligatorio (MAC) sigue reglas estrictas sobre qué tipos de acceso tiene cada nivel de sujeto para los objetos que están por encima de su nivel, en su nivel o por debajo de su nivel. Los niveles de sujeto y objeto son asignados por un administrador externo.
• 5.2.C.6 El modelo Bell-LaPadula es un modelo MAC que suele ser utilizado por gobiernos y organizaciones militares para controlar la seguridad de la información. Este modelo tiene las siguientes dos propiedades importantes:
  • i. La Propiedad de Seguridad Simple establece que los sujetos no pueden leer objetos que estén por encima de su nivel.
  • ii. La Propiedad de Seguridad * (Estrella) establece que los sujetos no pueden escribir en objetos por debajo de su nivel.
  • Estas reglas tomadas juntas a menudo se resumen como "escribir arriba, leer abajo" (WURD).
• 5.2.C.7 El principio de mínimo privilegio es la idea de que las entidades deben recibir exactamente tanto acceso como necesitan para realizar su función y nada más.

Objetivo de aprendizaje 5.2.D: Configurar la configuración de control de acceso en un sistema basado en Linux.

• 5.2.D.1 La autorización es cuando se concede a una entidad el permiso para tener cierto tipo de acceso a un recurso. Se implementan controles de acceso para controlar qué usuarios tienen qué tipos de acceso a qué datos.
• 5.2.D.2 Hay tres tipos de acceso a un archivo en Linux que se pueden configurar, y siempre vienen en el siguiente orden:
  • i. El acceso de lectura permite a un usuario ver el contenido de un archivo.
  • ii. El acceso de escritura permite a un usuario realizar cambios en un archivo.
  • iii. El acceso de ejecución permite a un usuario ejecutar un archivo binario, como un programa.
  • Estos se abrevian como rwx, respectivamente. Si un usuario solo tiene permisos de lectura y ejecución (no escritura), se mostraría como r-x. El símbolo - indica la ausencia de ese permiso.
• 5.2.D.3 Hay tres entidades predeterminadas para las cuales se establecen los permisos y siempre en este orden: (1) el propietario del archivo, (2) el grupo del archivo y (3) todos los demás usuarios. Los tres conjuntos se muestran sin espacios (p. ej., rwxrwxrwx).
• 5.2.D.4 Para ver la configuración de permisos actual de un archivo, utilice el comando ls -l, que mostrará la configuración actual para las entidades predeterminadas. Si hay un símbolo + al final de los permisos, esto significa que se han establecido otros permisos para ese archivo y se pueden ver con el comando getfacl.
• 5.2.D.5 Para modificar la configuración de permisos de un archivo, utilice el comando chmod. Este comando se puede utilizar con el método numérico o el método simbólico.
• 5.2.D.6 Para usar chmod en el método numérico, la sintaxis es chmod ### filename. Cada uno de los tres ### representa una de las tres entidades mencionadas anteriormente (el propietario, el grupo, otros usuarios no pertenecientes al grupo).
  • El primer # = el propietario
  • El segundo # = el grupo
  • El tercer # = otros usuarios no pertenecientes al grupo
  • El permiso para cada entidad se determina sumando los valores correspondientes a los tipos de acceso que se van a conceder:
  • 0 = sin permisos
  • 1 = ejecución
  • 2 = escritura
  • 4 = lectura
  • Por lo tanto, 3 establece permisos de escritura y ejecución, 5 establece permisos de lectura y ejecución, 6 establece permisos de lectura y escritura, y 7 establece permisos de lectura, escritura y ejecución.
  • Ejemplos ilustrativos para 5.2.D.6:
    • El comando chmod 750 test establecería los permisos para el propietario de lectura, escritura y ejecución; para el grupo de lectura y ejecución; y para todos los demás ningún acceso en absoluto.
    • El comando chmod 543 test establecería los permisos para el propietario de lectura y ejecución; para el grupo solo lectura; y para todos los demás escritura y ejecución.
    • El comando chmod 777 test establecería los permisos para las tres entidades de lectura, escritura y ejecución para el archivo test.
• 5.2.D.7 Para usar chmod en el método simbólico, la sintaxis es chmod entity +(or –) permission filename. Las entidades son el propietario del usuario, el grupo y otros usuarios no pertenecientes al grupo. Cada entidad está representada por una sola letra.
  • u = propietario del usuario
  • g = grupo
  • o = otros
  • a = todos
  • El permiso se puede añadir o eliminar a cualquier combinación de entidades.
  • • = añadir el permiso
  • – = eliminar el permiso
  • Los permisos que se pueden establecer son lectura, escritura y ejecución.
  • r = lectura
  • w = escritura
  • x = ejecución
  • Las entidades y los permisos se pueden combinar en un solo comando. Para añadir los permisos de lectura y ejecución para el grupo y el propietario del usuario para un archivo llamado testfile, el comando sería chmod ug+rx testfile.

Objetivo de aprendizaje 5.3.A: Explicar cómo el cifrado puede utilizarse para proteger archivos.

• 5.3.A.1 El propósito de la criptografía es ocultar información. Un algoritmo criptográfico define un proceso para cifrar y descifrar información. El cifrado es el proceso de ocultar la información, y el descifrado es el proceso de revertir el cifrado para recuperar la información original.
• 5.3.A.2 Un algoritmo de cifrado define un proceso para combinar la información que se va a cifrar con una clave predefinida. La información que se va a cifrar se denomina texto en claro. La salida del algoritmo de cifrado se denomina texto cifrado.
• 5.3.A.3 El número de claves posibles que pueden utilizarse en un algoritmo de cifrado se denomina espacio de claves. Cuanto mayor sea el espacio de claves, más tiempo tardará un adversario en descubrir la clave correcta por azar.
• 5.3.A.4 Los algoritmos criptográficos se clasifican según si utilizan una clave o dos claves.
  • Los algoritmos de cifrado simétrico utilizan la misma clave para cifrar y descifrar la información.
  • Los algoritmos de cifrado asimétrico utilizan dos claves diferentes: una para cifrar la información y otra para descifrarla.
• 5.3.A.5 Los algoritmos criptográficos también se clasifican según si procesan la información un bit a la vez o en bloques fijos de bits.
  • El cifrado por bloques maneja la información en bloques de tamaño fijo denominados bloques, produciendo un bloque de salida para cada bloque de entrada.
  • El cifrado en flujo maneja la información de entrada de forma continua, produciendo la salida un elemento a la vez.

Objetivo de aprendizaje 5.3.B: Aplicar algoritmos de cifrado simétrico para cifrar y descifrar datos.

• 5.3.B.1 Los algoritmos de cifrado basados en computadoras operan sobre datos binarios. El algoritmo de cifrado simétrico más común es el Estándar de Cifrado Avanzado (AES). El cifrado AES se utiliza para asegurar las transmisiones Wi-Fi, la navegación por internet, el cifrado de archivos en discos y el cifrado a nivel de hardware en procesadores.
• 5.3.B.2 AES es un cifrador por bloques de clave simétrica que cifra los datos en bloques de 128 bits (16 bytes). AES puede operar con claves de longitudes variables. Las claves más largas producen un cifrado más seguro pero requieren más tiempo para cifrar y descifrar.
• 5.3.B.3 El cifrado y descifrado simétricos pueden realizarse mediante la línea de comandos, software especializado o herramientas basadas en la web.
  • En una interfaz de línea de comandos, los usuarios pueden cifrar o descifrar con OpenSSL.
  • Software especializado como AES Crypt es una herramienta de código abierto que puede cifrar y descifrar archivos.
  • Existen muchas herramientas basadas en la web para cifrar y descifrar archivos.
• 5.3.B.4 Utilizando OpenSSL en una CLI, un usuario puede cifrar y descifrar un archivo utilizando los siguientes comandos (teniendo en cuenta que la clave de cifrado se deriva de la contraseña proporcionada):
  • Para cifrar un archivo llamado test con AES utilizando una clave de 128 bits, utilice el comando: openssl enc -aes-128-cbc -e -in test -k password -out test.enc
  • Para descifrar el archivo cifrado utilizando la misma clave, utilice el comando: openssl enc -aes-128-cbc -d -in test.enc -k password -out text

Objetivo de aprendizaje 5.4.A: Determinar la clave asimétrica apropiada a utilizar al enviar o recibir datos cifrados.

• 5.4.A.1 El cifrado asimétrico permite a los usuarios comunicarse de forma segura sin necesidad de acordar previamente una clave secreta compartida.
• 5.4.A.2 Al utilizar cifrado asimétrico, cada entidad que vaya a recibir datos debe generar primero un par de claves. Los pares de claves son cadenas binarias de igual longitud que se generan simultáneamente mediante un proceso matemático. Una de las claves se designa como clave pública y la otra como clave privada. Las claves son inversas matemáticas entre sí: cada clave revierte a su pareja. Cualquier clave puede utilizarse para cifrar información, pero solo la otra clave del par podrá descifrarla.
• 5.4.A.3 Una vez que el receptor genera el par de claves, la clave privada debe almacenarse de manera segura. Si la clave privada queda expuesta, se comparte, es robada, corrupta o comprometida, el par de claves debe eliminarse y generarse uno nuevo, ya que la seguridad del algoritmo de cifrado depende de la seguridad de la clave privada. La clave pública se publica para que cualquiera pueda verla y utilizarla.
• 5.4.A.4 Para enviar información de forma segura a alguien, el remitente utilizará la clave pública del receptor para cifrar los datos y enviarlos. Solo el receptor, que posee la clave privada, podrá descifrar y leer la información.

Objetivo de aprendizaje 5.4.B: Explicar por qué la longitud de una clave impacta en la seguridad de los datos cifrados.

• 5.4.B.1 Las claves más largas dan lugar a espacios de claves más grandes. Para claves binarias, una clave de longitud de n bits tiene un espacio de claves de $2^n$.
• 5.4.B.2 Utilizar una aplicación para adivinar aleatoriamente una clave de cifrado de longitud de n bits significa que, en promedio, un adversario podrá adivinar la clave correcta en $2^n \div 2$ (o $2^{n-1}$) intentos.
• 5.4.B.3 Aunque las claves más largas son más seguras, también requieren más tiempo para cifrar y descifrar mensajes.
• 5.4.B.4 La potencia de procesamiento computacional y la eficiencia continúan mejorando, lo que permite que el software adivine claves más rápidamente. Las recomendaciones de longitud de clave tanto para algoritmos de cifrado simétrico como asimétrico aumentan periódicamente para tener en cuenta el mayor poder de procesamiento.
• 5.4.B.5 La comparación de la longitud de las claves solo es válida cuando se comparan claves para el mismo algoritmo criptográfico.
  • Ejemplos ilustrativos para 5.4.B.5:
    • Una clave AES de 256 bits es más segura que una clave AES de 128 bits.
    • Una clave RSA de 4096 bits es más segura que una clave RSA de 2048 bits.
    • Las claves RSA y AES no se pueden comparar directamente entre sí para determinar el nivel de seguridad.

Objetivo de aprendizaje 5.4.C: Aplicar algoritmos de cifrado asimétrico para cifrar y descifrar datos.

• 5.4.C.1 Los algoritmos comunes de cifrado asimétrico incluyen RSA y la criptografía de curva elíptica (ECC). Los algoritmos asimétricos se utilizan en muchas aplicaciones, incluidas las firmas digitales y los certificados digitales.
• 5.4.C.2 Al igual que con el cifrado simétrico, el cifrado y descifrado asimétricos pueden realizarse mediante la línea de comandos, software especializado o herramientas basadas en la web.
  • En una interfaz de línea de comandos, los usuarios pueden cifrar o descifrar con OpenSSL.
  • Software especializado como RSA Encryption Tool es una herramienta de código abierto que puede cifrar y descifrar archivos.
  • Existen muchas herramientas basadas en la web para cifrar y descifrar archivos.
• 5.4.C.3 En una CLI, un usuario puede generar un par de claves asimétricas y cifrar o descifrar archivos según sea necesario.
  • Para generar un par de claves RSA de 2048 bits y guardar la clave en un archivo llamado rsa.pem, utilice el comando: openssl genrsa -out rsa.pem 2048
  • Para extraer la clave pública de rsa.pem a un archivo llamado public.pem, utilice el comando: openssl rsa -pubout -in rsa.pem -outform PEM -out public.pem
  • Para cifrar el archivo test utilizando cifrado RSA y el archivo de clave public.pem, utilice el comando: openssl pkeyutl -encrypt -pubin -inkey public.pem -in test -out test.enc
  • Para descifrar el archivo test.enc utilizando el archivo rsa.pem, ejecute el comando: openssl pkeyutl -decrypt -inkey rsa.pem -in test.enc -out test

Objetivo de aprendizaje 5.5.A: Identificar los principios de seguridad en aplicaciones: "seguro por diseño" y "seguro por defecto".

• 5.5.A.1 El enfoque "seguro por diseño" es una iniciativa que anima a las empresas a incluir la seguridad en todas las fases del desarrollo de productos, incluido el diseño. Cuando las organizaciones implementan este enfoque, la seguridad se convierte en un principio de diseño y no solo en una característica técnica.
• 5.5.A.2 El enfoque "seguro por diseño" incluye tres principios de diseño:
  • i. Las empresas deben asumir la responsabilidad de los resultados de seguridad de sus clientes. Deben construir productos que cumplan con las necesidades de seguridad de sus usuarios.
  • ii. Las empresas deben adoptar la transparencia radical y la rendición de cuentas. La publicación rápida de noticias y actualizaciones relevantes sobre seguridad mejora la seguridad para todos.
  • iii. Las empresas deben construir una estructura organizativa y liderazgo para implementar el enfoque "seguro por diseño". Necesitan líderes enfocados en la seguridad y con una postura prioritaria hacia la misma.
• 5.5.A.3 El enfoque "seguro por diseño" incluye el concepto de "seguro por defecto", que establece que las características de seguridad del software y los dispositivos deberían estar activadas por defecto. Los dispositivos y el software deben ser seguros de usar desde el primer momento (out of the box), con las funciones de seguridad ya habilitadas.

Objetivo de aprendizaje 5.5.B: Explicar cómo la sanitización de la entrada del usuario protege las aplicaciones.

• 5.5.B.1 Cuando los usuarios introducen datos en una aplicación, esta generalmente envuelve dicha entrada entre caracteres especiales para procesarla. Los caracteres que delimitan la entrada del usuario se denominan caracteres de control e incluyen la comilla simple, la comilla doble y el punto y coma.
• 5.5.B.2 Al crear un programa que recibe entrada del usuario, los programadores deben utilizar una función para verificar que la entrada cumpla con los criterios esperados y no incluya ningún carácter de control que pueda usarse para manipular el sistema. Esta función de verificación puede sanear la entrada del usuario eliminando caracteres potencialmente maliciosos, o bien puede mostrar un error al usuario y forzarle a proporcionar una entrada diferente. Esto puede proteger contra diversos ataques a aplicaciones, incluidos:
  • Ataques de inyección SQL
  • Ataques XSS
  • Ataques de navegación de directorios

Objetivo de aprendizaje 5.6.A: Explicar cómo detectar ataques a los datos.

• 5.6.A.1 Los dispositivos registran y almacenan en registros cuándo se accede a los datos y por quién. El proceso de grabación y monitoreo de las actividades del usuario se denomina contabilidad (accounting). El análisis de estos registros puede revelar actividad maliciosa cuando un adversario intenta acceder, copiar, mover o eliminar datos. La actividad sospechosa puede incluir:
  • Acceder a archivos que no suelen ser accedidos
  • Acceder a archivos o aplicaciones fuera de los patrones normales de un usuario (incluyendo la hora del día, la ubicación y el tipo de dispositivo)
  • Intentos de eliminar o copiar archivos sensibles
• 5.6.A.2 Un honeypot es un archivo que parece contener datos valiosos (por ejemplo, información de tarjetas de crédito, PII, contraseñas), pero los datos en el archivo son falsos. Un sistema puede alertar a los defensores si alguien intenta acceder al honeypot. Dado que el honeypot es un archivo falso, no hay una razón legítima para acceder a él, y cualquier intento de acceso sería un indicador de actividad maliciosa.
• 5.6.A.3 Las funciones hash criptográficas pueden generar un resumen (digest) para los datos y pueden revelar si los datos han sido alterados. Si un archivo ha cambiado inesperadamente, esto puede ser una señal de actividad maliciosa.

Objetivo de aprendizaje 5.6.B: Determinar controles para detectar ataques contra aplicaciones o datos.

• 5.6.B.1 El costo es un criterio para determinar los controles detectores. Los controles detectores como los honeypots y el uso de valores hash para verificar la integridad de los datos son económicos. Algunas organizaciones invierten en servicios de terceros de prevención de pérdida de datos (DLP), que monitorean el acceso, uso y transmisión de datos por parte de los usuarios en toda la organización para detectar actividad sospechosa; los servicios DLP proporcionan fuertes capacidades de detección a un costo más elevado.
• 5.6.B.2 La sensibilidad o criticidad de los datos o aplicaciones es un criterio para determinar los controles detectores. Los datos o aplicaciones más sensibles o críticos son objetivos más probables de un adversario y deben ser monitoreados más de cerca.
• 5.6.B.3 La clasificación de los datos es un criterio para determinar los controles detectores. Los datos que han sido clasificados como privados, educativos, de salud o financieros a menudo tienen requisitos legales o regulatorios de detección y monitoreo.

Objetivo de aprendizaje 5.6.C: Evaluar el impacto de un método para detectar ataques contra una aplicación o datos.

• 5.6.C.1 Para operar a una velocidad efectiva, el análisis de registros debe complementarse con cierta automatización. Los honeypots ofrecen capacidades de detección casi instantáneas.
• 5.6.C.2 Algunas herramientas DLP, honeypots y análisis de registros automatizado en tiempo real proporcionan alertas mientras ocurre un ataque. Estas herramientas permiten una respuesta rápida que puede detener un ataque antes de que cause más daño. El análisis retrospectivo de registros y el uso de hash criptográficos para verificar la integridad de los datos identifican ataques después de que han ocurrido.
• 5.6.C.3 Pueden ocurrir falsos negativos en la detección de ataques a aplicaciones y datos. Las funciones hash criptográficas solo detectan si los datos han sido alterados. Un adversario podría ver y robar datos sin alterarlos, y una función hash criptográfica no detectaría esto. Los honeypots no pueden detectar adversarios que no intenten acceder a ellos.

Objetivo de aprendizaje 5.6.D: Identificar si un archivo ha sido alterado verificando su hash.

• 5.6.D.1 Las funciones hash criptográficas pueden ayudar a identificar cambios en un archivo porque son repetibles: la misma entrada siempre produce la misma salida para una función hash dada.
• 5.6.D.2 Los hashes se pueden calcular usando la línea de comandos en una computadora, un sitio web o software especializado.
  • En Windows Powershell, si un usuario quisiera generar el hash SHA256 para un archivo llamado testfile, usaría el comando: Get-FileHash testfile -Algorithm SHA256
  • En BASH lo mismo se podría lograr con el comando: sha256sum testfile
  • En zsh, la terminal de línea de comandos común en computadoras Apple, esto se podría lograr con el comando: shasum -a 256 testfile
• 5.6.D.3 Se puede realizar el hash de un archivo y registrar su salida hash. Luego, se puede volver a hacer el hash más tarde y comparar la segunda salida hash con la salida hash anterior para el mismo archivo. Si el hash de un archivo cambia, entonces el archivo fue alterado entre el momento en que se generaron el primer y segundo hash.

Objetivo de aprendizaje 5.6.E: Aplicar técnicas de detección para identificar e informar indicadores de ataques a aplicaciones mediante el análisis de archivos de registro.

• 5.6.E.1 Los ataques de inyección SQL pueden detectarse revisando los registros de la aplicación y del servidor en busca de palabras clave y símbolos de control SQL en la entrada del usuario, tales como:
  • Un carácter de comilla simple (') o doble (")
  • Condiciones booleanas como OR 1=1
  • Dos guiones dobles (que indican un comentario en SQL): --
  • Palabras clave de control SQL (siempre en mayúsculas) como WHERE, IN, FROM
• 5.6.E.2 Los ataques XSS pueden detectarse revisando la entrada del usuario en busca de etiquetas sospechosas, particularmente la etiqueta .
• 5.6.E.3 Para aplicaciones web, los desbordamientos de búfer pueden detectarse verificando la cantidad de datos que el usuario está enviando a la aplicación web en su solicitud. Los campos comúnmente verificados son la longitud de la URL, la longitud de las cookies, la longitud de la cadena de consulta y la longitud total de la solicitud. Cadenas largas en cualquiera de estos campos pueden ser un indicador de un intento de ataque de desbordamiento de búfer.
• 5.6.E.4 Los ataques de traversía de directorio pueden detectarse revisando los registros de la aplicación y del servidor. Las solicitudes HTTP GET que incluyen rutas con secuencias de ../ son indicadores de un adversario que intenta una traversía de directorio.